PHP freaking (соединение отключено, соединение заброшено) в IIS 7.5

Question

У меня возникли проблемы с IIS и PHP (плюс com dll). Слишком много сбоев dll COM, но Я думаю проблемы не из-за этого (я отключил быструю защиту от сбоев), потому что dll всегда терпела крах, в то время как проблемы начались около трех недель назад, когда мы достигли около 15.000 пользователей в день ,

Случается, что внезапно все .php-файлы перестают отвечать на запросы, и сервер может обслуживать только статические .htm-файлы, что указывает на наличие проблемы с php (php-cgi.exe).

Это почти всегда происходит в часы пик (3-4-5 вечера), когда Google Analytics показывает 180-220 «онлайн-пользователей». Когда это происходит (из-за того, что я имею в виду PHP), я вижу в диспетчере задач сервера, что вместо обычных 10-12 процессов php-cgi.exe они пикируют до 30 или 40 процессов php-cgi.exe (~ 30 MB RAM каждый), что, как мне кажется, происходит потому, что php-cgi.exe перестает обрабатывать запросы. Сервер имеет в общей сложности 8 ГБ оперативной памяти.

Журналы ошибок включают в себя как connection_abandoned_by_regqueue и connection_dropped и если я не вручную перезапустить IIS или DefaultAppPool, ошибка повернет большую часть времени в DefaultAppPool не доступен 503

Один вопроса заключается в том, что в средстве просмотра событий я никогда не получаю сообщение от WAS о том, что defaultapppool был отключен, поэтому я мог подключить к нему задачу (перезапуск пула), а в консоли управления IIS я никогда не вижу, что defaultapppool отключен, несмотря на то, что он отображается как отключенный в журналах.

Я играл с таймаутами, но, похоже, ничего не понял.

Мои нынешние теории:

1) PHP выкрутасы с большим количеством пользователей (Windows, IIS) и не может справиться с этим

2) грохот из .dll вызывает проблемы, когда многие пользователи онлайн

3) Совместимость с php + iis не очень хороша в больших объемах, хотя я не считаю, что 15 тыс./сутки слишком много пользователей. Я должен отметить, что большинство запросов берут от 50 до 300 миллисекунд.

версия для PHP 5.3.19 установлена ​​через WebPI, версия для Windows - это Windows 2008 R2 64bit.

По какой-то странной причине блокнот ++ показывает строки запроса заброшенных/отключенных запросов, в журнале httperr в не скопированной шестнадцатеричной форме (запросы - UTF8 - греческий), а в обычных журналах строки запроса - оба видимый и скопируемый. снимок экрана приведен ниже.

Я также предоставляю второй скриншот с текущими настройками

HTTPERR файл_журнал ... Ошибки начинаются с соединением упали, а затем чуть позже с подключением заброшена http://img32.imageshack.us/img32/3796/9nkv.jpg

на втором скриншоте моего тока настройки: 1) активированные расширения php, 2) defaultapppool (пул, на котором запущен веб-сайт); 3) настройки php fastcgi и 4) пределы времени выполнения php. http://img34.imageshack.us/img34/2531/o6d1.jpg

Последнее изменение настроек сегодня состояло в автоматической утилизации defaultapppool каждые 3 минуты и отключении динамического сжатия содержимого. Посмотрите, как это пойдет.

Если у кого есть какие-либо намеки/идеи по решению, я был бы признателен за это!

Заранее спасибо.

Answer 1

Проблема была вызвана лимитом 32 процессов для php-cgi.exe в функции FASTCGI диспетчера iis. Увеличение до 64 для решения проблемы временно. Причина, по которой я получил до 32 обработанных, - это то, что веб-сервис является тяжелым CPU. Наконец, перейдя на выделенный сервер с большим количеством ядер, и больше бара было окончательным решением.

Answer 2

Могу ли я предложить перейти к 5.3.27 (окончательный выпуск 5.3) и посмотреть, исправляет ли это это? Слишком много ошибок при сбое, которые были исправлены между 20 и 27 для подсчета. Возможно, это будет очевидное решение, но стоит того.

Answer 3

1. Избегайте использования php FastCGI в iis. Скорее всего, вы получите лучшую производительность с кешированием php вместо fcgi.
2. Это звучит пугающе похоже на атаку Slow Loris.
3. Возможно, вам потребуется просмотреть настройки тайм-аута и убедиться, что fcgi правильно освобождает соединения. http://php.net/manual/en/mysqlnd-ms.pooling.php
4. Также может быть вызвана неисправной dll.
5. Также стоит запустить полную проверку памяти, поскольку я видел ошибочный барабан.