Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Каждый из подпроцессов съедает 0% памяти и 0% CPU, при этом все ядра компьютера загружены. По-моему, это, как минимум, странно.
Думается мне, что оптимизировать надо было код, а не пытаться его распилить на кусочки, дабы уложиться в memory_limit.
PS: а вообще, вся суть статьи сводится к тому, что ты использовал Process из Symfony.
Думается мне, что оптимизировать надо было код, а не пытаться его распилить на кусочки, дабы уложиться в memory_limit.
PS: а вообще, вся суть статьи сводится к тому, что ты использовал Process из Symfony.
Спасибо за отзыв)
Действительно сложно отрицать несостыковку в показателях. Но скорее всего я просто поймал момент смены процессов или это баг самого htopa.
В качестве пруфа я и выложил реп. Можно потестить на своей тачке.
По поводу оптимизации.
Да, для каких-то постоянных решений, особенно которые будут закладываться в ядро системы, я бы ни в коем случае не стал бы такое использовать. И все тяжелые скрипты нужно переписывать и разносить логику.
Данный же случай — скорее исключение. Нужно было написать одноразовую команду по сбору своеобразного «среза» с текущего состояние БД.
В лоб не получилось. С оптимизацией, имхо, было бы гораздо больше геморроя.
По поводу постскриптума.
Да, суть уловил верно. Это своеобразный рецепт по использованию. Подобных решений я, к сожалению, не встречал. Решил, что некоторым может быть полезно.
Еще раз спасибо за дельный отзыв ;)
Действительно сложно отрицать несостыковку в показателях. Но скорее всего я просто поймал момент смены процессов или это баг самого htopa.
В качестве пруфа я и выложил реп. Можно потестить на своей тачке.
По поводу оптимизации.
Да, для каких-то постоянных решений, особенно которые будут закладываться в ядро системы, я бы ни в коем случае не стал бы такое использовать. И все тяжелые скрипты нужно переписывать и разносить логику.
Данный же случай — скорее исключение. Нужно было написать одноразовую команду по сбору своеобразного «среза» с текущего состояние БД.
В лоб не получилось. С оптимизацией, имхо, было бы гораздо больше геморроя.
По поводу постскриптума.
Да, суть уловил верно. Это своеобразный рецепт по использованию. Подобных решений я, к сожалению, не встречал. Решил, что некоторым может быть полезно.
Еще раз спасибо за дельный отзыв ;)
Неужели нельзя решить проблему с памятью средствами самого PHP, не прибегая к распаралелливанию процессов в принципе?
На каждый пакет из 50 entities тратится, в среднем, 190мб памяти, с каждым новым пакетом кол-во использованной памяти росло
И вместо того, чтобы найти причину, почему Doctrine (doctrine ведь?) сжирает ресурсы, было принято решение распараллелить процессы?
Да, Doctrine.
С одной стороны, да, было принято такое решение.
С другой стороны, не стали делать это лишь потому, что вариант с распараллеливанием был наименее затратным для одноразовой команды.
И ещё один момент)))
Жуть как хотелось попробовать (=
С одной стороны, да, было принято такое решение.
С другой стороны, не стали делать это лишь потому, что вариант с распараллеливанием был наименее затратным для одноразовой команды.
И ещё один момент)))
Жуть как хотелось попробовать (=
Ну да, наименее затратным.
А когда и параллельные процессы начнут жрать память, будете дальше распараллеливать и сервера закупать?
А когда и параллельные процессы начнут жрать память, будете дальше распараллеливать и сервера закупать?
наименее затратным для одноразовой команды
Для одноразовой команды достаточно было лимит оперативной памяти увеличить, костыль ничем не лучше и не худе вашего.
Возможно. Но давайте оставим такие решения на суд кодревью. Так или иначе, никто из комментаторов того кода не видел. А смысл обсуждать то, что не видели — практически нулевой.
Данная статья не об оптимизации, как я писал ниже.
Это даже не руководство. А просто мой личный опыт реализации работы компоненты на конкретном примере.
И нацелен он был не на умудрённых опытом кавалеристов с овер-9000ным уровнем скилла, а на людей ищущих примеров реализации асинхронности в php.
Данная статья не об оптимизации, как я писал ниже.
Это даже не руководство. А просто мой личный опыт реализации работы компоненты на конкретном примере.
И нацелен он был не на умудрённых опытом кавалеристов с овер-9000ным уровнем скилла, а на людей ищущих примеров реализации асинхронности в php.
Вот все говорят, что мол не ту проблему решал и т.п. А я похвалю — статья познавательная, личный опыт использования компонента Process для асинхронных задач был любопытен и подобная инфа может очень даже пригодиться.
Спасибо, что поделился!
Спасибо, что поделился!
Человек узнал про компонент Symfony и решил расказать о нем другим? На руководство по использованию компонента не дотягивает, хоть документация по нему и так прекрасна.
PS. Утечка памяти для Doctrine это обычное дело и обычно это можно решить немного погуглив. Одна из причин — identity map
PS. Утечка памяти для Doctrine это обычное дело и обычно это можно решить немного погуглив. Одна из причин — identity map
Не Identity map а Unit of work, которому она нужна. И это не утечка памяти, так как мы эту память высвободить таки можем, просто уничтожив UoW текущий.
Вся проблема заключается по сути в том что после каждой операции не чистили UoW, что подтверждается следующей цитатой:
То есть на каждый flush у нас в UoW крутилось все больше и больше объектов. Это увеличивает расход памяти и снижает производительность.
Вся проблема заключается по сути в том что после каждой операции не чистили UoW, что подтверждается следующей цитатой:
а с какой-то возрастающей прогрессией.
То есть на каждый flush у нас в UoW крутилось все больше и больше объектов. Это увеличивает расход памяти и снижает производительность.
Я именно об этом и говорил, только на более высоком уровне, оставив возможность читателю исследовать эту тему самостоятельно не привязываясь к контексту статьи. Но спасибо, что разложили конкретный случай по полочкам.
Спасибо большое за ценную обратную связь.
На досуге попробую решить проблему утечки памяти на описанном примере.
По теме хочу сказать лишь одно. Ребят, тема не «Оптимизация работы проекта с помощью асинхронного выполнения PHP скриптов» и не «Руководство по асинхронному выполнению PHP скриптов». Поэтому как-то неприятно, что ли, получилось.
Эта статья была создана исключительно ради того, чтобы на живом примере показать, как с помощью описанных компонент можно реализовать асинхронность. Причиной тому стало то, что ранее я с подобным опытом не сталкивался, поэтому решил поделится.
Если же у вас такого опыта более, чем достаточно — я очень вам завидую.
Но сарказм в данном случае не самое архитектурно красивое решение.
На досуге попробую решить проблему утечки памяти на описанном примере.
По теме хочу сказать лишь одно. Ребят, тема не «Оптимизация работы проекта с помощью асинхронного выполнения PHP скриптов» и не «Руководство по асинхронному выполнению PHP скриптов». Поэтому как-то неприятно, что ли, получилось.
Эта статья была создана исключительно ради того, чтобы на живом примере показать, как с помощью описанных компонент можно реализовать асинхронность. Причиной тому стало то, что ранее я с подобным опытом не сталкивался, поэтому решил поделится.
Если же у вас такого опыта более, чем достаточно — я очень вам завидую.
Но сарказм в данном случае не самое архитектурно красивое решение.
ну… я рад за вас, проекты типа php-pm уже довольно давно крутятся, у кого-то в продакшене, у меня вот есть так же небольшой проектик с reactphp где логика вынесена в воркеры. event loop на пыхе это уже довольно давно не новинка. Вот только большинство еще не хочет отходить от классической умирающей модели.
Хочу еще больше картинок с нулями и единицами в ленте
А почему нельзя было просто использовать какой-нибудь сервер очередй? Зачем нужно что-то с подпроцессами делать? Какие преимущества дает(кроме транспортных потерь у очередей, вестимо)?
Все 2800 объектов связаны между собой? Если нет, то можно ведь просто освобождать память перед обсчётом следующего.
выше в комментариях это уже обсуждалось. И что падение производительности связано с тем что доктрина хранит все объекты в UnitOrWork и что с каждой итерацией обход всех сущностей занимает все больше и больше времени. И просто про оптимизации алгоритма и т.д. говорилось. Но…
Мне вот к слову стало что-то любопытно… среди тех кто использует доктрину, какой процент людей потрудилось почитать документацию?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Асинхронное выполнение PHP скрипта на подпроцессах