Оказалось что dotMemory в отличии от .NET Memory Profiler не умеет показывать недосягаемые объекты из дампа.
Это планируется реализовать в будущем ?
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, WW898, Вы писали:
WW>>Здравствуйте, _NN_, Вы писали:
_NN>>>Оказалось что dotMemory в отличии от .NET Memory Profiler не умеет показывать недосягаемые объекты из дампа.
_NN>>>Это планируется реализовать в будущем ?
WW>>А вы с какой целью недосягаемые объекты хотите? Какую проблему оно поможет решить?
_NN>Есть дамп на 2Гб, с помощью .NET Memory Profiler легко нашли какие объекты не убрались и решили проблему.
_NN>С dotMemory этого не видно.
Давайте для начала с терминологией определимся: недосягаемый/недостижимый объект — это объект в графе в который нет пути из какого-либо рута.
Другими словами это и есть тот самый мусор который и должен находить и репортить алгоритм сбора мусора. Но есть одно но, алгорим работает от обратного: находит все выжившие объекты, а остальные регионы (не объекты!!!) памяти в хипе считаются мусором. В этих регионах нет информации о начале объектов, их количестве, просто диапазоны памяти, где ничего теперь нет.
Дальше можно сделать 3 вещи с этими регионами:
Забить до следующего GC (быстро и эффективно).
Скомпактить (дорого и сердито). Тут тоже есть 2 варианта: сжимать и копировать
Использовать маленькие регионы для точечного выделения в них новых объектов (магия оптимизации)
Собственно размеры хиров, где содержатся managed обекты при этом не менются.
Теперь по вашему вопросу. Не могли бы Вы, коротенько, в паре абзацах, объяснить что именно Вы имели в виду?
Здравствуйте, WW898, Вы писали:
WW>Собственно размеры хиров, где содержатся managed обекты при этом не менются.
WW>Теперь по вашему вопросу. Не могли бы Вы, коротенько, в паре абзацах, объяснить что именно Вы имели в виду?
Всё так. Только
.NET Memory Profiler умеет показывать размеры выделенных блоков , а dotMemory нет.
Сборщик мусора конечно всё соберёт, но пиковове потребление памяти останется в истории
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, WW898, Вы писали:
WW>>Собственно размеры хиров, где содержатся managed обекты при этом не менются.
WW>>Теперь по вашему вопросу. Не могли бы Вы, коротенько, в паре абзацах, объяснить что именно Вы имели в виду?
_NN>Всё так. Только .NET Memory Profiler умеет показывать размеры выделенных блоков , а dotMemory нет.
_NN>Сборщик мусора конечно всё соберёт, но пиковове потребление памяти останется в истории
Добрый день
Если вы не против нам помочь, можно я вас попытаю? Пока совсем не понятно какую проблему вы решаете.
Давайте я опишу, что я понял из дискуссии, и отвечу на некоторые вопросы, а потом позадаю их сам.
Для взятия снимка памяти через MS Profiling API, dotMemory запрашивает полную сборку мусора, в идеале в графе объектов, который выдал MS Profiling API, не должно быть недостижимых объектов, так как они должны быть собраны. Но по факту, бывает, что он выдаёт некоторое кол-во объектов связанных друг с другом, но не достижимых из GC roots. Видимо, это какая-то внутренняя оптимизация или просто особенности работы GC. Эти объекты будут собраны в последующих GC. Какую пользу можно извлечь из знания какие объекты не были собраны из-за особенностей реализации сборщика мусора?
Windows memory dump можно взять в произвольный момент, то есть в момент между сборками мусора, когда часть ссылок уже потеряна логикой программы, но GC ещё не собрал недостижимые объекты. Они будут собраны в ближайший GC (с учётом сказанного в предыдущем абзаце). Здесь тоже непонятно какую проблему можно решить увидев случайный (случайный, потому что если dump взять на несколько миллисекунд раньше или позже, картина будет совершенно другая) набор уже недостижимых, но ещё не собранных объектов.
Далее вы пишете, что SkiTech "умеет показывать размеры выделенных блоков", мы имеете в виду размеры managed heaps. Это то, что dotMemory показывает на "
Group By Generations" для All Objects, или что-то другое? Если другое, расскажите, пожалуйста, что именно, или дайте screenshot/ссылку из SkiTech.
И "пиковое потребление памяти останется в истории". Потребление памяти dotMemory показывает во время профилирования, на графике
Timeline, и это будет настоящее потребление в каждый момент времени. Взятие dump в произвольный момент, даст некоторую оценку снизу, в силу случайности, которая описана выше.
И, собственно, вопрос. Вы можете описать, какую проблему вы решаете? Не какие данные, как вам кажется, для этого нужны, а именно техническое описание самой проблемы?
Потому что пока возникает ощущение, что вы хотите увидеть
memory traffic своего приложения, и dotMemory умеет его показывать в удобном виде. Удобнее чем произвольный набор недостижимых объектов.
Спасибо!
Здравствуйте, Ed.ward, Вы писали:
EW>И, собственно, вопрос. Вы можете описать, какую проблему вы решаете? Не какие данные, как вам кажется, для этого нужны, а именно техническое описание самой проблемы?
Клиенты были недовольны 2-м Гб памяти в диспетчере задач.
Мы не знали как воспроизвести проблему и почему происходит.
По случаю удалось взять дамп памяти .
dotMemory показывает, что есть 786МБ занято вторым поколением, но не может показать, что там.
.NET Memory Profiler смог показать размер блоков во втором поколении и на основании этого удалось понять кто их выделяет.
EW>Потому что пока возникает ощущение, что вы хотите увидеть memory traffic своего приложения, и dotMemory умеет его показывать в удобном виде. Удобнее чем произвольный набор недостижимых объектов.
Всё верно, но для этого нужно запустить dotMemory вовремя и воспроизвести проблему, а как её воспроизводить мы не знали и поэтому взяли дамп.
EW>Спасибо!
