Как и было обещано ранее, в этом обзоре мы рассмотрим совместное поведение диска Seagate Cheetah ST373307LW и контроллера Adaptec 39320D. Напомню, что в недавней статье про диски от Seagate и Fujitsu были получены странные результаты для Cheetah — при длине очереди, равной 64, во всех тестах IOMeter'а наблюдалось резкое падение производительности. Сегодня путем либо напряжения всех ресурсов серого вещества, либо шаманских танцев с бубнами и непременным помахиванием кроличьей лапкой нам предстоит прояснить эту ситуацию. А на разделочном столе после интернет-розысков присутствуют два драйвера контроллера 39320D от Adaptec'a, а также пойман за руку и находится под постоянным наблюдением один параметр реестра.
Итак, в прошлый раз для тестирования использовался драйвер версии 1.0.0.0, а в том самом пойманном за руку ключе реестра HKEY_LOCAL_MACHINESystem CurrentControlSetServicesadpu320ParametersDevice в параметре DriveParameter указана длина очереди, равная 64 (/MAXTAGS = 64). Сегодня попробуем поставить не так давно вышедший драйвер версии 1.1.0.0, а также посмотрим, как на производительность связки диск-контроллер влияют изменения вышеуказанного параметра.
Так как в этом обзоре рассматриваются вещи довольно специфические, хотелось бы ненадолго остановиться на некоторых терминах и понятиях, часто используемых в статье. Наверное, все знают, что Intel IOMeter есть синтетический тест, предназначенный для генерации определенным образом сформированного трафика. Если не вдаваться в детали, то трафик по сути своей есть поток команд на чтение-запись порций (блоков) информации различного размера. Исходя из этого определения и физической организации данных на диске логично предположить, что любой трафик типа диск-система можно характеризовать следующими параметрами: доля команд на чтение/запись, доли команд на работу с блоками каждого из размеров, тип трафика — последовательное или случайное чтение/запись, нагрузка на диск — длина очереди запросов, посылаемых на чтение/запись. В тесте Intel IOMeter имеется возможность управлять всеми этими параметрами и устанавливать их с точностью до 1%. Определенным образом заданные параметры представляют собой некоторые модели доступа. С другой стороны, статистически исследовав трафик, генерируемый машинами, работающими с реальными приложениями и имеющими определенные четко поставленные задачи, можно получить модели доступа, максимально приближенные к реальным (более подробно об используемых моделях доступа можно прочитать здесь). Есть еще один технический параметр — длина очереди посылаемых запросов, который характеризует интенсивность работы данной модели доступа. В наших тестах используются следующие обозначения этой длины: linear — queue = 1 (линейное чтение/запись), very light — queue = 4, light — queue = 16, moderate — queue = 64, heavy — queue = 256 (наиболее плотный поток запросов). В сегодняшних тестах мы временно отойдем от этих обозначений и для удобства представления результатов будем использовать непосредственные численные значения длины очереди. Теперь, после краткого технологического экскурса, можно перейти непосредственно к тестам.
Тесты
Конфигурация тестового стенда стандартная:
- Системная плата — Supermicro 370DLE (BIOS ver. R1.32);
- Процессор — Intel Pentium III 800EB;
- Память — 512 MB PC133 SDRAM;
- Системный диск — Western Digital WD100BB-00AUA1;
- ОС — Windows 2000 Professional SP3;
- SCSI-адаптер — Adaptec 39320D (driver ver. 1.0.0.0 и ver. 1.1.0.0).
А в крутить диски сегодня будем только в Intel IOMeter в шести основных паттернах (Workstation, File-server, Web-server, Database, Random read & Random write). Intel IOMeter
В прошлый раз все было просто — драйвер версии 1.0.0.0 с параметрами по умолчанию. Не прост был только результат, с трудом поддающийся какому-либо логическому объяснению. Итак, лезем на www.adaptec.com, скачиваем драйвер 1.1.0.0 и устанавливаем его, попутно отслеживая вносимые в реестр изменения каким-нибудь продвинутым инсталлятором/деинсталлятором, например Ashampoo Uninstaller. Из log-файла инсталляции видно, что параметр, программно ограничивающий максимальную длину очереди (в дальнейшем будем называть его «MAXTAGS», в отличие от значения «queue» или «длина очереди», характеризующего нагрузку, генерируемую тестом Intel IOMeter), поменял значение с 64 на 32. Крутим тесты, получаем красивые ровные результаты во всех паттернах:
Единственный недостаток — при увеличении длины очереди выше 32 и, соответственно, нагрузки на диск, о всяком росте производительности можно забыть, что не есть хорошо для диска, рассчитанного на активное серверное использование. Попробуем увеличить значение MAXTAGS до 64, а потом и до 256 — максимально возможного значения. Оп-п-па! Всего лишь изменением одного параметра в реестре драйвер версии 1.1.0.0 не то, чтобы превращается, но, по крайней мере, полностью повторяет результаты, полученные на драйвере 1.0.0.0. Для полноты картины сносим новый и ставим старый драйвер, а заодно изменяем параметр MAXTAGS на 32, и… По-моему, у меня дежа вю. Полученные результаты повторяют те, что получились на драйвере 1.1.0.0 и по умолчанию установленном значении параметра MAXTAGS = 32. Короче, смотрите ниже:
Кстати, хотелось бы сделать небольшое замечание. Тесты с драйверами версии 1.1.0.0 и значением MAXTAGS, равным 256, неоднократно запускались также на этой же тестовой машине, но с установленным Windows 2000 Professional и вторым Service Pack'ом, и ни в одном из паттернов не смогли успешно завершиться, зависая при попытках увеличить длину очереди до 64. С чем это связано, и почему на третьем Service Pack'е ничего подобного не происходит — загадка.
Итого мы имеем: при MAXTAGS = 32 на любых драйверах получаются уверенно ровные результаты, при большем значении MAXTAGS также на любых драйверах имеют место скачки производительности.
Выводы
В общем, картина получается интереснейшая. По результатам проведенных тестов кажется, что новая версия драйвера отличается от старой только значением одного параметра в реестре. Еще большее недоумение вызывает то, что новое значение параметра только обрезает производительность диска, а не лечит необъяснимые скачки его производительности. Эту ситуацию можно было бы отметить как интересную и труднообъяснимую и не очень-то заморачиваться в связи с нею, если бы не одно «но». Оба продукта — и Seagate Cheetah 10K.6, и Adaptec 39320D являются типичными и широко распространенными представителями классов SCSI-десятитысячников и Ultra320-контроллеров соответственно двух ранее отлично себя зарекомендовавших фирм, что делает выбор этих продуктов в качестве эталонного диска и контроллера вполне естественным. В сухом остатке имеется то, что у нас, с одной стороны, нет достаточно обоснованных претензий в этой связке, чтобы заменять контроллер, диск или их обоих на что-то другое, а с другой стороны, полученные результаты достаточно весомы, чтобы не закрывать на них глаза.
В результате принимается волевое решение оставить и диск, и контроллер в качестве тестовых эталонов, а для тестирования использовать версию драйвера контроллера Adaptec 39320D 1.1.0.0 со значением MAXTAGS = 256. Это значение параметра выбрано как не обрезающее возможной производительности дисков и не ограничивающее искусственно максимальную длину очереди запросов. Версия 1.1.0.0 выбрана в надежде, что инженеры Adaptec все-таки внесли еще какие-то изменения в драйвер, помимо изменения одного параметра в реестре (все-таки занимает он на одну сотню килобайт, что для драйверов немало). Засим разрешите откланяться, меня ждет милый пятнадцатитысячник от Seagate, но про него в другой раз…
