Недостаточно памяти Исключения характерны для приложений, которые видят периодические всплески транзакций, сохраняя большие объемы данных в памяти. Эта проблема, однако, зависит от вашего приложения и архитектуры. Ниже приведены несколько указателей:
- Аппаратное обеспечение - у вас Xeon 5500 (чипы Intel Nehalem). Они очень хорошо справляются с памятью. Вам должно быть хорошо здесь.
- ОС - Windows Server 2008 R2 - в качестве ОС эта система будет обрабатывать более чем достаточно памяти для вас (вам это хорошо, см. Ссылку на возможности: Ограничения памяти для Windows )
- Физическая память - вы сказали, что у вас 8 ГБ на сервере? Обратите внимание, ваше приложение позволяет 16 ГБ. Есть одна проблема. Если ваше приложение запрашивает больше памяти, чем физически доступно, вы увидите ошибку. Но это не единственная ваша забота ...
- Ограничения CLR / GC - «Размер файла подкачки» вашего приложения составляет более 16 ГБ. Это, вероятно, ваша проблема.
GC - это сердце вашей проблемы для вас. По той же причине, по той же причине Java и JVM имеют проблемы, когда приложение превышает 2-4 ГБ. Это требует взглянуть на фактический процесс GC.
У вас есть процессы сбора мусора "старого поколения" и "молодого поколения". Когда ваше приложение запускается, CLR пытается сохранить организованное пространство памяти. Эти процессы заставляют все потоки приостанавливать (изменение фазы), когда происходят процессы GC mark и swap. Проблема здесь в том, что в зависимости от того, как написан ваш код, и от того, сколько памяти вы храните в течение длительного времени, вы можете столкнуться с проблемами с памятью.
Каждый раз, когда вы нажимаете среду выполнения, чтобы превысить порог в 4 ГБ, вы увидите экспоненциальное увеличение времени сбора. Когда вы нажимаете кнопку «Остановить мир» (GC старого поколения, где все очищается), CLR должен пройти всю кучу и освободить память. Исходя из вашего приложения, 16 ГБ могут вызвать проблемы даже с большей физической памятью (Windows Server 2008 R2 - Enterprise или DataCenter могут поддерживать 2 ТБ). Даже если вы загрузите больше физической памяти, вы можете увидеть ДЛИТЕЛЬНОЕ время сбора, когда ваш полный сборщик мусора попадет.
В идеале я бы сделал следующее:
Получите больше физической памяти (вы никогда не захотите использовать 600 МБ общей физической памяти, выделенной вашему приложению, чтобы избежать ошибок нехватки памяти, но ваш буфер зависит от вашей нагрузки и способности приложения справиться с ней. .. вы можете захотеть, чтобы безопаснее была большая сетка).
Когда у вас есть физическая память, вам нужно запустить журналы GC, одновременно нагружая приложение. Это даст вам представление о том, где вы видите экспоненциальное снижение производительности и какой уровень может поддерживать ваше приложение при рассмотрении размера кучи (памяти). Возможно, вы захотите найти способ уменьшить размер страницы до 16 ГБ. Я знаю, что в .Net 4.0 Microsoft внесла существенные улучшения в процесс GC, в том числе разрешив фоновому потоку поддерживать GC. Это должно дать вам возможность поддерживать большие кучи (теоретически) ... но ничто не сравнится с реальными тестами в приложении. Проверьте эту ссылку для получения дополнительной информации:
Производительность сборки мусора (Asp.net 4.0) - Кроме того, я ограничен в ссылках. Перейдите на страницу «Основные принципы», где приведены отличные объяснения новых возможностей GC в ASP.Net 4.0.
(http://msdn.microsoft.com/en-us/library/ee787088.aspx#concurrent_garbage_collection)
Надеюсь, это поможет!
PS. Любой, кто пользуется меньшим оборудованием, должен знать об использовании ASP.NET потока GC. Если вы используете что-то в разработке, например Core Duo, вы должны учитывать, что 50% ваших вычислительных мощностей будут направлены на оптимизацию GC. Это означает, что важно учитывать аппаратное обеспечение (количество ядер). Если у вас есть больше, чем нужно, этот процесс теоретически должен помочь производительности. Если вы ограничены в ядрах, либо получите лучшее оборудование, либо используйте более старую версию ASP.Net или рассмотрите возможность отключения этой функции (если это возможно). Во-вторых, если проблема заключается в задержке, использование «гиперпоточности» также влияет на производительность. Вы всегда получаете лучшую производительность на «физических» ядрах ... но это не будет проблемой для 99,9% приложений.