У нас есть веб-приложение asp.net (.net 4.0), которое установлено в нескольких средах. В большинстве сред объем используемой памяти составляет около 1 ГБ. Однако у нас есть одна среда, в которой использование памяти достигает 5,5 ГБ. Это на машине Server 2008 с 4 ядрами и 8 ГБ оперативной памяти, работающей как клиент VMWare esx.
Я установил счетчики производительности со следующими результатами:
Memory
Committed Bytes 10 145 739 948,0000
Pages Output/sec 0,0000
Paging File _Total
% Usage 28,998
Process _Total w3wp
Working Set 7 480 003 280 5 604 421 056
Я также сделал дамп памяти процесса w3wp (когда он был +/- 2 ГБ, потому что большие дампы не удались). Запуск DebugDiag на дампе не сделал меня мудрее. Кажется, что сам .net занимает всего 800 МБ, а большая часть памяти занята «чем-то еще».
.NET GC Heap Information
GC Heap Size 826,09 MBytes
Total Commit Size 1217 MB
Total Reserved Size 16190 MB
Heap Analysis
Summary
Number of heaps 29 Heaps
Total reserved memory 1,89 GBytes
Total committed memory 1,79 GBytes
...
(largest of the Heaps)
Reserved memory 1,69 GBytes
Committed memory 1,67 GBytes(99,14% of reserved)
Uncommitted memory 14,86 MBytes(0,86% of reserved)
Number of heap segments 113 segments
Number of uncommitted ranges 113 range(s)
Size of largest uncommitted range 0 Bytes
Дело в том, что я не уверен, что такое высокое использование памяти является проблемой. Итак, я ищу руководство, как решить эту проблему:
РЕДАКТИРОВАТЬ: Это то, что я вижу в ProcExp:
Как видите, общее количество байтов во всех кучах составляет 1,12 ГБ. В то время W3WP использовал 6,4 ГБ. Почему между этими двумя числами такая большая разница? Что могло занимать это место? Это фрагментация LOH, которую я вижу?
На самом деле это скорее вопрос разработчика, не имеющий отношения к IIS.
Первое, что вам нужно сделать, это определить, в какой куче поколения находится память (0, 1, 2 или 3 (куча больших объектов)).
Process Explorer предоставляет простой способ отобразить эту информацию.
По большей части .NET GC является самоуправляемым. Есть несколько параметров .config, чтобы отрегулировать это, но это действительно та область, где разработчик должен дать рекомендации.
Если вы хотите проверить кучу, вероятно, лучше всего подойдет WinDbg.
http://blogs.microsoft.co.il/sasha/2010/08/24/psscor2-object-inspection-commands-part-2/
http://blogs.microsoft.co.il/sasha/2010/08/26/psscor2-gc-heap-analysis-commands/
Для тех, кто получает нечто подобное: в конечном итоге это был неуправляемый код в библиотеках Active Directory фреймворка .net, который был неправильно удален. Вот почему неуправляемая куча была такой большой.
Как я узнал, в чем виноват? Я просто посмотрел на случайные адреса памяти, чтобы узнать, что это за содержимое. И так как я нашел много данных, связанных с Active Directory, я знал, что это утечка данных.
Немного Dispose()
звонит позже, проблема решилась.