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

Question

После нескольких дней поиска в Интернете, переполнение стека, 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 отлично работает, когда я выполняю команды из workbench или любого другого приложения.

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

Я добавил память для 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 Глобальная конфигурация:

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, и у меня такая же проблема. Единственный способ сделать работу на сайте - перезагрузить всю систему.

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

Answer 1

После нескольких дней в поисках решения, проблема не была связана с инодов 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%" 

Answer 2

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

В течение нескольких недель сервер работал нормально, и внезапно он прекратил отвечать на запросы в Интернете. Я получал много сообщений «open socket #nnn left in connection» в сообщениях /var/log/nginx/error.log и «server received pm.max_children» в /var/log/php5.6-fpm.log

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

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

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