Ты бы что ли конфиги показал.

чтобы не спамить привожу существенные части конфигов, вырезав комментарии и явно не относящиеся к обсуждению вещи

nginx:
------------------------------------------------
worker_rlimit_nofile 99999;

events {
worker_connections 10240;
}

upstream backend {
server unix:/tmp/fcgi.sock;
}
location ~ .php$ {
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_pass backend;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/someurlwashere/www$fastcgi_script_name;
include fastcgi_params;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_intercept_errors on;
fastcgi_ignore_client_abort off;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
}
---------------------------------------------------------------------------
php.ini не модифицировался - стандартный из дистрибутива
----------------------------------------------------------------------------
/etc/php5/fpm/pool.d/www.conf:

[www]
listen.backlog = 2000
user = www-data
group = www-data
pm = static
pm.max_children = 2100
pm.start_servers = 500
pm.min_spare_servers = 500
pm.max_spare_servers = 2000
pm.max_requests = 500
request_terminate_timeout = 1m
request_slowlog_timeout = 60
slowlog = /var/log/php.log.slow
rlimit_files = 65535
chdir = /
catch_workers_output = yes

pm = static
pm.max_children = 2100
pm.start_servers = 500
pm.min_spare_servers = 500
pm.max_spare_servers = 2000

Твой конфиг — говно.

Слишком МНОГО врокеров, чайлдов и серверов. Сделай значения поближе к дефолту, тогда процент фейлов сойдет на 0.

Давай по-порядку. Показывай ulimit -a
Зачем тебе столько соединений?
Воркер только 1?
Сколько процессоров?

Слишком мало мозгов.

Лорчую

ulimit -a

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) 512000 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 ------------------------------------------------------ т.е. как бы в дескрипторы не упирается

worker_processes 5; виртуальная машина с 24 ядрами 2x 6Core Xeon, + hyperthreading

Коллеги, вы уверены, что дело в nginx? ведь с теми же самыми параметрами, только с proxy_pass -> apache вместо fastcgi_pass -> php-fpm все работает значительно лучше, неужели на fpm так сказываются настройки nginx?

прошу прощения, вот, с нормальными переносами:
ulimit -a
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) 512000
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
------------------------------------------------------
т.е. как бы в дескрипторы не упирается

worker_processes 5;
виртуальная машина с 24 ядрами
2x 6Core Xeon, + hyperthreading


Коллеги, вы уверены, что дело в nginx?
ведь с теми же самыми параметрами, только
с proxy_pass -> apache
вместо fastcgi_pass -> php-fpm
все работает значительно лучше, неужели на fpm так сказываются настройки nginx?

php-fpm медленнее mod_php ?

Жесть какая. А ещё недавно php-fpm имел такую же скорость, как и php-fcgi и как mod_php.

Сейчас картина такая (вызов <?php echo 2*2; ?>), 10000 запросов в 100 потоков:

lighttpd/php-fcgi = 18мс/запрос, 5,5 тыс. запросов в секунду

apache2/mod_php = 28мс, 3,6 тыс./с

nginx/php-fpm = 65мс, 1,5 тыс./с.

Походу, мне придётся пересмотреть некоторые схемы своих сайтов :)

А, да, ошибок, правда, никаких нет.

Да, очень сильно.
Уменьшай количество соединений. У тебя всё слишком похоже на превышение лимита файлов/соединений.

Проверь ещё длину очереди нетфильтра. http://shtsh.blogspot.com/2012/01/blog-post.html
Правда, эта проблема должна была быть в логах.

nginx/php-fpm = 65мс, 1,5 тыс./с.

Впрочем, после оптимизации параметров, удалось вытянуть 30мс и 3,3 тыс./с. Уже уровень Apache выходит, хотя и проигрывает lighttpd/fcgi.

вы или пишите по делу,
или покиньте обсуждение

