@rustlang_ru - страница 1204

Денис

подскажи лучше

Αλεχ

https://blogs.msdn.microsoft.com/alikl/2009/02/15/identifying-memory-leak-with-process-explorer-and-windbg/ - я вот к такому привык)

Αλεχ

правда, это уже наглеж)

Αλεχ

но очень уж удобно

Денис

@inv2004 зацени https://github.com/KDE/heaptrack , умеет ...Alternatively, you can attach to an already running process

Денис

но очень уж удобно

а чем это от валгринда принципиально отличается?

Денис

мб я чё-то не так понял, но по-моему то же самое примерно

Αλεχ

тебе не обязательно под валгриндом запускать

Αλεχ

ты можешь подключиться к проду который почему-то начал много жрать и снять дамп

Денис

... where <<PROCESSID>> is the process of w3wp.exe PID (process ID) that runs the leaking application

Αλεχ

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

Денис

=)))

Αλεχ

чет не понял что смешного

Αλεχ

кроме того, что чел зачем-то w3wp приплел

Денис

ну ты бы посмотрел статью перед тем как кидать :)

Αλεχ

ну чел дебажит веб-приложение

Αλεχ

только метод-то совершенно общий, я так дебажил демона

Αλεχ

там вообще была забавная штука с утеканиями кэшей ORM через замыкание на условие выборки из одной из таблиц

Денис

ну короче хорошо, что можно подключиться к работающему приложению, валгринд так не умеет

Денис

зато вон heaptrack умеет, правда там другие сложности

Денис

там вообще была забавная штука с утеканиями кэшей ORM через замыкание на условие выборки из одной из таблиц

беру свой смех обратно

Αλεχ

без полноценного GC такое вряд ли можно сделать

Αλεχ

а GC это оверхед

Денис

нам в любом случае к продакшену никто не даст подключиться

Денис

поэтому репродьюсим, а там уже хоть что делай )

Αλεχ

ну в моем примере нужно было 3-4 дня работы с продовским объемом данных чтобы кэши вылезли за 3гб и все свалилось с оом

Αλεχ

локально такое воспроизвести если и можно, то дорого

Αλεχ

плюс я не подключался к проду, я просто дамп оттуда забрал)

Денис

дык

Денис

зачем ждать оом?

Αλεχ

чтобы быть уверенным, что это утечка, а не просто временная аллокация большого количества объектов или режим работы GC

Αλεχ

если приложение жрет 300мб и не очищает их, это можно расценивать и как утечку, и как нежелание GC тратить время проца на очистку

Денис

а, то есть оно обычно норм работает, а потом бац — и 3 гига?

Andrew

Ещё можно форсануть гц, чтобы убедиться, что он ни при чем

Αλεχ

нет, оно работает, отъело 500, на аллокации гигабайта сжалось до 600, и такими вот скачками постепенно растет. Но у тебя получаетя на 600мб живых объектов пара сотен мегабайт утечки. Это сложно заметить

Αλεχ

короче, смысл в том, чтобы сигнал над шумом превалировал

Αλεχ

200мб утечки на 500мб живых объектов - незаметны

Αλεχ

2гб утечки на 500мб - сразу видны

Αλεχ

Ещё можно форсануть гц, чтобы убедиться, что он ни при чем

GC нельзя форснуть

Ευγένιος

Какой Gc? В расте?

Alexander

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

Andrew

GC нельзя форснуть

Можно профайлером точно

Αλεχ

Можно профайлером точно

Нет, нельзя

Αλεχ

https://github.com/dotnet/coreclr/blob/master/src/gc/gc.cpp - тут целых 16 тысяч строк сексуального удовлетворения кода, который сам знает лучше жалких человеков, когда ему запускаться

Αλεχ

https://stackoverflow.com/questions/334174/can-i-run-a-net-garbage-collection-from-windbg - собсна есть целый ответ

Andrew

https://github.com/dotnet/coreclr/blob/master/src/gc/gc.cpp - тут целых 16 тысяч строк сексуального удовлетворения кода, который сам знает лучше жалких человеков, когда ему запускаться

Ну формально ты прав, но фактически, я ещё ни разу не видел воочию такую экзотическую ситуацию, чтобы gc.collect() стабильно игнорировался