Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Настройка NT: стоит ли тратить время?

Джей Милн

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

Если вы спросите кого-нибудь из Microsoft, как максимизировать производительность операционной системы Windows NT, то услышите стандартный ответ, что их система является самонастраивающейся. И мы, основываясь на результатах своего тестирования, вынуждены согласиться. Не существует никакого иного способа сколько-нибудь существенно повысить ее производительность, кроме как увеличив объем оперативной памяти. Если у вас установлен стандартный сервер, то в процессе инсталляции Windows NT сама выполнит настройку функциональных характеристик оптимальным образом.

В нашей лаборатории мы занимались пошаговой инсталляцией ОС Windows NT Server, обращая особое внимание на установочные параметры и конфигурацию операционной системы, влияющие на использование процессора и памяти, систему ввода-вывода и обмен данными в сети. Мы исследовали методы настройки NT через пользовательский интерфейс и реестр. Данная статья - это описание нашего тестирования и анализ изменений параметров производительности, полученных в результате экспериментов с различными настройками. Однако в столь кратком обзоре специфику всех существующих приложений, таких, как принт-сервер, Web-сервер, групповое ПО, учесть невозможно. Такое специализированное исследование вам придется сделать самим.

Тестовая установка

Для испытаний мы использовали восемь клиентских систем с процессорами Pentium 90 и 200 МГц и ОС Windows NT 4.0. Емкость ОЗУ каждого клиента - от 64 до 128 Мбайт. В качестве сервера была использована машина PowerEdge 4200 фирмы Dell Computer с операционной системой Windows NT и СУБД Microsoft SQL Server 6.5, т. е. с типичным набором ПО для сети масштаба подразделения предприятия с числом пользователей до 250. На нашем сервере было установлено два процессора Pentium Pro (512 Кбайт кэш-памяти), ОЗУ объемом 256 Мбайт и дисковый массив RAID емкостью 24 Гбайт (шесть дисковых накопителей). Кроме того, к серверу через контроллер Adaptec SCSI были подключены два внешних диска Fast SCSI II. Все машины находились в автономном сегменте Ethernet с пропускной способностью 100 Мбит/с.

Работу сервера мы оценивали с помощью Dynameasure - инструмента анализа нагрузки для Windows фирмы Bluecurve с восьмью рабочими станциями и в общей сложности 50 экземплярами запущенных клиентских заданий. Продукт Dynameasure позволяет эмулировать приложения, использующие как файловый сервис, так и СУБД. Мы провели более 40 тестов, во время которых так или иначе было испытано большинство служб Windows NT. При проверке загрузки сервера мы использовали стандартный для этой ОС монитор Performance Monitor, а для оценки нагрузки на сеть - ПО анализа сети NetXray фирмы Network Associates.

Результаты тестирования

В общем случае изменения настроек Windows NT, сделанные из пользовательского интерфейса или в реестре, на повышение производительности работы с файлами и СУБД повлияли незначительно. Несмотря на проведенную нами оптимизацию использования памяти, мы не заметили реального повышения эффективности работы СУБД или сокращения среднего времени отклика во всем диапазоне задействованных клиентских приложений (20, 35 и 50). Хотя при этом выяснилось, что на производительность СУБД в значительной степени влияет расположение файла свопинга виртуальной памяти и, разумеется, производительность MS SQL Server существенно повышает наращивание объема ОЗУ.

Для иллюстрации различий в работе системы при увеличении объема памяти мы установили БД MS SQL на сервере, на котором было сначала 96, а потом 256 Мбайт ОЗУ. Как видно из рис. 1, производительность СУБД сильно возросла при увеличении объема ОЗУ с 96 до 256 Мбайт. Сама база данных занимала при этом около 750 Мбайт.


Рис. 1. Результаты тестирования производительности СУБД

Довольно странно, что наиболее сильное влияние на повышение производительности Windows NT мы заметили, когда просто отвели все ее ресурсы под выполнение выделенной задачи. В Windows NT по умолчанию запускается большое число дополнительных служб. При выполнении сервером специализированных задач многие из них можно просто отключить (см. таблицу). Выключив лишние службы, мы освободили примерно 4 Мбайт памяти. Это, конечно, не так много, но все-таки кое-что.

