использование exec для длительных скриптов

Question

использование exec для длительных скриптов

Я хочу получить некоторые данные и API и сохранить для этого пользователя в базе данных, это действие занимает случайное время в зависимости от времени, а иногда это занимает даже 4 часа,
Я выполняю сценарий, используя exec а также & на заднем плане в php,

Мой вопрос в том, что exec безопасен для длительных заданий, я мало что знаю о форке, процессах linux и т. Д., Поэтому я не знаю, что происходило внутри на ядрах процессора,

Вот то, что я нашел, что смутило меня,

http://symcbean.blogspot.com/2010/02/php-and-long-running-processes.html

Может кто-нибудь сказать мне, если я иду в правильном направлении с exec?

будет ли процесс убит сам после завершения скрипта?

Спасибо

1

cron exec php process ubuntu

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Хорошо, эта статья говорит о «деревьях» процессов и о том, как дочерний процесс зависит от того, как он порождает родителя.

Экземпляр PHP запускает дочерний процесс (через exec или аналогичный). Если он не ожидает вывода процесса, PHP-скрипт завершается (и ответ отправляется, например, в браузер), но процесс будет бездействовать, ожидая завершения дочернего процесса.

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

Затем автор статьи предлагает использовать демон и отделить дочерний процесс от родительского процесса.

Редактировать:

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

echo /usr/bin/php -q longThing.php | at now

Начиная слева направо.

эхо печатает в стандартный вывод (STDOUT) материал, который вы положили перед ним, чтобы …
echo /usr/bin/php -q longThing.php распечатает на оболочку /usr/bin/php -q longThing.php
| (конвейер) напрямую подает STDOUT предыдущей команды на стандартный ввод (STDIN) следующей команды.
в читает команды из STDIN и выполняет их в указанное время. at now означает, что команда будет выполнена немедленно.

В общем, это то же самое, что запускать следующую последовательность в оболочке:

at now — Открывает в приглашении
/usr/bin/php -q longThing.php — Команда, которую мы хотим запустить
^D (нажав Control + D) — чтобы сохранить работу

Итак, по поводу ваших вопросов:

Будет ли дочерний процесс немедленно уничтожен после завершения PHP-скрипта PARENT?

Нет.

Будет ли дочерний процесс вообще убит в какой-то момент в будущем?

Да. Apache позаботится об этом за вас.

Завершит ли дочерний процесс свою работу до того, как его убьют?

Может быть. Возможно, нет. Апач может убить его до того, как это будет сделано. Вероятность того, что это произойдет, возрастает с увеличением числа неактивных процессов и времени, которое требуется для завершения процесса.

Примечание:

Я думаю, что эта статья направлена в правильном направлении, но мне не нравится идея порождения процессов непосредственно из PHP. На самом деле PHP не имеет соответствующих инструментов для выполнения (длительной и / или интенсивной) работы bg. Только с помощью PHP вы практически не можете его контролировать.

Однако я могу дать вам решение, которое мы нашли для аналогичной проблемы, с которой я столкнулся некоторое время назад. Мы создали небольшую программу, которая будет принимать и ставить в очередь запросы на обработку данных (около 5 минут) и отчитываться о завершении запроса. Таким образом, мы можем контролировать, сколько процессов может быть запущено одновременно, использование памяти, количество запросов одного и того же пользователя и т. Д …

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

На внешнем интерфейсе пользователь будет проинформирован, когда запрос будет завершен путем длительного опроса,

2