Как профилировать память CLR?

[stdray]

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

Comments

[justy_tylor]

Были проблемы с памятью в подобной системе на C#, но там слишком очевидно, глубоко профайлить не пришлось. Решения я сделал такие:
1. Входные датасеты (несколько тысяч) все пишутся на диск. Есть небольшой хак, что если в http хедерах gzip-сжатие, то вместо *.xml пишем *.xml.gz. Удобно для расследований. Парсинг и занесение в базу - отдельной задачей.
2. Исходящие датасеты для партнёров тоже предзаготавливаются на диске в сжатом виде по запросу, затем стримятся. Если повторные запрос в течение получаса - стримится тот же кэш, иначе пересоздаётся. Наличие последней отправленной версии в кэше - также удобно для расследований.

[stdray]

Ну вот про п1, видимо, надо писать на диск, потому что сейчас всё в памяти. И там всё неплохо сделано по архитектуре, можно конкретные обработчики заставить сохранять, а можно -- вообще всех. Все будет понятно, если я завтра увижу картину, где массивы байтов всё пожрали. Только эта ситуация плохо воспроизводится, и можно ничего не увидеть. И просто ждать следующего такого лага.

п2 не про енту систему. Ей только бы получить данные, извлечь от туда несколько полей и сохранить в базу. Отчего кроме прочего, я грешу как раз на БД, потому что в момент сохранения объем данных по сути удваивается и живет в таком виде до окончания транзакции с последующим выходом GC.

[justy_tylor]

Вот кстати да, если где-то есть DataTable, то там максимальный возможный просёр по производительности и памяти. Сохранять надо батчами по N записей, пока парсится полтора гига какого-нибудь датасета.

[pigmeich]

Надо переписать всё к хуям.

Точнее, план:

1. Составить описание - ты сделал в посте.
2. Составить техническое описание с применяемыми интерфейсами.
3. Составить техническое задание с деталями интерфейсов и пометками, что будет делаться скриптами.
4. Переписать всё к хуям.

[stdray]

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

[enternet]

1. Я ставлю на удаленные машины VS Community Edition, забираю туда исходники и отлаживаю прямо там. Вот, например, вчера, нажатие кнопки "Dump" на процессе сожравшем 20ГБ в отработало за секунд 10. Правда на 32-х ядрах )
2. Всю распаковку я выношу на диски и отдельные проверенные утилиты командной строки. Я потратил достаточно много времени чтобы протестировать вагон разных C#/C/C++ библиотек и пришел к выводу что победить на многоядерной машине на распаковке, например, тот же 7-zip хотя и можно, но трудозатраты большие и забил на это.

[stdray]

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

[enternet]

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

[zinal]

Таки поддержу предыдущего оратора в части установки отладчика на машину с проблемным кодом.
В далеком уже 2003-м году делал примерно то же самое для кода на C++, собранном с символами - но в оптимизированном режиме.
Собственно отлаживать в таком виде толком нельзя, но трассировать на уровне вызовов и анализировать содержимое памяти - вполне можно.

[wizzard0]

1. тупое решение. поставить сервак на 256-512 гб RAM, и переключить GC в SustainedLowLatency
2. а вот уже потом! профайлить.
2.1. да, мемори профайлеры у джавы лучше :(
2.2. студия локально на серваке гораздо лучше всего удаленного, благо комьюнити кушать и активироваться не просит

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

в смысле, реально намного лучше один раз так сэкономить время, а потом либо забить вообще, либо оптимизировать, но имея запас "где развернуться" итд.

[stdray]

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