Приступаем к тестированию

Наша первая серия тестов была направлена на изучение влияния на производительность параметров свопинга Windows NT (рис. 2). Как выяснилось, эффективность работы сервера в значительной степени зависит от размещения файла свопинга. Наибольшую производительность (из расчета произведенных транзакций в секунду) SQL-сервер показал, когда файл свопинга был расположен на дисковом массиве RAID уровня 5 вместе с файлами СУБД.


Рис. 2. Производительность в зависимости от расположения файла свопинга

Мы также заметили улучшение, когда сконфигурировали сервер на использование двух файлов свопинга, каждый на своем внешнем диске SCSI. Интуиция подсказывает, что при подключении физического диска с более высокими скоростными характеристиками должна повыситься и общая производительность сервера. Когда, например, мы проводили тесты с файлом свопинга, находящимся на дисковом массиве RAID, длина дисковой очереди в среднем была равна нулю. Благодаря кэш-памяти объемом 32 Мбайт, высокоскоростным накопителям и контроллерам UltraSCSI массив RAID мог обслуживать запросы с гораздо большей производительностью, чем внешние диски SCSI. Все это время полученные нами результаты демонстрировали, что Windows NT только выигрывает от своей способности распределять файлы свопинга на несколько устройств. В данном случае NT пользуется преимуществом асинхронного ввода-вывода между согласованными дисковыми устройствами.

В ходе тестирования мы поняли, что не стоит строить слишком много предположений относительно расположения узкого места на сервере. Часто оно находится совсем не там, где вы думаете. Именно поэтому важно наличие таких инструментов, как Performance Monitor. Проводя серию тестов и меняя параметры системы, мы с помощью Performance Monitor смогли объективно (на основе количественных показателей) выделить все узкие места системы.

Следующая серия тестов была направлена на исследование влияния на скорость работы сервера типа используемой файловой системы: FAT (File Allocation Table) и NTFS (NT File System). Считается, что при небольших объемах (менее 2 Гбайт) FAT работает намного быстрее, чем NTFS, но испытания показали, что разница в их производительности невелика. При считывании и записи на диск FAT работала ненамного быстрее, чем NTFS.

Мы определили производительность для томов объемом 500 Мбайт и 1 Гбайт с помощью теста файлового сервиса Dynameasure. В обоих случаях использовались файлы размером 1 и 64 Кбайт. Дополнительно мы скорректировали величину блока размещения (allocation unit) для системы NTFS на нашем томе объемом 1 Гбайт с 4 до 64 Кбайт. Но, несмотря на изменения конфигурации, ощутимой разницы в производительности мы не заметили.

Если сомнение в производительности - последнее, что удерживает вас от перехода на NTFS, то мы советуем вам все-таки осуществить его. Помните, что результаты все равно будут зависеть от очень большого количества факторов: размеров файла и блоков размещения, типа носителя, используемых контроллеров RAID, дисковой конфигурации (RAID уровней 0, 1, 3, 5), емкости ОЗУ контроллера RAID и степени загрузки сети.

Другой областью наших исследований было изменение параметров настройки памяти, доступ к которым осуществляется через вызов пиктограммы Services в окне Network Control Panel. Windows NT предлагает четыре различных способа настройки характеристик сервера: минимизация использования памяти (Minimize Memory Used), балансировка (Balance), максимизация производительности для совместного использования файлов (Maximize Throughput for File Sharing) и максимизация производительности для сетевых приложений (Maximize Throughput for Network Applications). Чтобы определить влияние каждой из этих установок на передачу файлов, пришлось обратиться к продукту Dynameasure. Мы измерили производительность, используя все 30 клиентских приложений на 8 физических машинах. Наш набор данных - это файл размером 154 Мбайт, использующий нулевое время обсчета для каждого клиентского задания. Количественные характеристики представлены на рис. 3.


Рис. 3. Производительность двунаправленной передачи файлов

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

В прятки со смертью

Наши первые безобидные эксперименты мы проводили в рамках тех изменений, которые позволяет делать стандартный пользовательский интерфейс. Однако со своей следующей серией тестов мы вторглись в таинственный и непредсказуемый мир реестра Windows NT (результаты представлены на рис. 4).


