почему рабочие uwsgi простаивают, но nginx показывает много тайм-аутов?

Стек: nginx, uwsgi, джанго

uwsgitop и top показали, что рабочие процессы uwsgi простаивают, а в журнале ошибок nginx указано, что время ожидания истекло.

Я думал, что некоторым запросам требуется много ресурсов, таких как ожидание базы данных или кеша, а другим нет. После проверки запросов с истекшим временем ожидания большинство из них оказались не прожорливыми. Время ожидания любого запроса истекло.

Так почему же nginx не отправлял запросы на незанятые, если остальные были действительно заняты? почему мастер uwsgi просто держит кого-то занятым, а остальных бездействует?


django nginx uwsgi
person samuel    schedule 13.11.2012    source источник
comment
по моему опыту, реализация nginx wsgi работает плохо, особенно если приложение блокируется на несколько миллисекунд.   -  person Paulo Scardine    schedule 13.11.2012
comment
Они делают это постоянно или только при высокой нагрузке? У вас много операций ввода-вывода на вашем сайте?   -  person RickyA    schedule 14.11.2012
comment
@PauloScardine uwsgi на самом деле очень хорошо работал как в синхронном, так и в асинхронном режиме, хотя я не осмеливаюсь использовать асинхронный режим. Вместо этого я использую сельдерей. Я думал, что uwsig тоже блокирует, но другие рабочие бездействуют, так что это не может быть проблемой блокировки.   -  person samuel    schedule 14.11.2012
comment
@RickyA да, проблема была с загрузкой и вводом-выводом, но затем мы решили эти проблемы. Раньше DB IO был очень высоким, после некоторой настройки я удалил высокий IO.   -  person samuel    schedule 14.11.2012
comment
@PauloScardine Я полагаю, вы говорите о mod_wsgi для nginx, совершенно другом проекте (теперь и с другим именем), потому что uWSGI не работает в адресном пространстве процесса nginx.   -  person roberto    schedule 17.11.2012

Ответы (2)


arrow_upward
9
arrow_downward

Я хотел бы ответить на свой вопрос.

изменить параметр ядра: net.ipv4.ip_conntrack_max с 65560 на 6556000

У меня есть полная история о том, как мы нашли ответ:

  1. пользователь сказал медленно, медленно, медленно

  2. nginx переполнен сообщением «время ожидания исходящего соединения истекло»

  3. Я проверил лог uwsgi, нашел некоторые ошибки, исправил их; нашел больше, исправил больше, и этот цикл длился несколько дней. До вчерашнего дня я думал, что uwsgi, memcached, db, redis или что-то еще не имеет отношения к бэкэнду, потому что uwsgi простаивал.

  4. поэтому я подумал, что с nginx, должно быть, что-то не так, перезагрузите, перезапустите, проверьте соединения, рабочие, proxy_read_timeout и т. д. Не повезло.

  5. проверил ulimit -n, который сообщил 1024, значение по умолчанию. У меня есть 8 рабочих nginx, поэтому соединения должны достигать 1024 * 8, я подумал, что это может быть нормально, поскольку nginx никогда не говорил слишком много открытых файлов. Во всяком случае, я изменил его на 4096. Не повезло.

  6. проверьте количество подключений и состояние, после чего появится проблема. все восходящие соединения были в состоянии syn_sent, затем произошло время ожидания. Только 2 или 3 из 300 соединений находятся в установленном состоянии. Мы хотели знать почему. Один из моих друзей посоветовал мне использовать tcpdump, волшебный инструмент, который я ни разу не решился попробовать.

  7. Затем мы идем в syslog и обнаружили следующую ошибку, и, наконец, мы решили проблему

person samuel    schedule 14.11.2012

arrow_upward
0
arrow_downward

У меня была аналогичная проблема, когда моя очередь прослушивания росла, а количество запросов в секунду было низким, несмотря на то, что все рабочие бездействовали.

samuel нашел один из случаев, но есть еще несколько потенциальных причин такого поведения:

  • net.core.somaxconn недостаточно высок
  • uwsgi --listen недостаточно высокий
  • Рабочие процессы nginx слишком медленные
  • Слишком мало рабочих соединений nginx

Если ничего из этого не работает, вам нужно проверить свои журналы, что входящие запросы к uWSGI находятся под http/1.1, а не http/1.0, а затем использовать --http11-socket

Вот некоторые из моих выводов, когда я боролся с этой проблемой: https://wontonst.blogspot.com/2019/06/squishing-performance-bug-in.html

На странице настройки nginx также есть некоторые другие настройки, которые могут быть полезными или бесполезными для решения этой проблемы: https://www.nginx.com/blog/tuning-nginx/

person wonton    schedule 28.06.2019