У Nginx и PHP-FPM закончились соединения

9

Я продолжаю сталкиваться с такими ошибками,

[02-Jun-2012 01:52:04] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 19 idle, and 49 total children
[02-Jun-2012 01:52:05] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 16 children, there are 19 idle, and 50 total children
[02-Jun-2012 01:52:06] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 19 idle, and 51 total children
[02-Jun-2012 03:10:51] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 18 idle, and 91 total children

Я изменил свои настройки для php-fpm к этим,

pm.max_children = 150 (It was at 100, i got a max_children reached and upped to 150)
pm.start_servers = 75
pm.min_spare_servers = 20
pm.max_spare_servers = 150

В результате чего 

[02-Jun-2012 01:39:19] WARNING: [pool www] server reached pm.max_children setting (150), consider raising it

Я только что запустил новый сайт, который получает значительное количество трафика. Этот трафик является законным, и пользователи получают 504 тайм-аута шлюза при достижении лимита.

У меня ограниченные подключения к моему серверу с помощью IPTABLES, и я запускаю fail2ban и отслеживаю журналы доступа nginx. Трафик весь законный, мне просто не хватает места для пользователей.

В настоящее время я работаю на двухъядерной коробке с Ubuntu 64bit.

free
             total       used       free     shared    buffers     cached
Mem:       6114284    5726984     387300          0     141612    4985384
-/+ buffers/cache:     599988    5514296
Swap:       524284       5804     518480

Мой php.ini max_input_time = 60

Мой конфиг nginx

worker_processes 4;
pid /var/run/nginx.pid;

events {
    worker_connections 19000;
    # multi_accept on;
}
worker_rlimit_nofile    20000;  #each connection needs a filehandle (or 2 if you are proxying)

client_max_body_size 30M;
client_body_timeout   10;
client_header_timeout 10;
keepalive_timeout     5 5;
send_timeout          10;

    location ~ \.php$ {
    try_files $uri /er/error.php;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_connect_timeout 60;
    fastcgi_send_timeout 180;
    fastcgi_read_timeout 180;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 256 16k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    fastcgi_max_temp_file_size 0;
    fastcgi_intercept_errors on;
    fastcgi_pass unix:/tmp/php5-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
}

Что я могу сделать, чтобы остановить исчерпание соединений? Почему это происходит? Я отслеживаю свой трафик в Google Analytics в режиме реального времени, и когда число пользователей становится выше примерно 120, мой php-fpm.log заполняется этими предупреждениями.

nginx php-fpm E3pO
источник

Ответы:

5

Рассматривали ли вы, следуя хорошему совету, представленному в сообщении журнала, повышение значения pm.max_children? У вас есть куча свободной оперативной памяти для их размещения.

Чтобы ответить на ваши вопросы:

  • Что я могу сделать, чтобы остановить исчерпание соединений? Предоставьте больше подключений или уменьшите количество получаемых подключений.
  • Почему это происходит? Потому что у тебя кончаются связи.
ombble
источник
Извините, эта ошибка была помечена после того, как я обновил ее до 150 из 100 ... Да, у меня есть. Какие настройки я должен установить для всех моих оперативной памяти?
E3pO
Вы должны увеличить его до того (free/mem_per_worker)+150, где freeбудет объем памяти, который будет у вас после учета потребностей других процессов, чьи требования к памяти будут увеличиваться с увеличением нагрузки, и mem_per_workerэто максимальный объем памяти, который вы предвидите для каждого рабочего процесса PHP.
womble
4

У нас была такая же проблема на наших веб-серверах.

Вы можете попытаться перезапустить дочерний процесс каждые X запросов, чтобы избежать утечек памяти. Он хорошо работал в Apache и FPM, но и начинает хорошо работать.

 pm.max_requests = 50000

Это будет перезапускать дочерний процесс каждые 50 000 запросов

Али Альваш
источник