Ошибка подключения: php_network_getaddresses: ошибка getaddrinfo: системная ошибка

Ошибка подключения: php_network_getaddresses: ошибка getaddrinfo: системная ошибка

Часть "System error" действительно сбивает меня с толку.

Я боролся с этой ошибкой несколько месяцев, она очень спорадическая. Похоже, это исходит от моего соединителя базы данных.

Перезапуск php-fpm, по-видимому, решает проблему примерно на 24 часа, пока он снова не начнет действовать. Я думал, что это может быть максимальное количество детей с php-fpm, но после проверки статуса php-fpm это не так.

Я пытался сопоставить ошибку с журналом ошибок syslog и nginx для приложения, у меня заканчиваются идеи. Любые идеи о том, как устранить эту проблему?


nginx php
person Tyson    schedule 07.12.2017    source источник

Ответы (2)


arrow_upward
3
arrow_downward

после некоторых копаний я думаю, что наша проблема заключалась в том, что в нашей конфигурации не было установлено max_requests, дети никогда не рециркулировались. У нас был установлен process_idle_timeout, но у нас были запущены некоторые скрипты в cron, которые поддерживали процессы в рабочем состоянии.

так что если для всех остальных:

// количество запросов, которые он обрабатывает до перезапуска процесса

pm.max_requests = 500;

// максимальное время жизни в качестве бездействующего процесса

pm.process_idle_timeout = 10s;
person Tyson    schedule 11.12.2017

arrow_upward
1
arrow_downward

эта проблема всплыла для нас, и это сбивало с толку, потому что было связано с подключением к Redis

Я знал, что проблема не в Redis, и подумал, что странно, что мы получили часть «Системная ошибка», как вы упомянули.

Я очень быстро изучил исходный код php-fpm, чтобы увидеть, что вызвало эту ошибку, и обнаружил, что она связана с поиском DNS (очевидно), но почему это может быть проблемой, если у меня есть «127.0.0.1 localhost» в /etc/ хозяева?

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

Я хотел бы убедиться, что ваши дети php-fpm умирают изящно, чтобы соединение можно было переработать. У меня также было net.ipv4.tcp_tw_recycle=0 в /etc/sysctl.conf, что, казалось, вызывало проблемы.

Короче говоря, проверьте lsof, чтобы увидеть, кто использует файловые дескрипторы, и если вы еще не увеличили их, вы, вероятно, можете их увеличить!

person Brandon Kruse    schedule 11.12.2017
comment
Брэндон, спасибо за ответ, я считаю, что это напрямую связано с детьми php-fpm, которые не перерабатывают себя из-за неправильной настройки с нашей стороны. Я опубликовал ответ, чтобы, надеюсь, помочь другим. - person Tyson; 11.12.2017