PHP-FPM не отвечает, когда процессор загружен на 100% в процессах с низким приоритетом
У меня проблема, когда ЦП загружен на 100%: PHP-FPM не отвечает, даже процессы, использующие 100% ЦП, работают с самым низким приоритетом (+19).
Поясню: мой сайт запускает аудиоконвертер (ffmpeg) с помощью inotify + скрипт bash. Преобразователь работает с использованием "nice -n 19". Таким образом, загрузка процессора составляет 100%, но теоретически приоритет имеет PHP-FPM (приоритет по умолчанию равен 0).
Что происходит: зависает только PHP. Apache может реагировать на такие файлы, как JPG/CSS/JS. Линукс стабильный, другие ПО тоже. Все .php возвращают «504 Gateway Timeout» (браузер, ответ Apache). Apache открывает много экземпляров php-fpm и держит их открытыми.
30585 fedora 19 0.0 0.3 0:00.00 snippeter
30586 fedora 19 25.0 2.8 0:00.10 ffmpeg
15640 fedora 0 0.0 1.0 0:00.12 php-fpm
17174 fedora 0 0.0 1.0 0:00.10 php-fpm
20583 fedora 0 0.0 0.9 0:00.00 php-fpm
21072 fedora 0 0.0 0.9 0:00.00 php-fpm
21309 fedora 0 0.0 0.9 0:00.00 php-fpm
22601 fedora 0 0.0 0.9 0:00.00 php-fpm
23172 fedora 0 0.0 0.9 0:00.00 php-fpm
23277 fedora 0 0.0 0.9 0:00.00 php-fpm
24170 fedora 0 0.0 0.9 0:00.00 php-fpm
24823 fedora 0 0.0 0.9 0:00.00 php-fpm
24916 fedora 0 0.0 0.9 0:00.00 php-fpm
26589 fedora 0 0.0 0.9 0:00.00 php-fpm
%Cpu(s): 8.5 us, 4.5 sy, 85.6 ni, 0.0 id, 0.5 wa, 1.0 hi, 0.0 si, 0.0 st
Изменение приоритета php-fpm (renice), без разницы.
Я не знаю, что делать ... Я хочу запускать процессы в фоновом режиме, даже используя 100% процессора, но поддерживать нормальную работу PHP + Apache.
Сервер: Fedora 29, PHP 7.2.
1 процессор, это VPS.
Почему это на 100%?
Запуск фоновых процессов, но все с приоритетом +19 (приятно).
Какой VPS? Тот, который выделяет вам фактическое физическое ядро, тот, который выделяет вам часть ядра, или «разрывное» ядро, которое, вероятно, вызовет именно эту проблему? Вам также необходимо реализовать актуальный мониторинг ресурсов постоянный, чтобы проиллюстрировать проблему, подобную этой, поскольку случайные измерения на определенный момент времени точно не рисуют большую часть картины.
учитывая цену хостинга, я бы просто поставил на него еще один процессор, хотя бы для проверки
Это VPS на Vultr, KVM, так что дробь.
Но приоритет +19 для процессов с высокой загрузкой ЦП заморозит php-fpm? Я не понимаю, почему затронут только PHP. Все остальные программы работают нормально, получая больше циклов ЦП по запросу...
* Примечание: во время преобразования у меня есть один PHP-скрипт, работающий без ограничения по времени, только отслеживание и ожидание завершения процесса ffmpeg, но это почти 0% ЦП ... может ли PHP-скрипт, работающий в цикле, заморозить другие запросы?
Я знаю, что это не ответит на вопрос, но в целом я бы посоветовал вам перенести обработку ffmpeg на второй VPS, который обрабатывает только это, чтобы вы не мешали другому (казалось бы, более актуальному/критическому процессу, такому как как php-fpm)
Сказав это, ваша проблема мая связана не с процессором, а с памятью. Ffmpeg использует тонну оперативной памяти (вероятно, все, что доступно), поэтому, даже если у вас больше приоритет ЦП для php-fpm, может случиться так, что у него недостаточно памяти даже для запуска.
Да, я думал об этом, использовать другой VPS для конвертации файлов. Но проблема не связана с памятью. Конвертирую несколько файлов пакетно, аудиофайлы, но все маленькие MP3, 2-4 минуты, а на сервере при конвертации около 60% свободной оперативной памяти. Я просто не понимаю, почему зависает только PHP. Возможно, какая-то проблема со связью с Apache, даже Apache нормально отвечает на файлы, отличные от php.
вы можете использовать специальный сервис, такой как Amazon Elastic Transcoder,
Ответы 1
Решение найдено!
Проблема не связана со 100% использованием ЦП или только с одним ЦП. Поскольку у меня есть цикл, чтобы открыть каждый аудиоконвертер (файл bash) и дождаться его завершения, чтобы запустить следующий, PHP сессия заблокирован! Таким образом, когда другой PHP-скрипт в том же сеансе пытается выполниться, он не может прочитать файл сеанса, поэтому PHP зависает (ожидая доступа к файлу сеанса, пока не возникнет ошибка «Время ожидания шлюза»). Вот почему зависает только PHP, а не другие программы.
Чтобы исправить, мне пришлось запустить это перед основным циклом:
session_write_close();
session_start(['read_and_close'=>true]);
Итак, он записывает и закрывает файл сеанса, и снова читает его один раз, не блокируя его.
Это работает только в PHP 7+ и, очевидно, вы не можете записывать какие-либо данные сеанса. Или, после цикла, просто снова откройте сеанс с помощью session_start().
сколько процессоров в сервере?