что не понравилось в конфиге?
увидели одновременно и static и dynamic опции,
мозгов не хватило понять что игрался с параметрами и забыл вырезать?

KRON73
указанный эталонный php с «<? echo 2*2; ?>

у меня выдал на fpm
Concurrency Level: 100
Requests per second: 10679.35 [#/sec]

и тоже естественно без ошибок,
вопрос именно в том, чтобы держать 2000 именно параллельных клиентов

было бы здорово если вы поделились информацией о том, в чем заключалась ваша оптимизация

держать 2000 именно параллельных клиентов

Ололо. С такой задачей пхп справляется крайне говено. Вам необходимо пересмотреть архитектуру.

было бы здорово если вы поделились информацией о том, в чем заключалась ваша оптимизация

Ну, оказалось, что число воркеров 4 оказалось заметно лучше, чем 3, которые стояли до этого (да, ядра 4, но nginx там играет маловажную роль).

Также заметно ускорило работу увеличение pm.max_children до 100 (было 50) (и, да, у меня pm = dynamic). От числа серверов зависит мало.

Однако, общее число php-cgi детей у lighttpd — 40 и он справляется с теми же запросами много лучше.

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

Проверь ещё длину очереди нетфильтра

net.ipv4.netfilter.ip_conntrack_max=1000000
во время теста:
net.ipv4.netfilter.ip_conntrack_count = 28243
т.е. эта оптимизация -пройденный этап -не упирается

протестил различные значения
worker_processes
worker_connections

существенных изменений по нагрузке не обнаружил.
оставил в соответствии с официальными рекомендуемыми

Нетфильтр выгрузить неплохо бы. А потом в error.log нгинкса посмотреть.

pm.max_children = 2100
pm.max_requests = 500

это просто бред.

Сделайте max_requests в районе 5000, pm.max_children 2100 - у вас что воркеры блокируеются на секунду чтобы запрос выполнить? Сделайте разумное число какое то.

вопрос именно в том, чтобы держать 2000 именно параллельных клиентов

2000 параллельных клиентов это никак не значит 2000 параллельных php процессов. Если вы конечно не гигабайты ответа генерите php скриптом для каждого клиента.

зомби топик

cast KRoN73, на чем все-таки закончились опыты с производительностью?

Сам сейчас на php-fpm+lighttpd сижу, думаю может свалить на php-fcgi

cast KRoN73, на чем все-таки закончились опыты с производительностью?

Я потом к этой теме больше не возвращался. А php-fpm избегаю, где можно, по другой причине — оно с некоторых пор и в Gentoo, и в Ubuntu, стало падать. При чём встроенный менеджер (т.е. суть FPM) процессы не поднимает. Так и висит nginx с гейтвей-эррором.

А вот lighttpd сам прекрасно поднимает упавшие fcgi. Так что всё ответственное — на нём.

При чём, в Ubuntu под fpm сейчас вообще муть какая-то. Висит сайт. Стоит тупой watchdog, который wget'ом раз в N минут проверяет доступность страниц и при их отваливании рестартует fpm-демон. Через какое-то время оказывается, что часть страниц, в т.ч. контролируемая, работает, остальные — нет. Добавляешь новую страницу, через какое-то время все контролируемые работают, часть неконтролируемых — нет. Т.е., судя по всему, отваливается часть процессов, но только часть. И возникает ситуация, когда процессы контролируемых страниц доступны, остальные — упали.

Поковырялся с параметрами самоконтроля, рестарта — вроде, пока особо не помогает. Надо дальше копать.

спасибо, что ответил :)

А насчет падений php-fpm, не замечал такого в gentoo ~x86

ясно, тогда переползаю на fcgi, опять таки меньше конфигов крутить

Вообще, при наличии lighttpd, php-fpm нужен только если требуется многопользовательская система или индивидуальные настройки для разных хостов. Менеджер процессов в lighttpd при работе с fastcgi много лучше, чем менеджер в php-fpm.