Рис. 4. Влияние на производительность настройки реестра

Обратите внимание, что в качестве эталонного теста была использована установка "Максимизация производительности для совместного использования файлов". Вынуждены вас предупредить: модификация реестра опасна для вашего сервера! Если вы все-таки решились на это, не забудьте сделать полную резервную копию его диска, включая и сам реестр.

Целью нашего первого теста настройки через реестр была проверка влияния блокировки автоматического присваивания имен файлов по схеме 8.3 для томов NTFS. Хотя мы не обнаружили, чтобы это дало серьезный выигрыш при 20 запущенных клиентских задачах, однако на 35 и 50 задачах можно было заметить некоторые изменения: значительно сократилось среднее время отклика, но при этом немного снизилась производительность. Для блокировки автоматического присваивания имен по схеме 8.3 мы изменили значение параметра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\
NtfsDisable8dot3NameCreation с 0 на 1.

Во второй серии тестов по модификации реестра мы увеличивали число буферов, используемых Windows NT для маршрутизации. По идее с увеличением их числа производительность сети должна возрастать. В действительности же мы этого не обнаружили. Для того чтобы внести данные изменения, откройте запись реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManWorkstation\Parameters и добавьте параметр MaxCmds (тип REG_DWORD). Вам придется завести еще один параметр MaxThreads (тип REG_DWORD). Убедитесь, что для обоих вы задали одно и то же число (допустимое значение для каждого из них находится в пределах от 0 до 255, по умолчанию оно равно 15). Мы обнаружили, что эти установки также уменьшают время отклика сервера, но уже не в такой степени, как блокировка создания имен файлов по схеме 8.3.

Кроме описанных нами способов внесения изменений, для выполнения модернизации Windows NT можно использовать и специальные продукты третьих фирм. Один из них - AutoPilot P/SA фирмы MCSB Technology меняет приоритеты в списке выполняемых на сервере задач. Установив пакет AutoPilot, мы заметили небольшое повышение производительности при выполнении теста считывания из БД (рис. 5). Надо отметить и сокращение времени отклика при работе пакета AutoPilot. При считывании и записи в БД продукт не оказывал существенного влияния на производительность (рис. 6).


Рис. 5. Считывание из БД при работе AutoPilot


Рис. 6. Считывание/запись в БД при работе AutoPilot

Представители фирмы MCSB утверждают, что их продукт повышает производительность в тех случаях, когда многопоточность используется для выполнения одной серверной задачи, например Microsoft SQL Server. Управление же отдельными потоками в целом незначительно влияет на рабочую нагрузку. Скорее всего вы заметите более эффективную работу таких приложений, как Exchange, или других систем обмена сообщениями и группового ПО.





  
7 '1998
СОДЕРЖАНИЕ

колонка редактора

• Между прошлым и будущим

локальные сети

• Выбираем сетевой цветной принтер

• Сетевые адаптеры на 10/100 Мбит/с

• Sportster MessagePlus на скорости 33,6 Кбит/c и выше

• Кабельные системы для офисных зданий. Часть II. Администрирование

• Настройка NT: стоит ли тратить время?

• Ленточные накопители: богатство выбора

бизнес

• Настраивая каналы

корпоративные сети

• Телекоммуникационная составляющая системной интеграции

• Управление корпоративными СУБД: возвращение на землю

• Маршрутизаторы

• Проблемы резервного копирования промышленных баз данных

системы учрежденческой связи

• Тенденции развития телефонных станций

услуги сетей связи

• Интеллектуальные сети - российским операторам связи

• "Небесные" высокоскоростные сети

• Концентраторы доступа к ATM

• На пути создания интеллектуальных сетей

• CDMA - тема для отдельного разговора

интернет и интрасети

• Очередное вручение премии BOTI

• Гармония будущего

защита данных

• Протокол IPSec для групп по интересам

новые продукты

• Z.E.N.: новая философия управления фирмы Novell; В Интернет - через InBusiness Internet Station; Hicom 300 Е - это больше, чем просто УАТС; Серверы Sun для рабочих групп; CBOSS: биллинг для операторов;



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх