Контроль за процессами демонов через ps, pgrep. И снова о многопоточности демонов из под PHP

Бывало ли вам стыдно, когда на голубом глазу вы доказываете что-то кому то с пеной изо рта, а потом, спустя время понимаете, что несли дичь? 🤣 Впрочем мне похрен на стыд, потому что реализации и квалификация «оппонентов» были вообще чистым говном — только лишь контролем через файлы. А мои реализации контроля за процессами через ps aux + блокировка файлов были весьма и весьма неплохи, ни разу не ушатали системы «бомбанув» её своими форками, практически всё всегда было чётко и подконтрольно… Но… были странности 😊

Эти странности мы и разберем в этой статье. Речь кстати, не обязательно в контексте php, это касается любых процессов.

А причина странностей в микро задержках между фактическим запуском процесса и его регистрацией ядром ОС в таблице процессов. А также задержкой между его удалением из таблицы процессов после завершения процесса. Да, эти задержки есть! И поэтому ps, pgrep по факту отображают не моментальный снимок всех текущих процессов, а снимок блин таблицы в которой процессы регистрируются и разрегистрируются! А на это тоже уходит время! И «моментальность» — в данном контексте, это лишь речевой оборот и пренебрежение этой задержкой, поскольку она минимальна по времени. Так говорится, либо от незнания подробностей работы системы(грёбаные школоло писаки мануалов и «умных» книжек) , писаками про linux, либо как способ упростить материал для понимания новичкам. Аля: «моментальный снимок процессов», команда ps — юзайте на здоровье.

Моментальный? Ок. Значит можно надёжно контролировать количество процессов? Конечно! Только вот незадача — между реальным запуском и регистрацией пройдёт N милли/микро секунд, за которые вы теоретически можете шарахнуть ещё N «лишних» копий процессов, ага? Если они у вас отрабатывают и запускаются очень быстро. Обратная сторона этой медали — разрегистрация в таблице процессов — вы можете получать из неё инфу с гораздо бОльшим числом процессов, чем запущено на данный момент.

Вот такие странности. Так как же тогда эффективно и надёжно контролировать? Ведь это уже самый что ни на есть системный уровень, глубже некуда копать. Через файлы? Аля, всегда пишем в блокирующийся файлик количество и только по нему контролим или же, для каждого процесса создаём уникальный файлик и по ним контролим? Нет, это херня. Системы перезагружаются, файлы надо очищать, процесс может отвалиться в любой момент, эти и т.п. нюансы не будут отрабатывать нормально, вы их все никогда не обработаете под скоростные и надёжные задачи. Это можно и нужно делать, но вспомогательно, комбинировать файлами с блокировками — так, да! А основной контроль  всё же надо возлагать на таблицу процессов, учитывая эти задержки. Ведь именно в таблицу вы полезете смотреть через cli и визуализирующими таблицу процессов командами ps aux, pgrep, top, htop будете выяснять, управлять, убивать… Если конечно успеете до исчерпания ресурсов и краша системы попасть в терминал и набрать команды — то мало ли какой вы виртуозный программист 🤔

Демонизация PHP, распараллеливание, многопотоки, ограничение исполняемых процессов

Я хотел написать достаточно простенький скриптик^^^ — php демон, самозапускающийся, многопоточный, а со всеми нюансами вышел достаточно серьезный код.

Более продвинутый код, с фиксацией целей и отказов по ним, измерением скорости их обработки: https://github.com/avtobys/php-demon

Оставить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *