stdray | Как профилировать память CLR? (Reply)

У нашей системы загрузки данных есть особенности: наличие жесткого дедлайна и единомоментное массовое появление данных на ключевых источниках. То есть в теории мы пытаемся получать информацию в реальном времени, а на практике выходит, что бОльшую часть суточного объема мы получаем в конкретные часы ночью и должны полностью отпроцессить к началу рабочего дня. Двигать делайн нельзя, потому что источники начинают выкладывать данные ночью по Москве, а во Владивостоке люди уже сидят и работают. Из-за чего можно видеть пики загрузки подсистем: сначала на получении первички, потом на трансформации, потом на раскладывании данных в детальный слой, на построении витрин и, наконец, индексации на полнотекстах.

И в процессах загрузки первички и ее трансформации мы были всегда уверены. Но тут начались проблемы - процесс выедал всю память, уходил в своп и всё работало очень меделенно. Что за процесс, я писал в прошлом посте. Было уже не до шика, потому я первым делом разнес по разным приложениям (и соответственно серверам) загрузку первичных данных и трансформацию. Помогло достаточно неплохо, потому что я успел сгонять в отпуск и всё было норм, но вчера всё повторилось.

По логам это выглядит так: интервал между двумя записями job'а, в который, грубо говоря, происходит лишь одна операция "создание из одного гигантского хэшсета другого с добавлением туда новых элементов", составлял чуть ли не 30 минут. Плюс в этот же период идут алерты, что на сервере кончилась память, потому что процесс всё пожрал. То есть, как я понимаю, процесс начал свопить и все замедлилось в зигалион раз.

Можно сходу набросать несколько вариантов, как эффективней работать:

не создавать новый хашсет, а мутировать старый

не работать с архивами в памяти, а распаковывать их в tmp

уменьшить фрагментацию памяти, используюя пул стримов

и так далее.

Другой вопрос, что перебирать варианты опасно и долго. И тут я понял, что плохо представляю себе как профилировать память приложения, которое жрет по 16+Гб на удаленном сервере. Варианты, которые я испробовал:

JetBrains dotMemory через RemoteAgent. Не сработало, потому что долго конектится к процессу, долго делает дамп, НЕВЕРОЯТНО долго качает этот дамп, еще дольше его процессит. В итоге ни один дамп таким образом у меня открыт не был.

Делаешь дамп штатными средствами ОС, качаешь Far'ом, открываешь в WinDbg и через sos смотришь !dumpheap -stat. Работает, но опять же долго делать дамп и очень долго качать.

Открываешь дамп в dotMemory. Эта возможность помечена как "beta", работает 100500 лет, плюс у меня дважды упала ОС из-за ентова. На третий раз всё открылось быстро, но информация была крайне странная.
(В ЖЖ почему-то не отображается картинка, если что она есть)
Первая попытка профилирования, когда у меня помер пека, остановила процесс, потому что с того момента он больше не делал ничего. А что за дамп загрузился после второго падения, я хз. Хотя фантазия успела разыграться, несмотря на полное несоотвествие даже абсолютных значений реальной картине.

Вспомнил, что видел у Саши Голдштейна какую-то утилиту на этот счет. Она не работает. Совсем. По крайней мере, у меня.

Вспомнил, что есть clrmd и написал маленькую тулу вот такого вида. Она работает около минуты, дает более-менее похожие на правду значения. Вот ей пока и пользуюсь, только модифицировал, чтобы можно еще режим задавать (не только NonInvasive, но и Passive выбрать) и поставил в планировщик писать енти "логи" каждые 15 минут. Завтра буду разбирать.

Как вообще нормально профилировать память в серверных .Net приложениях? Поделитесь опытом. А то вот это всё дикое время на создение дампа, на перекатывание его туда-сюда просто убивает. Это как смотреть на растущее дерево. Должны же быть какие-то нормальные способы.