Могу ли я узнать все объекты в поколении сборщика мусора?
Меня поразила мысль о том, что было бы интересно, если бы приложение могло периодически сканировать объекты, которые висят в его поколении 2 или куче больших объектов в сборщике мусора, и посмотреть, сможет ли оно обнаружить вещи, которые задерживаются в течение очень долгого времени. / навсегда. Основная идея заключается в том, что приложение может определять потенциальные объекты, которые являются утечкой ресурсов, если одна и та же вещь присутствовала в нескольких коллекциях (отслеживание их по слабым ссылкам, так что сам процесс профилирования его не держит). Я могу найти способы спросить, в каком поколении находится конкретный объект, и найти API для неуправляемого кода или инструменты отладки для исследования управляемых куч, но мне действительно нужен управляемый вызов, чтобы дать мне какую-то структуру данных со всеми объекты в указанном поколении.
Есть ли у меня надежда найти такую вещь или я ищу то, чего не существует?
Теоретически может быть возможно выложить экземпляр приложения-отладчика и проанализировать результаты или что-то в этом роде, но я бы хотел, чтобы он работал на живых веб-серверах во время низкой нагрузки, и я не уверен, что ops понравится мне подключить отладчик, даже если это было возможно:)
1 ответ
Недавно, работая с аналогичными инструментами в Objective-C, вы, возможно, захотите поискать инструмент для динамической обработки. Инструмент 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.