Могу ли я узнать все объекты в поколении сборщика мусора? - PullRequest
4 голосов
/ 23 ноября 2011

Я был поражен мыслью, что было бы интересно, если бы приложение могло периодически сканировать объекты, которые висят в его поколении 2 или куче больших объектов в сборщике мусора, и посмотреть, может ли оно обнаружить вещи, которые задерживаются для действительно долго / навсегда. Основная идея заключается в том, что приложение может определять потенциальные объекты, которые являются утечкой ресурсов, если одна и та же вещь присутствует в нескольких коллекциях (отслеживание их по слабым ссылкам, так что сам процесс его профилирования не удерживает). Я могу найти способы спросить, в каком поколении находится конкретный объект, и найти API для неуправляемого кода или инструменты отладки для исследования управляемых куч, но я действительно хочу, чтобы управляемый вызов дал мне какую-то структуру данных со всеми объекты в указанном поколении.

Есть ли у меня надежда найти такую ​​вещь, или я ищу что-то, чего не существует?

Теоретически возможно выложить экземпляр приложения-отладчика и проанализировать результаты или что-то в этом роде, но я бы хотел, чтобы он работал на живых веб-серверах во время низкой нагрузки, и я не уверен, что ops хотел бы, чтобы я подключил отладчик, даже если бы это было возможно:)

1 Ответ

2 голосов
/ 23 ноября 2011

Недавно работая с аналогичными инструментами в Objective-C, вы, возможно, захотите поискать инструмент для кучи. Инструмент heapshot сделает снимки вашей кучи, построит из нее график памяти и попытается выяснить, какая память укоренена и где. Во многом это похоже на то, как сборщик мусора узнает, какие объекты собирать.

В общем, инструмент heapshot позволяет вам делать снимки вашей кучи в разное время и сравнивать, какая память укоренена и какие объекты занимают это пространство. Mono Heapshot https://github.com/mono/heap-shot кажется хорошей отправной точкой, хотя я лично не использовал его. Я имел хорошие результаты с JetBrains dotTrace Memory в прошлом. К сожалению, оба эти инструмента не покажут вам поколения, в которых живет объект, но они могут отслеживать идентичность объекта, иногда даже по снимкам. Если вы обнаружите, что объект переживает несколько коллекций, он, вероятно, будет жить в более высоком поколении. Точное поколение зависит от реализации, времени выполнения и конкретной среды.

Другие профилировщики памяти, безусловно, существуют. Очень хорошим инструментом в Microsoft CLR являются расширения WinDbg плюс SOS. Вот хорошая статья журнала MSDN об этом здесь: http://msdn.microsoft.com/en-us/magazine/cc163528.aspx, и я нашел Тесс из (чудесно названного) «Если он сломан, исправьте, вы должны», блог тоже имеет отличный контент. http://blogs.msdn.com/b/tess/

Некоторую общую информацию о структуре вашей кучи и поколений GC можно получить с помощью набора счетчиков производительности, задокументированных на http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx.

...