Как определять рабочие характеристики сервера с помощью утилиты Response Probe? Когда инженеры проектируют мост, они стремятся к тому, чтобы пропускная способность сооружения соответствовала интенсивности предполагаемого транспортного потока. Характеристики нового моста зависят, в частности, от того, какое максимальное количество транспортных средств может располагаться на мосту одновременно и сколько транспортных средств будут проезжать по нему в течение года. Пропускная способность моста связана с известной конструктору прочностью предназначенных для строительства материалов.
Инженеры, конструирующие серверы, решают похожие задачи с той лишь разницей, что в случае с серверами драматизм последствий неудачного решения не столь очевиден. Если, к примеру, в самый разгар рабочего дня процессоры сервера Windows NT, выполняющего важное приложение, не справятся с нагрузкой и машина перестанет отвечать на запросы, автомобили не станут падать в реку. Однако инженеру, который поручился за то, что сервер сможет удовлетворить потребности приложения, наверное, захочется провалиться сквозь землю.
Администраторы сталкиваются с проб-лемами «пропускной способности» всякий раз, когда наступает время конфигурировать сервер или прикладную программу, но им приходится тяжелее, чем строителям мостов: определение производительности сервера не относится к сфере точных наук. Для ее примерной оценки можно воспользоваться одним из трех методов.
Следовать рекомендациям поставщика. Изготовители аппаратных средств и прикладных программных продуктов обычно дают покупателям рекомендации как по выбору типа сервера, наиболее подходящего для решения конкретной задачи, так и по параметрам конфигурации аппаратных и программных компонентов. Однако такие оценки и даются, что называется, «с запасом».
Моделировать реальные условия эксплуатации. При наличии времени и подходящей тестовой среды в фазу разработки и создания сервера приложений можно включить период, в течение которого машина будет проходить «боевое крещение», т. е. с ней фактически будут работать пользователи. Однако надо сказать, что этот метод часто применяют лишь для подтверждения правильности концепции, а не для настоящего тестирования пропускной способности (т. е. в ходе испытаний сервер приложений не доводится до ситуации отказа).
Моделировать большую нагрузку с помощью программных средств. Этот метод не имеет серьезных недостатков, характерных для двух первых способов оценки пропускной способности. На серверах Windows NT моделирование рабочих нагрузок можно выполнять с помощью утилиты Response Probe, постав-ляемой корпорацией Microsoft в комплекте ресурсов Microsoft Windows NT Server 4.0 Resource Kit (в среде Windows 2000 Response Probe не функционирует).
Что такое Response Probe?
Смоделировать рабочую нагрузку нелегко, поскольку такие факторы, как фоновый сетевой трафик и число подключенных пользователей, трудно контролировать. Так вот, сильная сторона утилиты Response Probe как раз в том, что она обеспечивает возможность контроля. Это средство позволяет создавать воспроизводимую и независимую от конкретного приложения рабочую нагрузку и с ее помощью тестировать характеристики аппаратной и программной конфигурации сервера; при этом вовсе не нужно, чтобы сервером кто-то реально пользовался. Утилита не взаимодействует с выполняемой на сервере прикладной программой; она оценивает производительность системы, создавая уникальные потоки, которые применяют к серверу заданную нагрузку. Иными словами, Response Probe заменяет соответствующую прикладную программу. Утилита выполняется вместо главного приложения системы, но наряду с ее второстепенными приложениями.
Принцип действия Response Probe - моделирование реальных условий эксплуатации компьютера. Это значит, что утилита имитирует типичный цикл рабочей загрузки: время на обдумывание (которое может быть более или менее длительным), затем доступ к файлу и собственно вычисления. Response Probe исходит из того, что многие ха-рактеристики реальных рабочих нагрузок определяются стандартной кривой нормального распределения, и соответствующим образом формирует тестовые нагрузки. Так, время, затрачи-ваемое пользователями на обдумывание дальнейших действий зависит от компетентности пользователя и условий задачи, а время, затрачиваемое на поиск записи в файле, зависит от расположения записи на жестком диске относительно текущего положения считывающей головки диска. Response Probe исходит из того, что при типичных рабочих нагрузках эти и другие переменные распределяются нормально и что их можно описать, указав среднее и среднеквадратическое отклонение (подробное описание методики использования среднего и среднеквадратического отклонения для описания нормального распределения содержится в главе 11 руководства Resource Guide по Microsoft Windows NT Workstation 4.0, которое можно найти по адресу: http://www.microsoft.com/ technet/prodtechnol/ntwrkstn/reskit/03 tools.asp?frame=true). Как будет показано ниже, Response Probe позволяет определять средние и среднеквадратические отклонения для нескольких характеристик рабочих нагрузок.
При испытании эксплуатационных характеристик сервера Response Probe использует три тесно связанных между собой текстовых файла, которые описывают моделируемую нагрузку. Речь идет о следующих файлах:
- файл сценария процесса (.scr), который создает каждый процесс тестовой рабочей нагрузки;
- файл определения потоков (.scp), создающий потоки, которые будут выполняться в данном процессе;
- файл описания потоков (.sct), харак-теризующий процесс потока (для каж-дого определяемого потока необходим файл описания потоков).
Для каждого выполняемого программой Response Probe теста требуется по меньшей мере один экземпляр каждого из упомянутых файлов.
С помощью этих файлов Response Probe создает определенный уровень нагрузки, который остается неизменным при каждом запуске сценария в данной конфигурации. Проведя серию испытаний с различными параметрами сценария, администратор может установить базовый уровень производительности, а затем с помощью Response Probe определить верхний предел пропускной способности сервера.
Создание сценарных файлов
Для создания каждого процесса тестовой рабочей нагрузки используется файл сценария. Каждая строка в этом файле формирует отдельный процесс. Строки пишутся в соответствии со следующей синтаксической конструкцией:
REPEAT PROCESS
REPEAT n - необязательный параметр, указывающий на выполнение процесса n раз. ThreadDefFile.scp указывает на имя файла, определяющего потоки данного процесса. Параметр DataPages содержит количество страниц, выделенных для моделирования страниц данных (Data pages относится к внутреннему буферу хранения данных в Windows NT). ProcessName - необязательный параметр, указывающий имя процесса, в котором будет выполняться тест, а PriorityClass - необязательный параметр, устанавли-вающий для данного процесса относительный приоритет. Возможные значения параметра PriorityClass: I (Idle - ожидание), N (Normal - обычный), H (High - высокий) и R (Realtime - в реальном времени). Так, строка
PROCESS servbase.scp 10
создает один процесс, ассоциирует его с файлом определения потоков servbase.scp и указывает десятистраничный файл datapage.
Файл определения потоков служит для создания потоков, которые получают имена в файле-сценарии процессов. При этом используются следующие синтаксические конструкции
REPEAT THREAD
REPEAT n - это необязательный параметр, создающий n экземпляров потока. Параметр ThreadDesFile.sct указывает имя файла описания потоков, а переменная ThreadPriorityAd-justment позволяет задать потоку приоритет, отличный от приоритета, установленного для его процесса. Возможные значения для параметра ThreadPriorityAdjustment: T (TimeCri-tical - вне очереди), H (Highest - наивысший), A (AboveNormal - выше среднего), N (Normal - средний, принимается по умолчанию), B (Below Normal - ниже среднего), L (Lowest - самый низкий) и I (Idle - ожидание). Так, с помощью строки
THREAD servbase.sct
создается поток, который администратор настроил в файле описания потоков servbase.sct. Поскольку приоритет в этой строке определения потока не указан, поток выполняется с тем же уровнем приоритета, что и соответствующий процесс.
Наконец, этот поток описывается в каждом процессе, указанном в файле описания потоков. В данном файле содержатся почти все параметры конфигурации Response Probe, включая средние и среднеквадратические отклонения для нескольких параметров, используемых утилитой для генерации каждого потока. В Таблице 1 представлены параметры, которые может задавать администратор.
Файл описания потоков имеет табличный формат; каждому параметру выделяется отдельная строка. Порядок следования параметров может быть произвольным. Например, в приведенных ниже строках
| THINKTIME | 0 | 0 |
| CPUTIME | 0 | 0 |
| CYCLEREADS | 100 | 30 |
| FILESEEK | 0 | 0 |
| DATAPAGE | 0 | 0 |
| FUNCTION | 500 | 0 |
| FILEACCESS | workfile.dat | |
| FILEATTRIBUTE | SEQUENTIAL | |
| FILEACCESSMODE | UNBUFFER | |
| RECORDSIZE | 2048 | |
| FILEACTION | R | |
указаны параметры для потока, выполняющего операции чтения в файле. В соответствии с этими параметрами данный поток:
- не требует времени на обдумывание или дополнительного времени процессора;
- в промежутках между периодами обдумывания считывает данные в среднем 100 раз; при этом среднеквадратическое отклонение составляет 30 раз;
- использует последовательный доступ и, следовательно, игнорирует время поиска данных в файле;
- не контролирует обмен страницами данных;
- моделирует минимальное время доступа к кодовой странице, для чего многократно считывает функцию в центре этой страницы;
- считывает записи из файла рабочей нагрузки workfile.dat;
- считывает записи последовательно;
- не пользуется системным кэшем;
- считывает данные блоками по 2 Кбайт.
В отличие от предыдущих версий утилиты версия Response Probe 2.3 автоматически генерирует и считывает данные из внутреннего файла кодовой страницы. Используемый программой Response Probe 2.3 файл кодовой страницы содержит набор из 1000 вызовов встроенных функций или действий, которые может выполнять эта утилита. Данный файл выступает в роли кода приложения, откуда считываются команды при выполнении процесса. Определив, какие значения параметров наиболее точно передают создаваемую конкретным приложением нагрузку, можно добиваться более тонкой настройки нужных параметров.
Файлы сценариев Response Probe необязательно создавать «с чистого листа»; можно модифицировать образцы файлов из папки treskitperf-toolprobeexamples. В числе этих файлов есть несколько наборов превосходных сценариев для определения базового уровня производительности, которые вполне могут устроить разработчиков систем.
Файл diskmax.scr, например, определяет максимальную пропускную способность дискового накопителя с помощью последовательных операций считывания записей по 64 Кбайт из файла размером 20 Мбайт без использования буфера.
Файл minread.scr измеряет производительность диска при одновременном обращении лишь к одному из секторов диска; этот тестовый файл предусматривает выполнение последовательных операций считывания данных из файла размером 20 Мбайт блоками по 512 байт без использования буфера.
Файл sizeread.bat тестирует производительность конфигурации дисковой подсистемы при считывании записей растущего объема. Это не файл сценария процесса, а командный файл. Sizeraed.bat предусматривает проведение серии испытаний с выполнением последовательных операций считывания данных из файла размером 20 Мбайт без использования буфера, при которых размер считываемых записей увеличивается от 2 Кбайт до 8, 64, 256 Кбайт, до 1 и 4 Мбайт.
Конфигурирование сервера
Перед тем как запустить утилиту Response Probe, необходимо настроить оборудование сервера (как если бы компьютеру предстояло выполнять обычную работу), а затем вспомогательные программы и утилиты (скажем, антивирусные утилиты и программные средства мониторинга), которые будут выполняться одновременно с главным приложением. Следует использовать только те программы и службы, характеристики которых в плане требований к ресурсам не подвержены значительным колебаниям во времени. Например, такая служба, как SNMP Agent в Windows NT, увеличивает нагрузку на сервер, но эта нагрузка остается постоянной: на нее не влияют ни число подключенных пользователей, ни другие факторы, поэтому данную службу можно включать в конфигурацию. А использовать Microsoft SQL Server при тестировании не рекомендуется, потому что нагрузка от этого приложения может меняться.
Работа с утилитой Response Probe
Response Probe устанавливается на сервере в процессе инсталляции комплекта ресурсов. В ходе процедуры установки никакие параметры не нужны. Весь инструментарий состоит из файлов, хранящихся в папке tres-kitperftoolprobe (сюда же входит подкаталог с примерами).
После того как три файла сценариев определены, запуск Response Probe не вызывает затруднений. Утилита активизируется из командной строки. При этом используются следующие син-таксические конструкции:
probe
где ProcessFileName.scr - имя файла сценария процессов, в котором описываются тестируемые потоки, Trial Time - хронометраж предстоящего теста (в секундах), а OutputFileName - необязательный параметр, обеспечивающий формирование выходного файла (с расширением .out), в который Response Probe будет записывать результаты испытаний (по умолчанию выходной файл получает имя Pro-cessFileName.out). Управление утилитой, установленной на другом ком-пьютере, не предусмотрено. Нужно запускать ее на той системе, которую требуется испытать.
Одна из наиболее важных функций утилиты Response Probe - возможность выяснить, насколько новый сервер мощнее того, который предстоит заменить. Поставщики серверного оборудования снабжают свои изделия обширными статистическими выкладками по эксплуатационным характеристикам, но как на основании данных об увеличении тактовой частоты процессора, снижении времени поиска данных на диске, емкос-ти оперативной памяти, разрядности шины процессора и полосы пропускания сетевого интерфейса сделать вывод об общей производительности сис-темы? Многие из этих факторов меняются с появлением новой модели сервера, так что сравнивать серверы по номинальным характеристикам их компонентов практически невозможно. Между тем, говоря о новом сервере, клиенты чаще всего хотят знать, насколько быстрее он будет работать.Я считаю, что основное достоинство Response Probe именно в том, что данная утилита позволяет ответить на этот вопрос. Ведь с ее помощью можно определить подлинный базовый уровень производительности системы. Выполнив Response Probe на сервере приложений, который используется уже в течение двух лет, можно получить соответствующий базовый уровень, позволяющий оценивать кандидатов на замену этого сервера. Затем нужно выполнить Response Probe с той же программной конфигурацией на более новых серверах и сопоставить результат с итогами теста на старом сервере. Таким образом можно четко определить, насколько системы отличаются друг от друга по производительности. Другие средства, например Microsoft Performance Monitor, предоставляют сведения лишь об отдельных компонентах сервера, тогда как утилита Response Probe дает полную картину его эксплуатационных характеристик.
Джо Рудич - сетевой администратор из Сан-Паула, шт. Миннесота. С ним можно связаться по адресу: joe@rudich.com.