Назад | Перейти на главную страницу

Почему Windows 2008 использует подкачку до заполнения памяти?

Я администрирую сервер Windows 2008 (ну, на Amazon EC2) с IIS и веб-приложением .NET4. На днях я получил предупреждение о памяти, пошел и посмотрел, и, конечно же, память процесса со временем выросла из-за какой-то медленной утечки. Он не увеличился значительно, точно так же, как с 60 до 200 миллионов, но достаточно всего остального, что превысило наш довольно низкий порог (75%), чтобы сработать монитор.

Я переработал пул приложения, и память высвободилась, и при просмотре статистики я заметил, что пространство подкачки использовалось значительно и что более 1 ГБ его освободилось за счет этой перезагрузки.

Может быть, это базовый вопрос, но я парень UNIX и привык менять местами, не привыкая, пока не кончится память. Этот блок никогда не превышал 75% использования памяти. Это вещь Windows, .NET или Amazon? Я подозреваю, что в этом приложении утечка памяти намного больше, чем предполагалось - утечка не с 60 до 200 МБ, а с 60 до 1,2 ГБ, но большая часть из них каким-то образом «остывает» и выталкивается для обмена?

У меня в пуле приложений установлена ​​перезапись памяти, но она запускает полную память коробки, поэтому это приложение может стать действительно очень большим, прежде чем оно будет перезапущено автоматически.

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

Изменить с дополнительной информацией: память экземпляра: 1,7 ГБ подкачки: 4,5 ГБ

Я вижу процесс w3wp.exe в taskmgr, показывающий, что Память: 211 000 КБ. Но когда я перезапустил его (он находится в собственном пуле приложений, и это единственное приложение в коробке), его использование памяти снизилось до обычной начальной точки в 60 МБ, и, как и более 1 ГБ подкачки, также освободилось. В taskmgr у меня была только обычная статистика памяти (частный рабочий набор), но я увидел изменение подкачки через мой другой мониторинг (Cloudkick). Если вернуться назад и посмотреть на это сегодня, объем памяти в процессе составляет 195 МБ (всего 1,2 ГБ), а объем подкачки увеличился с 1,0 ГБ до 1,1 ГБ, но не полностью обратно на прежнее место (график с течением времени показывает медленная ползучесть).

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

Windows и Linux имеют две разные стратегии страницы / подкачки.

Linux

Linux вообще не хочет использовать пространство подкачки и ждет до последнего момента. Если вы видите большой объем подкачки в Linux, скорее всего, в вашей системе возникли проблемы. Эта стратегия хороша для минимизации общего дискового ввода-вывода, который является самой медленной частью вашей системы, но более слабая для систем с чередующимися периодами легкой и большой нагрузки (и, честно говоря, большинство из нас). Времена, когда ваша нагрузка уже велика, теперь будут отягощены "лишним" дисковым вводом-выводом, или, другими словами, вам нужно проектировать сборки вашего сервера с учетом того, чтобы иметь достаточно оперативной памяти, которую вы не меняете даже во время максимальное ожидаемое время загрузки.

Windows

Windows хочет рассматривать память как простой кеш файла подкачки. Ваш настоящий память всегда находится на диске, но сначала она будет читать / писать из "кеша", если это возможно. Эта стратегия хороша для выравнивания нагрузки с течением времени; когда система становится загруженной и ей необходимо поменять страницы местами, текущая страница уже находится на диске и половина работы уже сделана. Этот подход имел огромный смысл, когда Windows была молодой, 32 МБ (не говоря уже о ГБ) были еще большим объемом оперативной памяти, и частая необходимость в использовании пространства подкачки была очевидной. Даже сегодня это хорошо для рабочих нагрузок, которые чередуются между легкой и загруженной нагрузками, поскольку это помогает распределять дисковый ввод-вывод более равномерно с течением времени.

В современных версиях Windows есть дополнительные оптимизации, такие как SuperFetch, для предварительной загрузки и подготовки страниц памяти на диске и в ОЗУ, когда в остальном нагрузка невелика, чтобы избежать необходимости дополнительной записи на диск при загрузке программы в первый раз. Все это означает, что вы можете спроектировать свою систему так, чтобы ей требовалось достаточно оперативной памяти только для чего-то меньшего, чем самая высокая ожидаемая нагрузка, так что вы по-прежнему можете иметь хотя бы приемлемую производительность все время с меньшими затратами.

Конвергенция

Эта концепция измерения или прогнозирования нагрузки сначала в тестовой среде, а затем выделения производственных ресурсов, когда нагрузка известна, является относительно недавней разработкой в ​​области построения систем, которая стала возможной или, по крайней мере, практичной, частично с появлением виртуальных, а затем облачных серверов. . В зависимости от вашей нагрузки вы можете даже спроектировать систему так, чтобы ее вообще не нужно было менять. В этих случаях Windows позволяет отключить подкачку и вести себя больше как система Linux. Однако нужно быть осторожным; если конструкция вашей системы требует больше памяти, чем ожидалось, вы можете попасть в беду.

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

Windows (а также Linux и другие Unix-подобные ОС) будут перемещать страницы, которые не использовались в течение некоторого времени, на диск, чтобы освободить место для буферов и кеша, чтобы ускорить активную активность ввода-вывода. Кроме того, приложения часто выделяют больше памяти, чем они собираются использовать немедленно - это может побудить ядро ​​пейджинговать некоторые вещи, которые недавно не были затронуты в фоновом режиме, так что указанные приложения не видят задержку подкачки, когда они внезапно запускаются используя это распределение.

В Linux вы можете настроить (или заблокировать) это поведение, изменив соответствующие значения "swappiness" в /proc файловая система - без сомнения, есть значения реестра, которые вы можете настроить, чтобы изменить поведение Windows в этом отношении.

Еще одна вещь, о которой следует знать, - это то, что когда что-то было выгружено, а затем прочитано обратно, ядро ​​не удалит это из файла подкачки, пока либо файл не будет заполнен другим способом, либо страница в ОЗУ не будет изменена. Таким образом, если ему нужно снова разбить этот фрагмент на страницу, он может сделать это без необходимости фактически записывать страницы на диск: контент уже есть. Это может значительно повысить производительность в ситуациях, когда чрезмерная фиксация памяти стала настолько серьезной, что вызывает перегрузку файлов подкачки (значительное количество страниц постоянно отображается и удаляется). Скорее всего, вы обнаружите, что некоторые данные были вытеснены этой утечкой памяти и с тех пор были прочитаны, но не удалены с диска, на случай, если эти страницы необходимо сопоставить или ОЗУ, чтобы освободить место позже. В Linux значение SwapCached в /proc/meminfo показывает, сколько данных присутствует на страницах с идентичными копиями в ОЗУ и на диске. Без сомнения, Windows использует ту же оптимизацию (или что-то подобное), но я не совсем знаю, где посмотреть, насколько это происходит (без сомнения, есть соответствующие счетчики монитора производительности, которые вы можете запросить).

tl; dr: Это нормально. Современное ядро ​​ОС будет пытаться быть умным и максимально увеличить объем ОЗУ, который он может использовать в качестве кеша для сохранения операций ввода-вывода, и иногда будет копировать данные на диск и в ОЗУ для экономии ввода-вывода, если ему нужно вывести эти биты на страницу оперативной памяти позже. Скорее всего, хотя это может показаться нелогичным, такое использование файлов подкачки этими двумя способами, даже если в настоящее время у вас не мало оперативной памяти, улучшает вашу общую производительность, а не снижает ее.