DB
Почти узаконили ддос атаки
Size: a a a
2019 September 11
RB
Новые линуксы тоже обзавелись api для асинхронной работы с fs
Но в дистрибутивы типа редхата это попадет лет через пять )
AM
Новые линуксы тоже обзавелись api для асинхронной работы с fs
С разморозкой меня.
SA
Известно что питон не возвращает системе память, которую он у неё захавал - он сам ей рулит и переиспользует. Но вдруг есть какая-то хитрая функция, которая может вернуть свободную память в систему?
У меня в приложении используется Pillow для ресайза картинок. Причём я запускаю задачки ресайза в N-тредах, где N - число ядер. Иногда, похоже, прилетают довольно большие картинки, и при этом одновременно. В результате питон может захавать сразу N * ImageSize памяти.
И ладно бы оно захавало сколько надо для N * MaxImageSize и остановилось, но ведь нет - оно почему-то со временем начинает хавать больше и больше. Анализатор занятой памяти питона показывают, что под всякие питонячие структуры в приложении занято всего 30Мб. При этом процес занимает, например, 2.8 Гб памяти.
Подозреваю, что из-за фрагментации памяти, питон иногда не может "всунуть" новую картинку ни в один из своих свободных блоков памяти, и просто запрашивает доп. память у системы.
Как бы мне решить эту проблемку?
У меня в приложении используется Pillow для ресайза картинок. Причём я запускаю задачки ресайза в N-тредах, где N - число ядер. Иногда, похоже, прилетают довольно большие картинки, и при этом одновременно. В результате питон может захавать сразу N * ImageSize памяти.
И ладно бы оно захавало сколько надо для N * MaxImageSize и остановилось, но ведь нет - оно почему-то со временем начинает хавать больше и больше. Анализатор занятой памяти питона показывают, что под всякие питонячие структуры в приложении занято всего 30Мб. При этом процес занимает, например, 2.8 Гб памяти.
Подозреваю, что из-за фрагментации памяти, питон иногда не может "всунуть" новую картинку ни в один из своих свободных блоков памяти, и просто запрашивает доп. память у системы.
Как бы мне решить эту проблемку?
https://zapier.com/engineering/celery-python-jemalloc/ у меня была ровно такая же история (но не с пиллоу). Джемаллок помог. Но у меня он повел себя несколько иначе: общее потребление памяти увеличилось немного (процентов на 10), но таких вот псевдоликов больше не было
KK
https://zapier.com/engineering/celery-python-jemalloc/ у меня была ровно такая же история (но не с пиллоу). Джемаллок помог. Но у меня он повел себя несколько иначе: общее потребление памяти увеличилось немного (процентов на 10), но таких вот псевдоликов больше не было
Спасибо - почитаю.
KK
Сейчас у меня выгляди ситуация так, как "карта ляжет". Оно может либо за один день выжрать 7Гб или как сейчас - уже 2 дня в пределах 3Гб держится. Навреное зависит о того каким образом фрагментировалась память.
Была даже мысль при старте приложения сразу "захавать" память под N очень больших картинок, и потом "освободить" её. Что бы в будущем эта память использовалась. Хотя это как-то не очень надёжно - всё равно может наверное зафрагментироваться.
Была даже мысль при старте приложения сразу "захавать" память под N очень больших картинок, и потом "освободить" её. Что бы в будущем эта память использовалась. Хотя это как-то не очень надёжно - всё равно может наверное зафрагментироваться.
KK
Ха, долбанул по своему приложению доп. нагрузочку. И у него потребеление памяти с 3Гб упало до 1.3Гб - видимо где-то улучшилась фрагментация и питон смог освободить некоторые страницы памяти.
AS
Ха, долбанул по своему приложению доп. нагрузочку. И у него потребеление памяти с 3Гб упало до 1.3Гб - видимо где-то улучшилась фрагментация и питон смог освободить некоторые страницы памяти.
это без jemalloc?
KK
Без него, это уже запущеное два дня приложение
KK
Так то, на самом деле, питон освобождает и возвращает в систему память. Но только для объектов, которые больше 512 байт. Все объекты <=512 байт управляются в питоне специальным менеджером, который хитро раскидывает эти объекты, что бы уменьшить эфекты фрагментации. Вот эта память не возвращается в систему.
А для объектов большего размера используются стандартные C-шные malloc-и. И там проблема может быть такая-же как и в любом приложении - фргаментация. Система выделяет память большими кусками, и если ты в этом куске не осободишь хотя бы 1 байт - этот кусок будет считаться занятым и не вернётся в систему.
А для объектов большего размера используются стандартные C-шные malloc-и. И там проблема может быть такая-же как и в любом приложении - фргаментация. Система выделяет память большими кусками, и если ты в этом куске не осободишь хотя бы 1 байт - этот кусок будет считаться занятым и не вернётся в систему.
RB
это ты к тому что надо бы писать на сишечке? )
A
это ты к тому что надо бы писать на сишечке? )
Вообще все что связано с работой с памятью надо писать на сишечке или плюсах. Более того можно ещё и свои аллокаторы делать для наиболее оптимального использования.
KK
Нет, на C-шче такие же пробемы будут со стандартным malloc-ом в линухе
KK
Поэтому Редиски запилили jemalloc - он как-то лучше с фрагментацией борется
KK
А вот если я так буду запускать питон
LD_PRELOAD=/usr/local/lib/libjemalloc.so python your_app.py
то и все сабпроцессы, которые будет запускать это питон-приложение (например ffmpeg) тоже будут использовать jemalloc? Вроде как ENV переменные наследуются дочерними процессами, если их принудительно не переопределить при запуске саб-процессаin
Нет, на C-шче такие же пробемы будут со стандартным malloc-ом в линухе
можно попробовать маллок настроить:
man malloptKK
Ну мне проще бахнуть jemalloc - с ним без всяких настроек обещают "рай".
in
Ну мне проще бахнуть jemalloc - с ним без всяких настроек обещают "рай".
только массовые профилировки спасут родину
KK
Ну я под нагрузкой в продакшене сразу замечу как изменилось потребеление памяти.
RB
Ну мне проще бахнуть jemalloc - с ним без всяких настроек обещают "рай".
извините, но сразу вспомнилось
- первая часть моей фамилии это то что нам обещали, а вторая, то что мы получили
- гражданин райхер, пройдемте
- первая часть моей фамилии это то что нам обещали, а вторая, то что мы получили
- гражданин райхер, пройдемте