Процесс PHP Fpm убивает мой сайт: процесс заблокирован со статусом D

php linux ubuntu nginx

3197 просмотра

2 ответа

1089 Репутация автора

После нескольких дней поиска в Интернете, переполнение стека, Google. Везде не могу понять, что происходит с PHP-fpm после нескольких часов нормальной работы.

Описание проблемы:

У меня есть Ubuntu 16.04 VPS, где я установил PHP-FPM и Nginx, а также небольшой Redis-сервер для хранения сессий. У меня есть 4 сайта, работающих под PHP-Fpm. Все сайты хороши, только один из них имеет эту проблему.

PHP-FPM взаимодействует с Nginx с помощью сокетов.

После нескольких часов нормальной работы внезапно процессы PHP-FPM не работают и имеют статус D, когда я запускаю команду htop. Вот снимок экрана с выводом команды htop:

демонстрация

После поиска в интернете, я получил, что статус D означает, что процесс ожидает ресурс.

Я добавил больше памяти для MySQL Server, но ничего не происходит. Сервер MySQL в порядке, когда я выполняю команды из рабочей среды или любого другого приложения.

Возможно, это проблема с памятью?

Я добавил память для VPS, и теперь она работает с 6 ГБ памяти (большая часть памяти не используется). PHP-FPM продолжает иметь статус D после нескольких часов работы.

Возможно, это связано с открытыми файловыми дескрипторами?

Я изменил дескриптор количества открытых файлов на 2097152, что является очень большим числом. Я продолжаю получать ту же проблему.

Возможно, это проблема сокетов или проблема конфигурации Linux?

Я увеличил большинство параметров конфигурации Linux, как это:

# Increase size of file handles and inode cache
fs.file-max = 2097152

# unix sockets accept by default 127 connections.
net.core.somaxconn = 4096

vm.swappiness = 0
vm.vfs_cache_pressure = 50

#Needed by redis
vm.overcommit_memory = 1

#
# 16MB per socket - which sounds like a lot, but will virtually never
# consume that much.
#
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# Increase the number of outstanding syn requests allowed.
# c.f. The use of syncookies.
net.ipv4.tcp_max_syn_backlog = 8192

Но я продолжаю иметь ту же проблему. Вот что я получаю в журнале nginx:

2016/07/17 22:57:30 [alert] 1885#1885: *59394 open socket #156 left in connection 117
2016/07/17 22:57:30 [alert] 1885#1885: *59341 open socket #107 left in connection 118
2016/07/17 22:57:30 [alert] 1885#1885: *59385 open socket #148 left in connection 119
2016/07/17 22:57:30 [alert] 1885#1885: *59392 open socket #154 left in connection 121

Я перепробовал большинство рекомендуемых решений, найденных в сети, но безуспешно.

Я изменил эти параметры в PHP-fpm.conf.

emergency_restart_threshold = 30
emergency_restart_interval = 180
process_control_timeout = 30

Вот конфиг пула PHP-fpm:

pm = ondemand
pm.max_children = 30
pm.process_idle_timeout = 10s;
pm.max_requests = 500

Это мой конфиг сайта nginx:

fastcgi_buffers 256 16k;
fastcgi_max_temp_file_size 0;

    location ~ ^/index\.php(/|$) {
        fastcgi_pass unix:/var/run/php5-fpm-mysite.com.sock;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        internal;
    }

Nginx Global config:

worker_processes 2;
worker_rlimit_nofile 100000;

pid /run/nginx.pid;

events {
        worker_connections 1024;
        multi_accept on;
}

Последнее : до 2 недель у меня была Ubuntu 14.04, я обновил свой сервер до Ubuntu 16.04, и у меня много проблем. Но этот, я не могу точно понять происхождение этой проблемы.

Я использую Ocache для кеширования кода и увеличил все параметры, чтобы получить больше памяти, и веб-сайт работает нормально, а кэш-память никогда не заполнена.

Я уже много раз перезагружал сервер, чтобы применить конфигурацию.

Диск: заполнен на 50%. У меня много места.

Обратите внимание, что когда процесс PHP-fpm заблокирован, я перезапустил весь сервис, и через несколько секунд у меня возникла та же проблема. Я сделал то же самое для nginx, и у меня возникла та же проблема. Единственный способ заставить сайт работать - перезапустить всю систему .

Пожалуйста, любая помощь приветствуется!

Автор: skonsoft Источник Размещён: 17.07.2016 10:39

Ответы (2)


0 плюса

1089 Репутация автора

Решение

После нескольких дней поиска решения проблема не была связана с inode Linux, не связана с памятью и не связана с сокетами ...

Это связано с кодом приложения.

Я использую Symfony2 Framework, и по некоторым причинам я изменил параметр "auto_generate_proxy_classes" на true. И я отправил код в производство.

Если для auto_generate_proxy_classes установлено значение true, Doctrine будет проверять все прокси-классы и восстанавливать их каждый запрос. Поэтому, когда я получил много запросов, процессы php-fpm будут заново создавать эти классы одновременно. Так что процесс блокировался до тех пор, пока другой процесс не завершил генерацию кода.

Решение:

вместо:

doctrine:
    dbal:
        ....
    orm:
        auto_generate_proxy_classes: true.

Поместите конфигурацию Symfony2 по умолчанию:

doctrine:
    dbal:
        ....
    orm:
        auto_generate_proxy_classes: "%kernel.debug%"
Автор: skonsoft Размещён: 18.07.2016 08:56

0 плюса

719 Репутация автора

У меня была похожая проблема, и я попытался настроить большинство указанных выше параметров. Не работает Symfony, просто PHP 5.6 на Ubuntu 16.04 с nginx / php-fpm.

Сервер работал нормально в течение нескольких недель и неожиданно перестал отвечать на веб-запросы. Я получал много сообщений «открытый сокет # nnn оставлен в соединении» в /var/log/nginx/error.log, а «сервер достиг настройки pm.max_children» в /var/log/php5.6-fpm.log

Он работал на виртуальном сервере в Profitbricks с процессором AMD. После нескольких перезапусков и перезагрузок и нескольких часов безуспешно у меня кончились идеи, и я, наконец, позвонил в службу поддержки Profitbricks, чтобы выяснить, есть ли какие-либо проблемы с оборудованием или сетью. Ни о каких не сообщалось, но они предложили изменить тип процессора с AMD на Intel Xeon.

После того, как я перешел на процессор XEON, сервер перезагрузился и все заработало нормально.

Я до сих пор не уверен в том, что вызвало проблему (и, возможно, не удастся переключить процессоры на многих VPS), но, надеюсь, это решение может быть полезным для кого-то.

Автор: lfjeff Размещён: 10.02.2017 09:56
Вопросы из категории :
32x32