Почему большой расход RAM в фоновых PHP скриптах?

Question

[Андрей Раковский]

В фоне запущенно 300 PHP скриптов. В разных местах скрипта напичкан лог потребления памяти

$mem = round((memory_get_usage() / 1024000), 3) . ' MB';

В итоге все значения выдают от 5 до 6 мб. Т.е. получается 300 скриптов * 6 мб памяти = 1 800 мб потребляемой RAM.
Но команда free -m показывает, что используется 12-13 ГБ.

Есть подозрения, что это из-за MySQL т.к. каждый экземпляр скрипта тянет за собой соеденение с базой которое висит по 5-7 часов (время выполнения скрипта).
SHOW PROCESSLIST
показывает чуть более 300 процессов.

Есть вариант отказаться от постоянного соеденения с базой, написать API которое будет работать с этой базой. Т.е. фоновый пхп скрипт (которых 300 штук) будет работать не напрямую с БД, а по REST API. Это позволит избежать от большого кол-ва висящих соединений с БД.

Поможет это сократить потребление RAM или может быть причина не в этом?

Comments

[Андрей Раковский]

Спасибо, не знал)

Показывает, что мои скрипты занимают 0.1% т.е. это примерно по 32 мб. А MySql 224 мб.

Как бы и не сильно много но всё таки почему memory_get_usage() в коде показывает 5 мб, а процесс в общем занимает 32 мб?

[Андрей Раковский]

Лентяй, хм, ну если так, тогда остаётся только расширяться на другие сервера. Печально.

Answer 1

[Pretor DH]

Как на меня то 300 штук фоновых это многовато. Нужно ли столько в риллтайм?

Все запросы не риллтайм к фоновому скрипту - выделить, объединить в queue и/или перенести на исполнение rest server/service. Пусть фоновый скрипт/сервис/сервер (в единственном или небольшом числе) исполняет их потихоньку вытягивая из очереди.

P.S. Просто перенеся функциональность фонового скрипта на rest api ничего не поменяется. Будет тоже количество соединений. И "те же грабли, только в профиль."

Comments

[Андрей Раковский]

Сейчас 300 соединений висит постоянно, а так будет одновременно висеть по 20-50 соединений.

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

[Pretor DH]

Думаю дело не совсем в соединениях. А в количестве запущенных процессов и к каждому ещё php интерпретатор. Плюс нагрузка на многозадачные переключения.

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

[Pretor DH]

Как написали умные люди:

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

Потому вывод:
- к базе подключаться асинхронно;
- формировать очередь задач;
- не запускать одинаковых обработчиков параллельно;
- написать асинхронный менеджер процессов;
- держать в фоне малое количество параллельных процессов;

Answer 2

[Stalker_RED]

Ваши фоновые процессы в основном пишут, или читают?

Запросы по rest API либо будут порождать новые подключения каждый раз, либо, если обращаетесь к демону, могут мешать друг-другу и выстраиваться в очередь.

Возможно, стоит воспользоваться чем-то типа gearman?

Comments

[Андрей Раковский]

В большинстве случаев пишут.
Собственно для фоновых задач я и юзаю gearman. Впринцепи можно реализовать три воркера, один на запись, второй на чтение и третий на изменение что позволит не плодить большое кол-во соединений. Но будет создаваться очередь и соответственно будут задержки, а REST API может обрабатывать одновременно много запросов.

Нужно в общем подумать.

[Stalker_RED]

Андрей Раковский, ну тут уж надо решить, что вам дороже - скорость или память. И можно ли поднять скорость еще, если оптимизировать процессы записи/чтения. Происходят ли блокировки, что там с индексами происходит и так далее. Может вам выгодно будет сделать чтение по требованию, затем лок, запись большой пачкой, (однократное обновление индексов), и снова чтение. Или наоборот.
Может структуру таблиц поменять, или бд. Или добевить прослойку в виде redis, например. Без подробностей задачи можно только гадать.

Answer 3

[Antonio Solo]

со стороны клиента открытое соединение с БД это просто открытый сокет. так что тут вряд-ли проблема.

зачем 300 "висящих по 5-7 часов" скриптов ? Они усиленно трудятся в это время ?

Comments

[Андрей Раковский]

Но я же грешу на MySQL а не на клиентскую часть.

Да, практически каждую секунду происходят какие-то действия. Получение данных с БД, со стороннего API, запись в базу, отправка данных по API и т.д.

[Antonio Solo]

Андрей Раковский,

free -m - покажи полный ответ

[Андрей Раковский]

Antonio Solo,

[Antonio Solo]

Андрей Раковский, процессами у тебя занято 8407 (8407+171)

memory_get_usage показывает использование памяти структурами PHP, а не всем процессом

[Antonio Solo]

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

Answer 4

[synapse_people]

если процессы форкаются, то память шарится

Answer 5

[Андрей Раковский]

Ок, допустим 32 гб мне хватит примерно на 900-1000 процессов (задач). Меня это устраивает, но тут появилась новая проблема.
Прошло немного времени и при таком же кол-ве задач памяти стало пожирать раза в 2-2.5 больше.


Смотрю htop и вижу, что у mysql висит не один процесс как раньше, а много, каждый из которого занимает около 300 мб памяти.

Answer 6

[Игорь Русинов]

Предполагаю, что 5-6 Мб на процесс не так и много, эту память могут просто занимать загруженные библиотеки и модули вашего приложения. Для проверки этой гипотезы создайте скрипт с загрузкой тех же библиотек, что используется в ваших фоновых скриптах, но не извлекающий ничего из базы данных, и замерьте использование памяти. Но, если скрипты начинают использовать больше памяти со временем, то возможно вы не очищаете какие то переменные, например есть массив, в который складываются какие-то данные на каждой итерации, но не очищаются в конце. В таком случае, я думаю, что проблему нужно искать в вашем коде.