Постійно доводиться перезавантажувати PHP-FPM

У нас досить завантажений сервер, на якому працює nginx та PHP-FPM. У нас на цьому сервері є 6 веб-сайтів, на яких працює PHP-FPM та nginx. Програмне забезпечення - всі версії 3.8 та WordPress. Бази даних знаходяться на окремому сервері.

Тепер, оскільки це дуже популярні веб-сайти, ми зазвичай маємо 7-8 000 відвідувачів в Інтернеті одночасно, причому кожна сторінка в більшості своїй вражає базу даних. Я вважаю, що це причина наших проблем.

Оскільки у нас дуже багато великих баз даних на сервері MySQL, і тому що запити, чесно кажучи, можуть бути набагато кращими в програмному забезпеченні, я думаю, що MySQL час від часу не зможе своєчасно повернути результати PHP, створюючи ефект каскаду, який у підсумку змушує все просто зупинятися, поки ми не перезавантажимо PHP-FPM. Після цього ми знову почнемо працювати нормально.

Причина у мене виникають проблеми з усуненням цього в тому, що я не можу реально розрізнити нічого з журналів. У журналі повільних запитів MySQL я не бачу нічого цікавого, коли відбувається час простою. У журналах nginx я бачу тисячі записів про те, що запит на читання вичерпався або з'єднання вичерпано (до PHP-FPM). І в журналах PHP-FPM я бачу безліч рядків, в яких написано: "Час виконання вичерпано (31 сек), що закінчується

Тож на даний момент я просто повністю не знаю, де шукати проблему. Очевидно, що все, що відбувається, відбувається тому, що ці сценарії не виконуються досить швидко іноді (як правило, вони завантажуються за секунду, але трапляється щось, що призводить до збільшення часу завантаження). Це трапляється багато разів на день, і це стало для нас досить проблемою.

На даний момент у мене просто є кронтаб для обслуговування перезавантаження php5-fpm кожні 10 хвилин, що допомагає вирішити проблему з збоєм. Звичайно, коли PHP перезавантажується, nginx видає помилку шлюзу 502, тож це не так вже й багато рішення.

PHP працює кеш APC, якщо це має значення. Я прочитав у кількох плямах, що APC може спричинити зависання за певних обставин.

Будь-які покажчики будуть корисні. Мені дуже хотілося б не турбуватися про цю машину весь час.

Більше інформації можна отримати, звичайно. Просто дайте мені знати, що вам потрібно.

Оновлення: я щойно скопіював apc.php у веб-корінь і отримав доступ до нього, щоб переглянути нашу статистику. Все виглядало добре. Потім я натиснув на посилання, щоб перейти до статистики користувача і БОМ сервер миттєво повісив. Я перезавантажив php-fpm, а потім перезавантажив сторінку статистики користувача, і вона пройшла добре. Зачекав хвилину, знову перезавантажився, сервер знову завис.

Таким чином, це, безумовно, пов'язано з APC. Питання - як це виправити?

Налаштування APC:

[apc]
apc.enabled="1"
apc.stat = "1"
apc.max_file_size = "2M"
apc.localcache = "1"
apc.localcache.size = "256"
apc.shm_segments = "1"
apc.ttl = "3600"
apc.user_ttl = "7200"
apc.gc_ttl = "3600"
apc.cache_by_default = "1"
apc.filters = ""
apc.write_lock = "1"
apc.num_files_hint= "10000"
apc.user_entries_hint="10000"
apc.shm_size = "1G"
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.include_once_override = "0"
apc.file_update_protection="2"
apc.canonicalize = "1"
apc.report_autofilter="0"
apc.stat_ctime="0"

Оновлення 2: Ми досягли певного прогресу в цьому. Виявляється, що плагін кешування WordPress (W3 Total Cache) - це те, що спричиняло збої. Ми досі не знаємо чому, але з відключеною програмою ми працювали PHP вже майже 4 години, не маючи перезавантажень, жодних уповільнень та збоїв. Ми все ще використовуємо APC на форумах vBulletin, і жодних проблем там немає. Чи є спосіб, яким ми можемо визначити, Чому APC виходить з ладу? Я хотів би використовувати його в наших установках WordPress, але не ціною крихкої системи.

Ви використовуєте php-fpm, тому я пропоную бути більш агресивними щодо того, як довго дітям php-fpm дозволяється жити. Вам потрібно знайти солодке місце між коротко прожилими нитками / дітьми та стабільністю. Значення за замовчуванням php-fpm є щедрими для будь-якої виробничої системи, IMHO.

Я б зменшив кількість для pm.max_requests для ваших виробничих пулів. Я думаю, що за замовчуванням - 200. Я б почав з 50 і побачив, куди це тебе веде.

Якщо цього не додати / доповнити, ви також можете спробувати ці глобальні параметри (AFAIK - усі вони відключені за замовчуванням):

emergency_restart_threshold=3
emergency_restart_interval=1m
process_control_timeout=5s

Що це означає? Якщо 3 дочірника PHP-FPM обробляють вихід із SIGSEGV або SIGBUS (тобто збій) протягом 1 хвилини, тоді PHP-FPM повинен автоматично перезапуститися. Дочірній процес чекає 5 с на реакцію на сигнали від майстра.

Це повинно підтримувати ваш пул працівників PHP красивим, свіжим та чистим. Чим довше працівникові дозволяється подавати запити, тим нестабільнішими вони будуть. Також вищий ризик витоку пам'яті.

Ось приємний огляд усіх параметрів конфігурацій, про які я згадував тут, а також інших: http://myjeeva.com/php-fpm-configuration-101.html

Сподіваюся, ці поради допоможуть вам! Не забудьте налаштувати та спостерігати, на жаль, не здається, що для цього все є правило, є занадто багато змінних, які впливають на поведінку та стабільність PHP.