A
System.gc() в джаве просто ставит флажок что неплохо бы было провести отчистку. Кажется, уместно после аллокации большого количества объектов
по пробкуй написать 2 раза подряд)
Size: a a a
2021 January 22
ES
Deniss
да, с CPython имплементацией - все чистится
Вроде CPython умеет считать ссылки и, например, закрывать файлы, на которые больше никто не ссылается. Возможно, что-нибудь такое происходит с нативными буферами или чем-то таким, типа with забыли
D
спасибо за ответы
D
по пробкуй написать 2 раза подряд)
Лучше тюнить GC по-нормальному :)
IV
pypy жрет память как не в себя
A
Лучше тюнить GC по-нормальному :)
я был молод и глуп, поддерживал java applet.....
IV
Deniss
Привет.
Много читаю, сам не пишу. Знаю, что на этом канале есть Python специалисты. Хотел бы спросить вопрос связанный на тему memory leak/garbage collection.
На моем новом проекте используется Python. (Я сам не являюсь разработчиком Python). Один из сервисов приложения с CPython перевели на PyPy, чтобы сделать его более производительным.
Обнаружили, что сервис, запущенный на Pypy потребляет память так словно там есть memory leak. Однако, сервис запущен на PythonC работает иначе и с памятью все в порядке.
Немного изучив то как работает GC в PythonC/Pypy решил собрать метрики с помощью memory_profiler и понять в чем разница.
В итоге, обнаружил, что память затраченная на выполнение socketio.emit(source, payload, broadcast=True) только растет и практически не освобождается.
есть способы как заставить GC работать по другому, и я делал пару экспериментов, и все равно не добился результата.
Я не уверен, что запускать gc.collect() с периодичностью считается правильным.
Я также не уверен, что проблема в самом socketio package, и тем как он работает с PyPy.
Возможно нужно заставить работать GC правильнее, но мануально управлять памятью не хотелось бы.
Буду рад любым идеям.
Много читаю, сам не пишу. Знаю, что на этом канале есть Python специалисты. Хотел бы спросить вопрос связанный на тему memory leak/garbage collection.
На моем новом проекте используется Python. (Я сам не являюсь разработчиком Python). Один из сервисов приложения с CPython перевели на PyPy, чтобы сделать его более производительным.
Обнаружили, что сервис, запущенный на Pypy потребляет память так словно там есть memory leak. Однако, сервис запущен на PythonC работает иначе и с памятью все в порядке.
Немного изучив то как работает GC в PythonC/Pypy решил собрать метрики с помощью memory_profiler и понять в чем разница.
В итоге, обнаружил, что память затраченная на выполнение socketio.emit(source, payload, broadcast=True) только растет и практически не освобождается.
есть способы как заставить GC работать по другому, и я делал пару экспериментов, и все равно не добился результата.
Я не уверен, что запускать gc.collect() с периодичностью считается правильным.
Я также не уверен, что проблема в самом socketio package, и тем как он работает с PyPy.
Возможно нужно заставить работать GC правильнее, но мануально управлять памятью не хотелось бы.
Буду рад любым идеям.
https://doc.pypy.org/en/latest/gc_info.html#minimark-environment-variables попробуй поиграться с этими параметрами, обычно помогает
D
я был молод и глуп, поддерживал java applet.....
Слышал про случаи, когда GC тригерили генерацией мусора в память. Но это прямо костылище 😁
D
https://doc.pypy.org/en/latest/gc_info.html#minimark-environment-variables попробуй поиграться с этими параметрами, обычно помогает
да, читал про эти параметры и пробовал менять их. Запускал тест на 12 часов. Не заметил разницы, но возникла мысль попробовать поиграться еще раз и запустить сервис на более долгое время. Как раз выходные впереди :) спасибо
NK
по пробкуй написать 2 раза подряд)
?
A
когда писал один раз. gc не вызывался, возможно просто ставился флаг, а вот повторный вызов реально чистил память
IV
Deniss
да, читал про эти параметры и пробовал менять их. Запускал тест на 12 часов. Не заметил разницы, но возникла мысль попробовать поиграться еще раз и запустить сервис на более долгое время. Как раз выходные впереди :) спасибо
обычно pypy отжирает память до максимума, а но потом не растет. Тюнинг PYPY_GC_MAX / PYPY_GC_MIN должен помочь
NK
когда писал один раз. gc не вызывался, возможно просто ставился флаг, а вот повторный вызов реально чистил память
Мне кажется система лучше меня знает когда GC вызывать, я лишь подсказываю
A
Мне кажется система лучше меня знает когда GC вызывать, я лишь подсказываю
я уже не вспомню зачем, но очень надо было в конкретном месте, год 2008 был на дворе
D
обычно pypy отжирает память до максимума, а но потом не растет. Тюнинг PYPY_GC_MAX / PYPY_GC_MIN должен помочь
супер, спасибо. надеюсь поможет
D
@classmethod значит ли это что для этих параметров у pypy нету default значений? (в том случае когда мы явно не прописываем значения через env vars)
АА
когда писал один раз. gc не вызывался, возможно просто ставился флаг, а вот повторный вызов реально чистил память
такое может быть, финализатор работает после первого gc.collect()
второй gc.collect() как раз и доберет память
второй gc.collect() как раз и доберет память
IV
Deniss
да, читал про эти параметры и пробовал менять их. Запускал тест на 12 часов. Не заметил разницы, но возникла мысль попробовать поиграться еще раз и запустить сервис на более долгое время. Как раз выходные впереди :) спасибо
дефолты точно есть, но я их не знаю. попробуй посмотреть что дает
gc.get_statsA
такое может быть, финализатор работает после первого gc.collect()
второй gc.collect() как раз и доберет память
второй gc.collect() как раз и доберет память
звучит разумно
АА
звучит разумно
как там было, если ты хочешь вызывать gc.collect() - либо ты полностью даешь себе отчет что ты делаешь и зачем, либо от безысходности и совсем не понимаешь что делаешь