Управление памятью для намеренно интенсивно использующих память приложений
Примечание: Я знаю об управлении памятью вопроса в интенсивно использующем память приложении, однако тот вопрос, кажется, о приложениях, которые делают частые выделения памяти, тогда как мой вопрос о приложениях, намеренно разработанных для потребления такой физической памяти, как безопасно.
У меня есть серверное приложение, которое использует большие объемы памяти для выполнения кэширования, и другие оптимизации (думайте SQL Server). Выполнение приложения на выделенной машине, и так может (и если) используют столько памяти, сколько она хочет / может к тому, чтобы убыстриться и увеличить пропускную способность и время отклика без беспокойства влияния на другие приложения в системе.
Проблема состоит в том, что, если использование памяти недооценено, или если загрузка увеличивает свое возможное для окончания с противными отказами, поскольку выделения памяти перестали работать - в этой ситуации, очевидно, лучшая вещь сделать состоит в том, чтобы освободить память для предотвращения отказа за счет производительности.
Некоторые предположения:
- Приложение работает на выделенной машине
- Требования к памяти приложения превышают физическую память на машине (то есть, если бы дополнительная память была доступна приложению, то это всегда могло бы использовать ту память, чтобы в некотором роде улучшить время отклика или пропускную способность),
- Памятью эффективно управляют в некотором роде таким образом, что фрагментация памяти не является проблемой.
- Приложение знает, какая память может быть безопасно освобождена, и какая память должна быть освобождена сначала для наименьшего количества влияния производительности.
- Выполнение приложения на машине Windows
Мой вопрос - как я должен обработать выделения памяти в таком приложении? В особенности:
- Как я могу предсказать, перестанет ли выделение памяти работать?
- Я должен оставить определенное количество памяти свободным, чтобы удостовериться, чтобы базовые операции ОС остались быстро реагирующими (и таким образом неблагоприятно не влияйте на производительность приложений), и как я могу узнать, сколько памяти, которая является?
Базовая цель состоит в том, чтобы предотвратить отказы в результате использования слишком большой памяти, одновременно израсходовав как можно больше памяти.
Я - разработчик C#, однако моя надежда состоит в том, что фундаментальные понятия для любого такого приложения являются тем же независимо от языка.
2 ответа
, который является очень хорошим вопросом, и обязательно должно быть субъективным, потому что сама природа фундаментальной части C # заключается в том, что все управление памятью выполняется по времени выполнения, то есть сборщик мусора. Коллектор мусора - это не детерминированное предприятие, которое управляет и подметает память для восстановления, в зависимости от того, как часто память становится фрагментированной, ГХ отсюда будет принять участие в том, чтобы заняться заранее.
Для правильной управления памятью звучит утомительно, но применяется здравый смысл, такие как , используя пункт , чтобы обеспечить распоряжение объекта. Вы могли бы поставить в один обработчик для ловушки исключения , но это неловкий способ, поскольку если программа заканчивается памятью, программа просто захватывает, и взрывайтесь или должны ждать Терпеливо для ГХ, чтобы выгнать, снова определяя это сложно.
Нагрузка на систему может отрицательно повлиять на работу GC, почти до точки отрицания сервиса, где снова все просто превращается в остановку, поскольку спецификации машины, или какова природа этой машины Работа неизвестна, я не могу ответить на это полностью, но я предполагаю, что у него есть множество RAM ..
по сути, в то время как отличный вопрос, я думаю, вы не должны беспокоиться об этом и оставить его в .NET CLR для Обработка распределения / фрагментации памяти, как кажется, очень хорошая работа.
Надеюсь, это поможет, С уважением, Том.
В Linux процент использования памяти разделен на следующие уровни.
0 - 30% - без обмена 30 - 60% - коммутация грязных страниц 60 - 90% - Обмен чистыми страницами также на основе политики LRU.
90% - ссылаться на убийцу OOM (вне памяти) и убить процесс, потребляющий максимальную память.
Проверьте это - http://linux-mm.org/om_killer
В Think Windows может иметь аналогичную политику, поэтому вы можете проверить статистику памяти и убедиться, что вы никогда не попадаете на максимальный порог.
Один из способов прекратить потребление большего количества памяти - пойти спать и дать больше времени для запуска потоков очистки памяти.