18 ноября 2007 в 15:19
Вот этот странный баг не даёт покоя drupal.ru последнее время - проявляется в ошибках 404 и 500 на некоторых страницах. Другим сайтам хостинга помогло увеличение временных лимитов fastcgi_*_timeout и буферов в nginx, но на drupal.ru проблемы сохранились. Пока сайт не перенесён на новый сервер, попробую собрать на Gentoo новое ядро.
Комментарии
Таймауты в PHP тоже достаточные? Памяти хватает? Ограничение по кол-ву одновременных соединений, процессов?
"Connection reset by peer" - это ведь значит, что backend отвалился, а не только nginx'у надоело ждать от него ответа.
Угу, именно так, перезапуск fastcgi исправляет ситуацию на некоторое время. Но нельзя сказать, что fastcgi полностью подвисает, поскольку остальные сайты на php сохраняют работоспособность. Глюки сейчас проявляются только на drupal.ru. Лимит памяти в php - 48М, имхо достаточно. Текущие настройки fastcgi: 15 процессов, 1024 запроса до перезапуска каждого процесса (пробовал как уменьшать так и увеличивать оба параметра, от 5-30 процессов, до 512-16384 запросов). Не помогло.
попробуй пхп пересобрать
у меня была версия 4, вис постоянно
на 5й пока норм.
Запускаю через spawn-cgi
Также запускаю через spawn-fcgi, PHP 5.2.4_p20070914-pl2-gentoo
Глюки, значит, локальные, в пределах одного сайта.....
Ограничения на коннекты к БД есть? Сама БД не валится в это время?
Поделись конфигами nginx, PHP и MySQL (в приват)?
А что показывает top и netstat во время проблем?
В top ничего отличного от нормы, загрузка проца не выше обычного. Вывод netstat внимательно не разбирал, на первый взгляд общение nginx и fastcgi идёт нормально.
Вот в сислоге кстати что нашлось неоднократно:
php-cgi[15845]: segfault at 00002c9c700e3fc8 rip 00000000005fe05f rsp 00007fff3dfb3030 error 4
Конфиги не секретны, кидаю сюда. Вот только чего-то я сегодня правил и похоже глючить перестало (понять бы ещё что правил и перестало ли?)
Я бы попробовал так
nginx.conf
events {
worker_connections 1024; # если в spawn-fcgi.conf PHP_FCGI_MAX_REQUESTS=1024, то зачем зедсь бОльшее число?
use epoll; # типа быстрее других
}
http {
keepalive_timeout 5 5; # кроме самой страницы ведь тянутся ещё и картинки и пр. мелочь - вот и пусть идут в одном соединении
reset_timedout_connection on; # не все клиенты умеют закрывать соединения.....
client_body_buffer_size 256k;
client_max_body_size 10m; # зачем там было 48m ? Здесь такие большие файлы загружают?
large_client_header_buffers 8 16k;
gzip on;
gzip_comp_level 5;
gzip_min_length 4096;
gzip_proxied any;
gzip_types text/plain text/css application/x-httpd-php application/x-javascript application/xml;
# гзипуем всё, что больше 4096 байт (т.е. кроме мелких js и картнок)
}
Число рабочих процессов уже увеличил, а число коннектов такое большое, по той причине, что на машине живут несколько сайтов не на PHP, в т.ч. сайт отдающий только статику (картинки), причём дохрена отдающий. Хотя возможно 16384 тож много, попробую уменьшить. client_max_body_size - на drupal.ru не загружают, но это нужно для другого сайта. Остальные части конфига осмыслю, попробую, спасибо.
Почти все параметры можн устанавливать на уровне конкретного server, а не только глобального http.
Вот, кстати точно, это я переконфигурю под виртуальные хосты.
Segfault очень часто сопутствует генте - если собирать все из исходников то весьма вероятно можно получить непредсказуемый результат, у меня хоть и несколько серверов на генте работают, но очень часто я натыкался на segfault при своих экспериментах, да и обновлять потом все это очень долго и неудобно, путем долгих мучений пришел к выводу что сегодня лучше убунта-редхет-дебиан...
Или вполне возможно что nginx просто не может дождаться результата от php и обрывает по тайм ауту.
Если дело действительно в segfault - то надо убрать из /etc/make.conf все левые флаги оптимизации и из php тоже все ненужное, потом нажать emerge --sync и пересобрать все типа emerge -eN world, но там уже очень долго ждать.
Сервер достался уже с Генту на борту. Пришлось срочно изучать её методики работы. Так я тоже на дебиане ставлю сервера, исходя из принципа, что майнтенеры пакетов лучше разберутся в сборке, пусть в результате и будет оно медленней работать
Всё прочитал. Люблю слушать когда умные люди говорят - может и я чему научусь.
Влад, не смущай
После не особо успешной борьбы с этим fastcgi я себя и так чувствую полным идиотом 
Может-таки вернуть backend на Apache?
Собрав с минимумом модулей и отдав авторизации/реврайты/доступы/и т.п. nginx'у. Этот вариант проверен годами и стабилен как скала.
Уже договорился о переезде сайта со Stalker-g2. У него как раз так - Апач после Nginx.
Но со старым сервером проблема остаётся - просто любопытно уже добиться адекватной работы Drupal с Nginx.
судя по всему работа php в режиме fast-cgi зависит исключительно от положения звезд
Также поймал проблему с нехваткой nginx_worker_connections при работе торрент-трекера. Правда нагрузка там тоже дай боже ...
Увеличение числа воркеров в nginx & fastcgi результатов не дало ...
Столкнулся с той же проблемой при замене ядра с 2.6.18 на 2.6.22 ... на днях попробую откатится обратно или раньше, как советовали здесь
http://www.lexa.ru/nginx-ru/msg11835.html
по дефолту максимальное число коннектов в ядре ограничено, его надо увеличить