Почему веб-сервер глючит (Nginx + php5-fpm)?

Question

[Дмитрий]

Здравствуйте. До текущего момента стояла связка Nginx + Apache2. Апач стал есть очень много ресурсов со временем. Очень много раз читал про связку Nginx + PHP-FPM, и решил поставить её.
Что есть:
1) сайт с посещаемостью 80к в сутки
2) конфиг сервера: 32гб RAM, 8 ядер, SSD. Nginx 1.4.6, memcache, opcache включен

После долгой настройки fpm и nginx, имеются следующие конфиги:
Nginx:
конфиг сайта pastebin.com/u6BVkQzC
главный конфиг : pastebin.com/viyWGkjU
FPM:
главный www pastebin.com/Y7iEmndn
конфиг пользователя pastebin.com/QDkjxeNa

Когда поток пользователей перенаправляю на этот сервер, в top появляются процессы php5-fpm , и некоторые грузят почти все на 100%. Постепенно ответ от сервера из 60мс уходит до 2 секунд. Всё тормозит и глючит. В логах вот что:

*an upstream response is buffered to a temporary file /var/lib/nginx/fastcgi/9/00/0000000009 while reading upstream

load average больше 10
Подскажите, что не так сделано? Должно же быть как минимум лучше, чем в связке апача с nginx. Буду рад Вашей наводке.

UPD.
С буфером проблему решил, увеличил его, теперь load average <= 4. Это нормально для 730к просмотров страниц в день?

Comments

[ldv]

Что такое главный конфиг FPM?

[Дмитрий]

ldv: www.conf

[ldv]

Дмитрий: ok. Может я не вижу, но где этот пул используется в nginx?

[ldv]

Дмитрий: и что в логах php-fpm?

Answer 1

[Sanes]

Настройте для начала логирование медленных запросов.

Comments

[Дмитрий]

Sanes а разве это будет иметь значение? На апаче ведь быстро выполняется. Да и без нагрузки очень все быстро выполняется

Answer 2

[Anton B]

У вас запросы к fpm через сокеты, может быть у вас низкий лимит на открытые файлы? ulimit в linux

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

Comments

[Дмитрий]

Anton B ulimit 8192. Если не секрет, какая посещаемость и какое использование ресурсов при данной посещаемости?

[Дмитрий]

Anton B покопав, увеличил буферы, ошибок сейчас нет. Картинка следующая: c2n.me/3ywyk8L. В секунду примерно 30 запросов идёт. Я думаю многовато ресурсов ест. pastebin.com/hxQsvnQb вот настройки nginx

Answer 3

[Влад Животнев]

try_files
fastcgi_pass
include fastcgi_params; + fastcgi_param в одном location
ssi on;
error_log /dev/null crit;
access_log off
pm.max_children = 5

Эталонный сборок ошибок вида "как не надо делать" и "почему вам лучше использовать апач".
(справедливости ради, намек на правильную настройку самого fpm есть, но процессов мало и сокеты - жопа).

Ну а по сабжу - модель дисков в студию. Скорее всего, беда в них.

Comments

[Дмитрий]

Влад Животнев pastebin.com/tAWUdQW3 модель диска с системой, остальные диски такие же. На сайте используется Yii, в котором Active Record практически везде, за исключением сложных запросов. Попробовал заменить на обычное DAO, и закешировал полностью страницу - результат на лицо: siege говорит вот что:
siege -t 2M -c 30 site.info
pastebin.com/PDp9ya3k (с opcache)

Было так pastebin.com/PeNuaHAf (с opcache)
Могли бы указать, почему сокеты это плохо? Начитался очень много инфы, пишут, что в рамках одного сервера лучше использовать сокет.
А насчёт кол-ва процессов - ставил больше, load average просто улетал в небытие. Насчёт остальных параметров даже ничего не могу сказать, кроме как ssi off; Могли бы наставить на путь истинный?

[Влад Животнев]

Дмитрий: load average - это цифра, которой можно подтираться. Она нужна для того, чтобы реагировать на резкие её изменения.

Смотрите на время ответа и неответы. А солить железо - бестолку. Если больше процессов отвечают быстрее и неответов меньше - то пусть их будет больше.

Сокеты под высокой нагрузкой ведут себя хуже, чем tcp. TCP в линуксах тюнят все, кому не лень, на код про unix-сокеты все подзабили. К тому же (могу ошибаться, не помню уже) в fpm, скорее всего, однопоточный сокет, то есть одновременно может приниматься один запрос/отдаваться один ответ (обрабатываться внутри php - сколько угодно).

[Дмитрий]

Влад Животнев: спасибо, буду смотреть. Скажите, Влад, а чем Вам не нравится try_files? Из-за лишних проверок? fastcgi_pass так же не пойму, почему Вы включили в этот список. Искал исключения из правил, но не смог понять.

[Влад Животнев]

Дмитрий:
try_files там к черту не нужен, там нужно конфиг под проект написать, а не копировать.

fastcgi_pass - это, скорее, отсылка к тому, что используется unix-сокет. Самая протестированный и вылизанный по скорости код в nginx, опять же, в районе proxy_pass+http.

[Дмитрий]

Влад Животнев: спасибо за информацию. Кстати, увеличил количество дочерних процессов, вроде ещё меньше использует ресурсов процессора. Правда не доверяю тестам на одну страницу, нужно "боевое крещение"