но это не значит, есть есть утечки...

А за неделю?

простите)

Да не всенормально

Только вчера запустил

Я бы сказал что программы в штатном режиме могут вполне себе так набирать памяти. Смотри дальше будут ли проблемы

tl;dr - узбагойся, утечки у тебя скорее всего нет

То есть эти цифры можно игнорировать???

+++

Оставь прогу работать неделю

И посмотри будет ли там 100 мб

Выделять память кусками одинакового размера. Выделить нужную память всю сразу целиком, а не постепенно кусками разного размера и т.д.
Например у меня, при создании zip-файла, очень сильно фрагментировало память хранение структуры директорий zip-файла в виде списка (дело было в питоне) мелких структур разного размера, по одной на файл. Я переделал это всё на один бинарный буфер (аля Vec<u8>), который требовал гораздо меньше аллокаций. Мне это помогло (мне фактически не нужна была структура директорий, а только байтики из которых она состоит, что бы записать в конец zip-файла)

Жду. Испытания не меньше месяца должно пройти. Подумал если на старте такое, может сразу можно это пресечь если это реальная проблема)

можно посмотреть код используемой асинк библиотеки, там должны быть какие-то нагрузочные тесты которые можно под себя подпилить + профайлер

Спасибо. Будем посмотреть

Ещё можно попробовать заюзать другой аллокатор. Например jemalloc. Мы его тоже для питона заюзали, т.к. он якобы немного лучше справляется с фрагментацией.

Но лучше бы убедиться что это именно фрагментация. В питоне это было просто - собрать в разное время статистику по числу объектов и их размеру. У нас она менялась очень мало, и была сильно ниже чем реальное потребление памяти. Так и догадались, что дело во фрагментации.

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

Надеюсь на подобный исход)

Ок