Существует так много вопросов о том, стоит ли вам связываться с файлом подкачки или нет. Этот сценарий описывает уникальные обстоятельства реального мира в моей производственной среде. Вывод, к которому я пришел, чтобы решить мою проблему, - отключить файл подкачки.
Я использую серию гостевых виртуальных машин, все из которых Server 2003 Enterprise Edition (а?). На своих физических хостах я использую HP DL380 G7, загруженный VMware ESXi 5.0 (управляемый через vCenter). В качестве хранилища у меня есть массив HP P2000 G3 SAS, на котором установлено 16 дисков SAS емкостью 300 ГБ 10k в RAID 6, назовите его LUN01. Эти виртуальные серверы составляют нашу среду Wonderware с одним сервером SQL и Historian, двумя серверами приложений и двумя серверами терминалов.
Работа, которую выполняет этот стек, критически важна и определяет, может ли объект выполнять свои функции или нет. (т.е. когда сервер выходит из строя, бизнес падает). Недавно несколько отказов дисков в массиве P2000 заставили меня переосмыслить архитектуру с нуля. Реконструкция дисков в массиве серьезно снизила производительность до такой степени, что приложение wonderware перестало отвечать. Поскольку на всех этих виртуальных машинах выполняются приложения с интенсивным вводом-выводом, реконструкция RAID предъявляет такие высокие требования к RAID.
Я определил, что узкое место во время восстановления диска возникает из-за записи на диск сервера приложений. По-видимому, потому, что он использует файл системной страницы вместо ОЗУ. Таким образом, объем сетевого ввода-вывода напрямую связан с дисковым вводом-выводом. Следовательно, серьезное влияние на производительность дисков во время реконструкции напрямую влияет на ввод-вывод сервера приложений. Это не имеет большого смысла, почему он разработан таким образом, но он прекрасно объясняет, почему сервер, который ничего не хранит локально (сервер приложений), будет поддерживать скорость записи на диск 10 Мбит / с (статистика производительности vmware для виртуальной машины сервера приложений).
Итак ... то, что я думаю, связано с обстоятельствами, при которых я хочу отключить файл подкачки в гостевой ОС (server 2003 EE), чтобы развернутый движок приложения Wonderware не создавал такие высокие требования к вводу / выводу диска ... в результате уменьшится влияние будущих реконструкций дисков в RAID.
Я смог понять это, проводя много времени по телефону с Wonderware. По сути, внутри каждого App Engine, развернутого в Galaxy, есть настраиваемый параметр, называемый «Контрольный период».
Контрольный период - это период времени между тем, когда Archestra будет записывать текущее состояние (значения, переменные и т. Д.) Приложения на диск. Это делается для того, чтобы в случае перезагрузки сервера или сбоя системы приложение могло возобновить работу с самого последнего состояния без потери данных. Если ваше приложение предназначено для хранения значений в самих объектах галактики, вы должны взвесить, сколько потерь данных вы можете допустить. Если ваше приложение предназначено для простой обработки данных и перекладывает задачу хранения информации на сервер SQL или оставляет значения в базе данных тегов, то вы не рискуете потерять какие-либо данные, увеличивая это значение.
В настоящее время ArchestrA насчитывает около 9000 тегов. Это означает, что между любыми двумя секундами может измениться 9000 значений, в результате чего 9000 значений будут записываться на диск ... каждую секунду. Большинство этих значений перезаписывают значения, которые были сохранены в предыдущую секунду. Системы, предназначенные для мониторинга аналоговых входов, всегда будут иметь огромное количество изменений каждую секунду. Как администратор вы должны решить, сколько из этого шума и сколько из этих данных необходимо захватить для отслеживания тенденций и т. Д.
Увеличение значения по умолчанию 0 мс (которое система интерпретирует как «по умолчанию не указано, использовать 1 секунду») до 5000 мс снизило мою активность на диске с более 300 IOP до менее 25 IOP. Фактически мы сгруппировали каждый механизм приложений с простым числом около 5000 мс, чтобы период контрольной точки каждого механизма делал независимые запросы к дискам для операций ввода-вывода. Это особенно важно для виртуализации систем управления. Производительность и масштабируемость становятся проблемой, когда в одном массиве работает много серверов.
Я не знаю Wonderware, но если вы используете файл подкачки, значит, у вас не хватает памяти, и все идет медленнее, используя виртуальную память - отключение файла подкачки не обязательно исправит это, это может просто заставить все работать нехватка памяти и сбой.
1) Купите больше RAM для хостов или настройте больше RAM в гостях.
2) Или настройте приложение на использование меньшего объема памяти.
3) Или, что более полезно, запустите что-нибудь вроде ProcMon PSInternals чтобы увидеть, что на самом деле записывается на диск в гостях, и подтвердить свои подозрения.
4) Если вы можете запустить аналогично настроенный тестовый сервер на Windows Server 2008 R2, диспетчер задач покажет доступ к диску гораздо более подробно, чем 2003 (процесс, файл, время ответа), без огромного файла журнала Process Monitor.
Это не имеет большого смысла, почему он разработан таким образом, но он прекрасно объясняет, почему сервер, который ничего не хранит локально (сервер приложений), будет поддерживать скорость записи на диск 10 Мбит / с (статистика производительности vmware для виртуальной машины сервера приложений).
Журналы приложений? Временные файлы, такие как шаблоны отчетов или рендеринга, и их вывод? Журналы транзакций для всего, что проходит через приложение? Синхронизация состояний между двумя серверами приложений? Мошеннический антивирусный сканер? Поврежденный драйвер фильтра файловой системы? Вредоносное ПО?