Давно не интересовался темой. А в питоне появился полноценный сборщик мусора, или, кажется, его оттуда как раз недавно выпилили?.. Если последнее, то очень может быть связано с данной проблемой. Но мы тут можем только гадать)

Напиши в дев лист опенстека да и все.

У меня python 2.7.

Напиши в дев лист опенстека да и все.

Мне скорее всего ответят, что мой релиз опенстека (kilo) уже не поддерживается. Просто взять и обновить не получится, так как у меня тут некоторые свои патчи, которые сначала нужно портировать на новый релиз и протестировать.

В общем мне самому придётся это чинить.

В общем мне самому придётся это чинить.

Отпиши, пожалуйста, потом в топике, интересно.

Для питона можно попробовать использовать cProfile

У Светлова в блоге было пару статей на эту тему
http://asvetlov.blogspot.ru/2013/05/gc.html?m=1

Не valgrind, но хоть что-то - https://github.com/lmacken/pyrasite-gui.

Консольный вариан тоже есть - http://pyrasite.readthedocs.io/en/latest/MemoryViewer.html.

Tracking Down a Python Memory Leak

А в питоне появился полноценный сборщик мусора, или, кажется, его оттуда как раз недавно выпилили?

Что-то новенькое. Откуда дровишки?

Может быть спутал с Objective-c. Мне одинаково интересны оба языка)

Всё смешалось в доме Облонских...
В Swift, емнип, вместо сборщика мусора только счётчик ссылок запилили, под названием Arc («automatic reference counting»). А Питону, как и любому ЯП с виртуальной машиной, без GC никуда.

ТС'у прежде всего стоит проверить свои патчи, если память начала течь недавно.

Вот именно, что смешалось у кого-то... В первых версиях питоне не было сборщика мусора. Там был банальный подсчет ссылок.

Касательно Objective-C. В некоторых версиях для OS X была опциональная сборка мусора, которая включалась флагами компилятора. Но ее не было для iOS. Кажется, ее выпилили, начиная с какой-то версии и из десктоной версии Objective-C тоже, хотя точно не уверен. Только там не просто подсчет ссылок, а чуточка по-хитрее механизм, но он тоже недалеко ушел от подсчета ссылок.

Возможно, что в питончике тоже игрались, пытаясь ввести сборщик мусора, но особо не интересовался темой. Мне все равно.

Или ты примитивный подсчет ссылок готов считать за сборщик мусора?

Снобизма аромат неуловимый чувствую я, не вижу смысла отвечать поэтому.

В питоне сейчас есть неотключаемый счетчик ссылок + отключаемый GC (https://docs.python.org/3/library/gc.html)

ТС'у прежде всего стоит проверить свои патчи, если память начала течь недавно.

Память начала течь давно, просто только сейчас OOM-killer стал как-то недобро смотреть на процессы опенстека. И дело точно не в моих патчах.

Beyond repair

Если кому интересно...

Корень проблемы в том, что nova (как и другие компоненты опенстека) не удаляет записи об удалённых объектах из базы данных, а помечает их как удалённые. Не очень понятно кто и зачем это придумал, но вроде есть движения в сторону нормальной реализации.

Такой жор памяти у nova-scheduler в моём случае происходит из-за того, что nova-scheduler должен всегда знать на каких компьют-нодах какие инстансы работают. Для этого он периодически запрашивает все инстансы из БД. Естественно, фильтр !=deleted добавить забыли. Это починили начиная с liberty. Патчик я к себе стащил и всё стало сильно лучше.

Теперь про nova-api... Там жор памяти вызывается вот таким запросом:

2016-12-06 14:09:15.801 3363 INFO nova.osapi_compute.wsgi.server [req-8ca2611d-f485-4b24-949f-75c06d610162 5f9b66a5a2e045c485a5643428a6cc5e f4a196fddbdc483783ccfe425fb4cfe9 - - -] 10.208.38.1,127.0.0.1 "GET /v2/f4a196fddbdc483783ccfe425fb4cfe9/os-simple-tenant-usage?start=2015-05-01T00:00:00&end=2016-12-06T23:59:59&detailed=1 HTTP/1.0" status: 200 len: 17316087 time: 467.9599042

• https://github.com/cernops/nova-db-purge
• https://github.com/openstack/osops-tools-generic/blob/master/nova/openstack_db_archive.sh

Ни то ни другое пока не пробовал.

P.S. Похоже питон не возвращает системе однажды выделенную память даже если она больше не используется.
P.P.S. У меня в БД сейчас примерно 43000 удалённых инстансов.

Ах да, питоньи тулзы - лютое говно по сравнению с тем, что доступно для C/C++. Удалённую отдладку в pdb не завезли (есть криво работающие сторонние костыли), цепляться к уже запущенным процессам он не умеет, нормальных средств отладки утечек памяти я так и не нашёл. Всё, что было посоветовано и нагуглено - либо не завелось (nova-api и nova-scheduler падали при запуске), либо не дало полезной инфы.

Благодарю.

Всё, что было посоветовано и нагуглено - либо не завелось (nova-api и nova-scheduler падали при запуске), либо не дало полезной инфы.

как же ты отдебажил, методом тыка и догадок?

как же ты отдебажил, методом тыка и догадок?

Методом гуглинга и вдумчивого чтения кода.

openstack_db_archive.sh удалил не всё, но большую часть. Достаточно для того, чтобы прекратить жор оперативной памяти.

стало тоже интересно, и спросил у друга, опытного питон разработчика, про то что убрали ли сборщик мусора... " Не, не убирали, но всегда же можно потечь в стронней тулзе или создать хитрый глобальный объект, который содержит лишние ссылки, либо __delete__ как-нибудь не очень удачно переопределить "

Как-то интересовался темой. По ходу он про неиспользуемые переменные вспоминает когда память закончится.