Я использую сервер nginx, который действует как прокси для восходящего сокета Unix, например:
upstream app_server {
server unix:/tmp/app.sock fail_timeout=0;
}
server {
listen ###.###.###.###;
server_name whatever.server;
root /web/root;
try_files $uri @app;
location @app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
}
Некоторые процессы сервера приложений, в свою очередь, обрабатывают запросы по /tmp/app.sock
мере их появления. Конкретный сервер приложений, используемый здесь, - это Unicorn, но я не думаю, что это имеет отношение к этому вопросу.
Проблема в том, что кажется, что после определенной нагрузки nginx не может получать запросы через сокет с достаточно высокой скоростью. Не имеет значения, сколько процессов сервера приложений я настроил.
Я получаю поток этих сообщений в журнале ошибок nginx:
connect() to unix:/tmp/app.sock failed (11: Resource temporarily unavailable) while connecting to upstream
Многие запросы приводят к коду состояния 502, и те, которые не требуют много времени для выполнения. Статистика очереди записи nginx колеблется около 1000.
В любом случае, я чувствую, что мне здесь не хватает чего-то очевидного, потому что эта конкретная конфигурация nginx и сервера приложений довольно распространена, особенно с Unicorn (на самом деле это рекомендуемый метод). Есть ли какие-либо параметры ядра Linux, которые нужно установить, или что-то в nginx? Любые идеи о том, как увеличить пропускную способность для восходящего сокета? Что то я явно не так делаю?
Дополнительная информация об окружающей среде:
$ uname -a
Linux servername 2.6.35-32-server #67-Ubuntu SMP Mon Mar 5 21:13:25 UTC 2012 x86_64 GNU/Linux
$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
$ unicorn -v
unicorn v4.3.1
$ nginx -V
nginx version: nginx/1.2.1
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
TLS SNI support enabled
Текущие настройки ядра:
net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_mem = 16777216 16777216 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.somaxconn = 8192
net.netfilter.nf_conntrack_max = 524288
Настройки Ulimit для пользователя nginx:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65535
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
ulimit
, а именно количество открытых файлов?ulimit -n
говорит65535
.Ответы:
Похоже, узким местом является приложение, питающее сокет, а не само Nginx. Мы часто видим это с PHP при использовании сокетов по сравнению с TCP / IP-соединением. В нашем случае узкие места PHP гораздо раньше, чем Nginx.
Вы проверили превышение лимита отслеживания соединения sysctl.conf, лимита невыполнения сокетов
net.core.somaxconn
net.core.netdev_max_backlog
источник
Вы можете попробовать
unix_dgram_qlen
посмотреть документацию к документам . Хотя это может усугубить проблему, указав больше в очереди? Вам придется посмотреть (netstat -x ...)источник
Я решил, увеличив число невыполненных заданий в config / unicorn.rb ... Я имел отставание до 64.
и я получаю эту ошибку:
Теперь я увеличил до 1024, и я не получаю ошибку:
источник
ТЛ; др
listen("/var/www/unicorn.sock", backlog: 1024)
worker_connections 10000;
обсуждение
У нас была та же проблема - приложение Rails, обслуживаемое Unicorn за обратным прокси-сервером NGINX.
В журнале ошибок Nginx были такие строки:
Читая другие ответы, мы также поняли, что, возможно, виноват Юникорн, поэтому мы увеличили его отставание, но это не решило проблему. При мониторинге серверных процессов было очевидно, что Unicorn не получает запросы для обработки, поэтому NGINX оказался узким местом.
Поиск параметров NGINX для настройки в
nginx.conf
этой статье о настройке производительности выявил несколько параметров, которые могут повлиять на количество параллельных запросов, которые может обрабатывать NGINX, особенно:источник
Значение по умолчанию для backlog - 1024 в конфигурации Unicorn.
http://unicorn.bogomips.org/Unicorn/Configurator.html
Клиент 1024 - это ограничение сокета домена unix.
источник