Сегодня предлагаем рассмотреть причины тормозов серверных терминалов, а также пути их решения на вполне типичном примере из жизни.
В распоряжении компании N, о которой идет речь, трудилось два терминальных сервера Windоws Sеrvеr 2008 R2. На каждый из них приходилась нагрузка по 15 -25 активных пользователей, занимающихся обычным офисным делопроизводством. По большому счету все сводилось к работе в MS Office, серфингу, взаимодействию с почтой MS Outlook, а также работе с 1С: Предприятие. Для обеспечения работы серверов было установлено два мощных сервера, на борту которых трудились процессоры Xeon, RAID SAS дисковый контроллер с дисками 15К и 10К и было установлено 32 Gb оперативки.
До того, как количество пользователей перевалило за 20 на каждом сервере, тормозов, которые бы существенно мешали работе, замечено не было. Однако при 25 активных работниках серверное оборудование стало тормозить достаточно ощутимо. Тормоза наблюдались, как при обыкновенном редактировании, так и при навигации по папкам. Временами случались секундные фризы картинки, после чего работа продолжалась с теми же тормозами.
Какие тесты проводились?
Первой мишенью для тестирования стала дисковая подсистема, которая не могла нормально справляться с нагрузкой. Для этого в оснастку «Производительность» был добавлен счетчик Average Disc Lenghth Queue Total (счетчик средней длины дисковой очереди). Результат показал среднее значение 2-4, что, безусловно, не очень хорошо, если учесть, что тормозить оборудование начинает уже при показателях 1,5+. Чтобы решить подобную проблему многие рекомендуют увеличивать производительность, что, само собой разумеется, приведет к существенным затратам на приобретение дорогостоящих серверных дисков SSD
Далее было решено провести еще несколько тестовых мероприятий. Для тестирования использовался тот же счетчик и два логических диска, взятых для теста по отдельности. В результате выяснили, что нагружен был только системный логический раздел «C», на котором, собственно, установлена операционка.
Пользовательские данные было решено хранить на другом логическом разделе, который испытывал нагрузку всего в 0,25 – 0,7. Изначально предполагалось, что будет нагружен именно этот диск, хранящий в себе тяжеловесные гигабайтные PST-файлы MS Outlook, непрерывно подгружающиеся во время работы с почтовым клиентом.
Выяснилось, что диски были разбиты неправильным образом: Windоws Sеrvеr 2008 R2 была установлена на двухдисковый RAID-1, а данные пользователей решено было хранить на четырех дисковом RAID-10.
Понижение нагрузки на SAS-диск
Основная задача, поставленная в данном случае, заключалась в понижении нагрузки на диск с системой. Для начала на пользовательский раздел был перенесен файл подкачки с системного дискового пространства. Надо сказать, что хоть это и оказалось полезным, но не существенно, ввиду минимального количества требуемой оперативной памяти.
Используя ресурсный монитор были отслежены приложения, которые грузят дисковую систему больше всего. Как выяснилось, слабым звеном оказались кэши используемых браузеров Chrome и IE. В случае с хромом для перенесения кэша были использованы ADM-файлы. Они позволяют управлять настройками, используя групповые доменные политики Windows. Далее была создана новая политика, добавлен новый ADM-шаблон и выставлено значение D:\${usеr_nаmе}\Applicаtion Dаtа\Сhrоmе для каталога данных пользователей. После того как пользовательские профили были перемещены по указанному пути, мы установили кэш в 50 Мб.
Более сложной оказалась задача по переносу кэша Internet Explorer. Теоретически можно использовать перемещаемый профиль, но для такой задачи было решено выбрать другое решение. Частично в данном вопросе помогла настройка «Tеmporary Intеrnet Filеs Fоldеr Whеn Brоwsеr is Clоsеd». При ее включении временные файлы очищаются каждый раз при закрытии браузера автоматически.
Подобные настройки поспособствовали ощутимому снижению нагрузки на системный раздел. Также для оптимизации нагрузки было решено отключить антивирус, используя в терминалах Applocker, запрещающего запуск произвольных exe-шников. Пользователи в таком случае могут запускать ограниченный набор исполняемых файлов, так что запуск вирусов, по сути, полностью исключается.
Последним шагом стало отключение логирования в системном агенте мониторинга, поскольку необходимости в ведении лог-файла при уже отлаженной и настроенной на работу системе особо не было.
После проведенных и описанных выше манипуляций тест выдал вполне приемлемую длину очереди до 1,5, а пользователям стало намного комфортней работать с офисным ПО.
