«Провалы» в работе Nginx

Nginx версии 1.2.7

Это достаточно старая версия, я бы начал с установки актуальной 1.6.2

Может затык в ФС? Попробуйте на определённый location повесить return 200, отключить access log и прогнать тестирование на нём, повторится ли проблема?

пальцем в небо: включить multi_accept и поднять worker_connections

Access log отключён был изначально, а SSD должен исправлять основные затыки работы с ФС, я думаю.

До версии 1.6.2 обновил, значения параметров multi_accept и worker_connections установил/поднял.
После проведённых правок проблема осталась, но видоизменилась.

Во-первых, на тестировании location`а c «return 200» и на тестировании php-скриптов, изображающих бурную деятельность (вызовающих mt_rand() в цикле) такого провала больше не наблюдается, однако он проявляется при запросе скриптов приложения.
Во-вторых, период работы увеличился с 30 секунд до примерно 45, после чего опять следует провал аналогичной продолжительности (или чуть меньшей).

Такое ощущение, что есть некое что-то, которое расходовалось раньше Nginx`ом, а теперь им расходуется экономичнее и это что-то расходуется напару с приложением (которое создаёт коннекты к базам, например). Когда это что-то заканчивается, оно подчищается неким коллектором и начинает расходоваться заново.

График загрузки процессора при двухминутном тестировании: http://i67.fastpic.ru/big/2014/1224/0e/8622492fee0db4d5c02a20e3a618410e.jpeg
Видно, что период работы стал больше. Также стоит отметить, что в конце тестирования потребление чего-то снижалось, из-за чего провала «в ноль» не наблюдается — он нивилировался снизившейся нагрузкой.

Может быть это какое-то ограничение самой ОС? Количество открытых сетевых соединений?.. Что-то ещё?

не знаю как в макоси, но для линукса стоит изучить вот это:
https://rtcamp.com/tutorials/linux/sysctl-conf/

начиная в твоем случае с секции
### TUNING NETWORK PERFORMANCE ###

Конфиг нжинкс? Применяется ли кеширование?

Очень похоже на лимит открытых файлов, но оно бы писалось в error.log и проявлялось не так резко. В cpu не упирается, в память тоже вряд ли.

Раз уж с новым nginx на статике нет проблемы, то очевидно надо искать со стороны приложения, например засекать время между установкой соединения с приложением, началом обработки запроса, окончанием и закрытием соединения, чтобы понять в какой фазе проблема.

Но скорее всего проблема с системой/сетевым стеком. Используются где то имена хостов вместо ip? Может резолвинг тормозит? Как nginx и приложение общаются(сеть/unix сокет)? приложение и БД?

Обращение к приложению происходит по хосту, обращение к базам — ip:port. Всё находится локально и при не очень высоких нагрузках работает замечательно.

Профайлингом приложения смогу заняться чуть позже, но сдаётся мне, что проблемой окажется момент установки соединения с какой-нибудь базой. За время тестирования в логе php появилась пара таймаутов при попытке коннекта к Memcached. То есть, судя по всему, проблема общая.

Провёл тестирование на статическом location`е при бОльшем concurrency — проблема проявляется и в этом случае:

Transactions:		       26085 hits
Availability:		      100.00 %
Elapsed time:		       59.90 secs
Data transferred:	        0.00 MB
Response time:		        0.18 secs
Transaction rate:	      435.48 trans/sec
Throughput:		        0.00 MB/sec
Concurrency:		       77.11
Successful transactions:       26085
Failed transactions:	           0
Longest transaction:	       13.60
Shortest transaction:	        0.00

Базовый конфиг nginx:

worker_processes  12;

error_log  /var/log/nginx/error.log debug_http debug_event;

events {
    worker_connections  8096;
    multi_accept        on;
}

worker_rlimit_nofile 40000;

http {
    include       mime.types;
    client_max_body_size 20M;
    default_type  application/octet-stream;

    access_log  /var/log/nginx/access.log;

    sendfile        on;

    keepalive_timeout  0;

    include       /usr/local/etc/nginx/sites-avaliable/*.conf;
}

server {
  listen 80;

  server_name domain.dev;
  root .../www;

  server_tokens off;
  tcp_nopush on;
  tcp_nodelay on;
  reset_timedout_connection on;
  client_body_timeout 10;
  send_timeout 2;

  gzip off;

  access_log off;
  error_log .../logs/error.log;

  charset utf-8;
  index index.php;

  location ~* \.php$ {
    fastcgi_index   index.php;
    fastcgi_pass    127.0.0.1:9000;
    include         fastcgi_params;
    fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
    fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;
    fastcgi_max_temp_file_size 0;
    fastcgi_buffers 256 16k;
  }
}

fastcgi_pass 127.0.0.1:9000;

В пределах одной машины лучше общаться через unix сокет, там нет оверхеда сетевого стека. Т.е. что-то вроде:

fastcgi_pass    unix:/tmp/fastcgi.socket;

435.48 trans/sec в среднем на заглушку какой-то ужас, даже при учёте этого 14 секундного простоя. На статике на локалхосте около 20k стоит ждать. А если проблема не проявляется, сколько rps получается?

Попробуйте обращаться везде где можно по ip.

При -c200, условно говоря, проблемы нет (Longest transaction всего лишь 0.91 секунды). При этом trans/sec равен 371. Если ставить -c2000, или даже -c1000, то появляются ошибки типа

[error] socket: 448630784 connection refused.: Connection refused
[alert] socket: 917061632 select timed out: Invalid argument

При работе siege через ip (на «return 200») ничего не изменилось: проблема на месте, rps не повысился.

Тогда это еще одно проявление проблемы, предлагаю откатить конфиг совсем на дефолтный и проверить там rps. Если будет хоть сколько-то нормальным (>5k), то пробовать бисектом перетаскивать конфиг. rps можно замерять куда быстрее, не дожидаясь провалов, за несколько секунд тестирования

Unix-сокет крайне нестабилен при высокой нагрузке. Те запросы, что проходят, отрабатывают быстро, но остальные тупо умирают. Столкнулся с этим во время «чёрной пятницы», около четверти запросов (всего было около 80k rps) не доходило до php-fpm, возвращая gateway timeout. Увеличение и вообще снятие лимитов не помогло, а при переключении на tcp-сокет время обработки запросов повысилось, но зато все запросы проходили как надо. Версию nginx сейчас не скажу, была последняя стабильная на тот момент из официальных репов.