У нас есть asp.net (.net 4.0) webapplication, который установлен в нескольких средах. В большинстве сред использование памяти - где-нибудь приблизительно 1 ГБ. Однако у нас есть одна среда, где использование памяти достигает максимума к 5.5 ГБ. Это находится на машине Сервера 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 (когда это было +/-2GB, потому что большие дампы перестали работать). Выполнение 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, который я вижу?
Для тех, кто получил нечто подобное: в конце концов, это было неуправляемым код в библиотеках Active Directory инфраструктуры .NET, который не был удален правильно. Вот почему неуправляемая куча была такой большой.
Как я узнал, в чем была причина? Я просто посмотрел на случайные адреса памяти, чтобы узнать, что это за содержимое.И поскольку я нашел много данных, связанных с Active Directory, я знал, что это утечка данных.
Несколько вызовов Dispose ()
позже, проблема была решена.
Это скорее вопрос разработчика, и он не имеет отношения к IIS.
Первое, что вам нужно сделать, это определить, в какой генерации находится куча памяти (0, 1, 2 или 3 (Большая куча объектов)).
Проводник процесса обеспечивает простой способ отображения этой информации.
По большей части, .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/