У меня были случайные 500 Internal Server ошибок 500 Internal Server на моих сайтах на основе PHP / MySQL на разных общих хостах. Я использую PHP 5.2.17 через CGI / FastCGI на общем сервере Linux. Когда я смотрю в журналы, я вижу следующее:
[error] [client 75.71.176.224] (104)Connection reset by peer: FastCGI: comm with server "/dev/shm/blackmou-php.fcgi" aborted: read failed, referer: ... [error] [client 75.71.176.224] FastCGI: incomplete headers (0 bytes) received from server "/dev/shm/blackmou-php.fcgi", referer: ... [error] [client 75.71.176.224] (104)Connection reset by peer: FastCGI: comm with server "/dev/shm/blackmou-php.fcgi" aborted: read failed, referer: ... [error] [client 75.71.176.224] FastCGI: incomplete headers (0 bytes) received from server "/dev/shm/blackmou-php.fcgi", referer: ...
Кто-нибудь знает, как это решить?
Эта проблема, как правило, не только специфична для узла, но и зависит от разработчика, в зависимости от конфигурации. Однако некоторые хосты довольно строгие с FastCGI и ограничивают ваши возможности. Как правило, проще запускать без использования FastCGI и просто использовать mod_php, если у вас нет необходимости использовать FastCGI в вашем приложении.
Нам нужно будет увидеть вашу обертку fcgi (что находится в /dev/shm/blackmou-php.fcgi) или .htaccess для нереста FastCGI, чтобы лучше помочь вам, не зная, какие файлы и код, который есть в тех файлах, с которыми возникает проблема. Также используют ли ваши хосты Apache, LightHttpd или Nginx (или комбинацию)? В этот момент я настоятельно рекомендую обновить, чтобы использовать PHP 5.3.9+
Поскольку это может быть вызвано любым количеством проблем, FastCGI эффективно предотвращает атаку вашего сайта / скриптов путем отказа в обслуживании или сбоя из-за утечек памяти и т. Д. (EG: пытается обрабатывать 80 000 подключений, просто снижая и ограничивая число запросов или застревание в бесконечном цикле путем тайминга и завершения процесса)
Эта ошибка, в частности, вызвана, как правило, idle_timeout (30 секунд по умолчанию) или максимальным количеством дочерних процессов. Это также может быть вызвано тем, кто запускает длинный сценарий и закрывает свой браузер / соединение до завершения скрипта.
FastCGI запускает свою оболочку процесса, выполняет команду, время до завершения процесса, соединение рассматривается как сброс одноранговым узлом.
Другим примером является то, что максимальные дети (maxProcesses) достигнуты (EG: на многих сайтах показано 2 или 4 в качестве примера, когда на самом деле вам может понадобиться 20 или 50 в зависимости от среднего трафика). Если все дети в настоящее время активны и дополнительный запрос / соединение ограничено maxProcesses, на которое FastCGI не будет делить активных дочерних элементов, поэтому он должен сначала либо завершить процесс, либо запустить новый дочерний процесс, либо отказаться от запроса, в зависимости от ваших конфигураций.
Вот еще информация о настройках:
http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
http://www.fastcgi.com/drupal/node/10
Пример упаковки
PHP_FCGI_CHILDREN=0 #no limit export PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=10000 export PHP_FCGI_MAX_REQUESTS
ОБНОВИТЬ
Чтобы добавить к этому, это также может быть вызвано ограничением памяти php
Если вышеуказанное не решит вашу проблему, обновите php.ini, чтобы увеличить memory_limit
для тех, кто ищет дополнительную информацию:
в моем случае возникла проблема с кодом. При входящем HTTP-запросе из внутреннего кода делался вызов внутреннего URL-адреса, создавая тем самым тупиковую ситуацию.
Это привело к зависанию процессов PHP и привело сервер к работе. мы использовали file_get_contents ('URL') или cURL () в нашей функции обратного вызова. Затем мы заменили его простой функцией drupal, которая предоставила нам значения из БД.
Инструмент NewRelic помог мне определить функцию, на которую уходило много времени, чтобы ответить.
Другим способом определить это было бы сделать drupal_watchdog для нашей функции обратного вызова и проверить журналы, когда сервер разбился.
надеюсь это поможет.