Управление памятью для преднамеренно интенсивного использования памяти

Question

Примечание: Мне известен вопрос Управление памятью в приложениях с интенсивным использованием памяти , однако этот вопрос, как представляется, касается приложений, которые часто выделяют память, тогда как мой вопрос касается приложений намеренно разработан, чтобы потреблять столько физической памяти, сколько безопасно.

У меня есть серверное приложение, которое использует большие объемы памяти для выполнения кэширования и других оптимизаций (например, SQL Server). Приложение работает на выделенном компьютере и поэтому может (и должно) использовать столько памяти, сколько оно хочет / может, чтобы ускорить и увеличить пропускную способность и время отклика, не беспокоясь о воздействии на другие приложения в системе.

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

Некоторые предположения:

• Приложение работает на выделенном компьютере
• Требования к памяти приложения превышают физическую память на машине (то есть, если приложению будет доступна дополнительная память, оно всегда сможет использовать эту память для некоторого улучшения времени отклика или производительности)
• Память эффективно управляется таким образом, что фрагментация памяти не является проблемой.
• Приложение знает, какую память можно безопасно освободить, и какую память следует освободить в первую очередь для наименьшего влияния на производительность.
• Приложение работает на компьютере с Windows

У меня вопрос - как мне распределить память в таком приложении? В частности:

• Как я могу предсказать, удастся ли выделить память?
• Должен ли я оставить определенное количество свободной памяти, чтобы гарантировать, что операции ядра ОС остаются отзывчивыми (и таким образом не влияют на производительность приложений), и как я могу узнать, сколько это памяти?

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

Я разработчик на C #, но я надеюсь, что основные понятия для любого такого приложения одинаковы независимо от языка.

Answer 1

В Linux процент использования памяти делится на следующие уровни.

0 - 30% - без обмена 30 - 60% - меняйте только грязные страницы 60 - 90% - меняйте чистые страницы также на основе политики LRU.

90% - вызвать OOM (Out of memory) и убить процесс, потребляющий максимум памяти.

проверьте это - http://linux -mm.org / OOM_Killer

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

Один из способов прекратить использование большего количества памяти - перейти в спящий режим и дать больше времени для запуска потоков очистки памяти.

Answer 2

Ваш вопрос напоминает мне давнюю дискуссию «Так что же не так с программированием 1975 года?» . Архитектор varnish-cache утверждает, что вместо того, чтобы указывать ОС уходить с дороги и самостоятельно управлять всей памятью, вам лучше сотрудничать с ОС и дать ей понять, что вы намерены делать с памятью .

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

Answer 3

Это очень хороший вопрос, и он также должен быть субъективным, потому что сама природа основы C # заключается в том, что все управление памятью выполняется средой выполнения, то есть сборщиком мусора. Сборщик мусора - это недетерминированный объект, который управляет и очищает память для восстановления, в зависимости от того, как часто память фрагментируется, сборщик мусора включается, следовательно, заранее знать, что это нелегко.

Правильное управление памятью звучит скучно, но для этого нужен здравый смысл, например, выражение using, обеспечивающее удаление объекта. Вы можете добавить один обработчик для перехвата OutOfMemory Exception, но это неудобный способ, поскольку, если программе не хватает памяти, программа просто захватывает и выполняет бомбардировку, или она должна терпеливо ждать, пока GC удар, снова определяя, что это сложно.

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

В сущности, хотя это отличный вопрос, я думаю, вам не следует беспокоиться об этом и оставить .NET CLR для управления распределением / фрагментацией памяти, поскольку это, кажется, делает довольно хорошую работу.

Надеюсь, это поможет, С наилучшими пожеланиями, Том.