Nginx + единорог (rails) часто выдает «Отказ в соединении» в журнале ошибок nginx - PullRequest
Новая
       3

Nginx + единорог (rails) часто выдает «Отказ в соединении» в журнале ошибок nginx

3 голосов
/ 24 мая 2011

На работе у нас есть несколько сайтов с высоким трафиком в рельсах. У нас часто возникают проблемы со спамом в журнале ошибок nginx: 

2011/05/24 11:20:08 [error] 90248#0: *468577825 connect() to unix:/app_path/production/shared/system/unicorn.sock failed (61: Connection refused) while connecting to upstream

Наша настройка - это nginx на внешнем сервере (балансировка нагрузки) и единорог на наших 4 серверах приложений. Каждый единорог работает с 8 работниками. Настройка очень похожа на ту, что использует GitHub.

Большая часть нашего контента кэшируется, и когда запрос достигает nginx, он ищет страницу в memcached и сообщает, что может найти ее - в противном случае запрос отправляется на рельсы.

Я могу решить вышеуказанную проблему - ИНОГДА - выполнив pkill процессов единорога на серверах, после чего: 

cap production unicorn:check (removing all the pid's)
cap production unicorn:start

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

Ответы [ 2 ]

0 голосов
/ 20 января 2014

Я не думаю, что это проблема nginx для меня, перезапуск nginx не помог. Похоже, что это Gunicorn ... Быстрый и грязный способ избежать этого - перерабатывать экземпляры Gunicorn, когда система не используется, например, в 1:00, если это приемлемое окно обслуживания. Я запускаю gunicorn как сервис, который вернется, если его убьют, поэтому сценарий pkill позаботится о перезапуске / перезапуске: 

start on runlevel [2345]
stop on runlevel [06]
respawn
respawn limit 10 5
exec /var/web/proj/server.sh

Я начинаю задумываться, связано ли это вообще с выделением памяти. У меня есть MongoDB, работающий в той же системе, и он резервирует всю память для себя, но он должен давать, если другие приложения требуют больше памяти.

Другие вещи, которые стоит попробовать, - избавление от eventlet или других зависимых модулей при запуске gunicorn. uWSGI также может использоваться как альтернатива оружейному мозгу.

0 голосов
/ 17 ноября 2011

Что-то убило ваш процесс единорога на одном из серверов или истекло время ожидания.Или у вас в старом блоке app_server {} есть старый сервер приложений, который больше не действителен.Nginx будет повторять это время от времени.По умолчанию повторная попытка другого восходящего потока, если он получает ошибку соединения, надеюсь, ваши клиенты ничего не заметили.

...