Сегментирование кэш-памяти и быстродействие жестких дисков


В первой части данного обзора мы познакомились с режимом Performance Mode у SCSI-дисков Seagate Cheetah со скоростью вращения 10 000 и 15 000 об./мин — Cheetah 10K.7 и Cheetah 15K.4. Напомню, что утилита Seagate SeaTools Enterprise позволяет пользователю управлять политикой кэширования и, в частности, переключать новейшие SCSI-диски Seagate между двумя разными моделями кэширования — Desktop Mode и Server Mode. Этот пункт в меню SeaTools носит название Performance Mode (PM) и может принимать два значения — On (Desktop Mode) и Off (Server Mode). Отличия между этими двумя режимами чисто программные — в случае Desktop Mode кэш-память жесткого диска разбивается на фиксированное число сегментов постоянного (одинакового) объема и далее они используются для кэширования обращений при чтении и записи. Причем, в отдельном пункте меню пользователь даже может сам назначать количество сегментов (управлять сегментированием кэша): например, вместо дефолтных 32 сегментов проставить другое значение (при этом объем каждого сегмента пропорционально уменьшится).

В случае же Server Mode сегменты буфера (кэша диска) могут динамически (пере)назначаться, меняя при этом свой размер и количество. Микропроцессор (и микропрограмма) диска сами динамически оптимизируют количество (и емкость) сегментов кэш-памяти в зависимости от поступающих для исполнения на диск команд.

Тогда мы смогли выяснить, что использование новых накопителей Seagate Cheetah в режиме «Desktop» (при фиксированном сегментировании по умолчанию — на 32 сегмента) вместо дефолтного «Server» с динамическим сегментированием способно немного поднять производительность дисков в ряде задач, более характерных для настольного компьютера или медиа-серверов. Причем, эта прибавка порой может достигать 30-100% (!) в зависимости от типа задачи и модели диска, хотя в среднем она оценивается величиной 30%, что, согласитесь, тоже неплохо. Среди таких задач — рутинная работа настольного ПК (тесты WinBench, PCmark, H2bench), чтение и копирование файлов, дефрагментация. При этом в чисто серверных приложениях производительность накопителей почти не падает (если и падает, то незначительно). Впрочем, заметный выигрыш от использования Desktop Mode мы смогли наблюдать только на диске Cheetah 10K.7, тогда как ее старшей сестрице Cheetah 15K.4 оказалось почти все равно, в каком из режимов работать над настольными приложениями.

Пытаясь разобраться дальше, как влияет сегментирование кэш-памяти этих жестких дисков на производительность в различных приложениях и какие режимы сегментирования (какое количество сегментов памяти) более выгодно при выполнении тех или иных задач, я исследовал влияние количества сегментов кэш-памяти на производительность диска Seagate Cheetah 15K.4 в широком диапазоне значений — от 4 до 128 сегментов (4, 8, 16, 32, 64 и 128). Результаты этих исследований и предлагаются вашему вниманию в этой части обзора. Подчеркну, что данные результаты интересны не только сугубо для этой модели дисков (или SCSI-дисков Seagate в целом) — сегментирование кэш-памяти и выбор количества сегментов — это одно из основных направлений оптимизации firmware, в том числе, настольных дисков с интерфейсом ATA, которые сейчас также оснащаются преимущественно буфером 8 Мбайт. Поэтому описанные в данной статье результаты производительности накопителя в различных задачах в зависимости от сегментирования его кэш-памяти имеют отношение и к индустрии настольных ATA-накопителей. А поскольку методика испытаний была описана в первой части, переходим непосредственно к самим результатам.

Впрочем, прежде, чем перейти к обсуждению результатов, взглянем чуть подробнее на устройство и работу сегментов кэш-памяти диска Seagate Cheetah 15K.4, чтобы лучше понимать, о чем идет речь. Из восьми мегабайт для собственно кэш-памяти (то есть для кэширующих операций) здесь доступно 7077 Кбайт (остальное — служебная область). Эта область делится на логические сегменты (Mode Select Page 08h, byte 13), которые используются для чтения и записи данных (для осуществления функций упреждающего чтения с пластин и отложенной записи на поверхность диска). Для обращения к данным на магнитных пластинах сегменты используют именно логическую адресацию блоков накопителя. Диски этой серии поддерживают максимум 64 сегмента кэш-памяти, причем длина каждого сегмента равна целому числу секторов диска. Объем доступной кэш-памяти, по всей видимости, распределяется поровну между сегментами, то есть если сегментов, скажем, 32, то объем каждого сегмента равен примерно 220 Кбайт. При динамической сегментации (в режиме PM=off) количество сегментов может меняться винчестером автоматически в зависимости от потока команд от хоста.

Приложения для серверов и настольных компьютеров требуют различных операций кэширования от дисков для обеспечения оптимальной производительности, поэтому сложно обеспечить единую конфигурацию для наилучшего выполнения этих задач. По мнению Seagate, для «настольных» приложений требуется сконфигурировать кэш-память так, чтобы быстро отвечать на повторяющиеся запросы большого количества небольших сегментов данных без задержек на упреждающее чтение смежных сегментов. В серверных задачах, напротив, требуется так сконфигурировать кэш, чтобы обеспечить поступление больших объемов последовательных данных в неповторяющихся запросах. В этом случае более важна способность кэш-памяти хранить больше данных из смежных сегментов при упреждающем чтении. Поэтому для Desktop Mode производитель рекомендует использовать 32 сегмента (в ранних версиях Cheetah использовались 16 сегментов), а для Server Mode адаптивное количество сегментов стартует всего с трех на весь кэш, хотя в процессе работы может и увеличиваться. Мы в своих экспериментах по поводу влияния количества сегментов на производительность в различных приложениях ограничимся диапазоном от 4 сегментов до 64 сегментов, а в качестве проверки «прогоним» диск также при 128 сегментах, установленных в программе SeaTools Enterprise (программа при этом не сообщает, что данное количество сегментов в этом диске недопустимо).

 

Результаты тестов физических параметров

Графики скорости линейного чтения при разном количестве сегментов кэш-памяти приводить никакого смысла нет — они одинаковы. А вот по измеренной тестами скорости работы интерфейса Ultra320 SCSI можно наблюдать весьма любопытную картину: при 64 сегментах некоторые программы начинают неправильно определять скорость работы интерфейса, снижая ее более чем на порядок.

По измеренному среднему времени доступа отличия между различным количеством сегментов кэш-памяти становятся более заметны — по мере снижения сегментации среднее измеренной под Windows время доступа при чтении немного растет, а существенно лучшие показания наблюдаются в режиме PM=off, хотя утверждать при этом, что количество сегментов очень мало или, наоборот, очень велико, на основании этих данных сложно. Возможно, что диск в данном случае просто начитает игнорировать префетч при чтении, чтобы исключить дополнительных задержки.

Об эффективности работы алгоритмов отложенной записи firmware диска и кэширования записываемых данных в буфере накопителя можно попытаться судить по тому, как падает среднее измеренное операционной системой время доступа при записи относительно чтения при включенном write-back кэшировании накопителя (оно в наших тестах было всегда включено). Для этого мы обычно используем результаты теста C'T H2benchW, но в этот раз дополним картину и тестом в программе IOmeter, паттерны чтения и записи для которой использовали стопроцентно случайный доступ блоками по 512 байт с единичной глубиной очереди запросов. (Разумеется, не следует думать, что average write access time на двух диаграммах ниже реально отражает данную физическую характеристику накопителей! Это лишь некий программно измеряемый при помощи теста параметр, по которому можно судить об эффективности кэширования записи в буфере диска. Реальное заявленное производителем среднее время доступа при записи для Cheetah 15K.4 составляет 4,0+2,0=6,0 мс). Кстати, предвидя вопросы, замечу, что в данном случае (то есть когда в диске разрешена отложенная запись) накопитель рапортует хосту об успешном завершении команды записи (статус GOOD) сразу, как только они записаны в кэш-память, а не непоседственно на магнитный носитель. Этим и обусловлено меньшее значение измеренного извне average write access time, чем для аналогичного параметра при чтении.

По результатам этих тестов налицо ясная зависимость эффективности кэширования случайной записи мелких блоков данных от количества сегментов кэш-памяти — чем больше сегментов, тем лучше. При четырех сегментах эффективность резко падает и среднее время доступа при записи возрастает почти до значений при чтении. А в «серверной моде» число сегментов в данном случае, очевидно, близко к 32. Случаи 64 и "128" сегментов полностью идентичны, что подтверждает программное ограничение на уровне 64 сегментов сверху.

Интересно, что тест IOmeter в простейших паттернах на случайный доступ блоками 512 байт дает совершенно такие же значения при записи, что и тест C'T H2BenchW (с точностью буквально до сотых долей миллисекунды), тогда как при чтении IOmeter показал несколько завышенный результат во всем диапазоне сегментирования — возможно, разница в 0,1-0,19 мс с другими тестами на время случайного доступа при чтении обусловлена какими-то «внутренними» причинами для IOmeter (или же размером блока 512 байт вместо 0 байт, как требуется в идеале для таких измерений). Впрочем, результаты «по чтению» у IOmeter практически совпадают с таковыми для дискового теста программы AIDA32.

 

Быстродействие в приложениях

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

Данная диаграмма позволяет нам судить об эффективности алгоритмов многопотоковой отложенной записи жестких дисков в реальных (а не синтетических, как было на диаграмме со средним временем доступа) условиях при работе операционной системы с файлами. Лидерство обоих SCSI-дисков Maxtor при записи несколькими одновременными потоками не вызывает сомнений, однако у Читы мы уже наблюдаем некий оптимум в районе между 8 и 16 сегментами, тогда как при более высоких и более низких значениях скорость диска на данных задачах падает. Для Server Mode число сегментов, очевидно, равно 32 (с хорошей точностью :)), а "128" сегментов — это, на самом деле, 64.

При многопотоковом чтении ситуация для дисков Seagate явно улучшается по сравнению с дисками Maxtor. Что же касается влияния сегментации, то, как и при записи, мы наблюдаем некий оптимум ближе к 8 сегментам (при записи он был ближе к 16 сегментам), а при очень высоком сегментировании (64) скорость диска существенно понижается (как и при записи). Отрадно, что Server Mode тут «отслеживает базар» хоста и меняет сегментирование с 32 при записи на ~8 при чтении.

Теперь посмотрим, как диски ведут себя в «преклонных», но до сих пор популярных тестах Disk WinMark 99 из пакета WinBench 99. Напомню, что мы проводим эти тесты не только для «начала», но и для «середины» (по объему) физического носителя для двух файловых систем, а на диаграммах приведены усредненные результаты. Безусловно, данные тесты не являются «профильными» для SCSI-накопителей, и мы приводя тут их результаты скорее отдаем дань уважения самому тесту и тем, кто привык судить о скорости диска по тестам WinBench 99. В качестве «утешения» заметим, что эти тесты с определенной долей достоверности покажут нам, какова производительность этих enterprise-накопителей при выполнении задач, более характерных для настольного компьютера.

Очевидно, что оптимум сегментирования есть и здесь, причем при малом количестве сегментов диск смотрится невыразительно, а при 32 сегментах — наилучшим образом (возможно, именно поэтому разработчики Seagate «сместили» дефолтную настройку Desktop Mode с 16 до 32 сегментов). Впрочем, для Server Mode в офисных (Business) задачах сегментирование не совсем оптимально, тогда как для профессиональной (High-End) производительности сегментирование более чем соптимизировано, заметно обгоняя даже оптимальную «постоянную» сегментацию. Видимо, именно в процессе выполнения теста она меняется в зависимости от потока команд и за счет этого получается выигрыш в общей производительности.

К сожалению, такой оптимизации «по ходу теста» не наблюдается для более свежих «трековых» комплексных тесты оценки «настольной» производительности дисков в пакетах PCMakr04 и C'T H2BenchW.

На обоих (а точнее — на 10 различных) «треках активности» интеллект Server Mode заметно уступает оптимальной постоянной сегментации, которая для PCmark04 равна примерно 8 сегментам, а для H2benchW — 16 сегментам.

Для обоих этих тестов 4 сегмента кэш-памяти оказывается очень нежелательным, да и 64 тоже, и сложно сказать, к чему больше тяготеет в своем выборе Server Mode в данном случае.

В противовес этим, безусловно, все же синтетическим (хотя и очень похожим на реальность) тестам — совершенно «реальный» тест скорости работы дисков с временным файлом программы Adobe Photoshop. Здесь ситуация гораздо позрачнее — чем больше сегментов, тем лучше! И Server Mode это почти «уловила», воспользовавшить 32 сегментами для своей работы (хотя 64 было бы еще чуточку лучше).

 

Тесты в Intel Iometer

Переходим к задачам, более характерным для профилей использования SCSI-накопителей — работе различных серверов (DataBase, File Server, Web Server) и рабочей станции (Workstation) по соответствующим паттернам в программе Intel IOmeter версии 2003.5.10.

С имитацией сервера базы данных успешнее всех справляется Maxtor, а для Seagate выгоднее всего использование Server Mode, хотя по сути последняя очень близка к 32 постоянным сегментам (объемом примерно по 220 кбайт каждый). Меньшее или большее сегментирование в данном случае оказывается хуже. Впрочем, это паттерн слишком прост по виду запросов — посмотрим, что будет для более комплексных паттернов.

При имитации файлового сервера лидирует снова адаптивная сегментация, хотя отставание от нее 16 постоянных сегментов ничтожно (32 сегмента тут чуть хуже, хотя тоже вполне достоны). При малом сегментировании наблюдается ухудшение на большой очереди команд, а при слишком большом (64) любая очередь вообще противопоказана — видимо, в этом случае слишком малым оказывается размер секторов кэша (менее 111 Кбайт, то есть всего 220 блоков на носителе), чтобы эффективно кэшировать приемлемые по размеру объемы данных.

Наконец, для Web-сервера мы видим даже более занятную картину — при НЕединичной очереди команд Server Mode равноценна любому уровню сегментирования, кроме 64, хотя на единичной она чуть лучше всех.

В результате геометрического усреднения показанных выше серверных нагрузок по паттернам и очередям запросов (без весовых коэффициентов) получаем, что для подобных задач адаптивное сегментирование лучше всего, хотя 32 постоянных сегмента отстают незначительно, да и 16 сегментов тоже смотрятся в целом неплохо. В общем, выбор Seagate вполне можно понять.

Что касается паттерна «рабочая станция», тот здесь Server Mode явно лучше всех.

А оптимум для постоянной сегментации находится на уровне 16 сегментов.

Теперь — наши паттерны для IOmeter, более близкие по назначению настольным ПК, хотя определенно показательные и для enterprise-накопителей, поскольку и в «глубоко профессиональных» системах жесткие диски львиную долю времени считывают и записывают большие и маленькие файлы, а также иногда копируют файлы. А поскольку характер обращений в данных паттернах в данных паттернах в тесте IOmeter (по случайным адресам в пределах всего объема диска) более характерен именно для систем серверного класса, то и важность этих паттернов для исследуемых дисков выше.

Чтение крупных файлов снова лучше дается для Server Mode, за исключением непонятного провала на QD=4. Однако небольшое количество крупных сегментов явно предпочтительнее для диска на этих операциях (что, в принципе, предсказуемо и отлично согласуется с результатами для многопотокового чтения файлов, см. выше).

Спорадическая запись крупных файлов, напротив, пока «не по зубам» интеллекту Server Mode, и здесь выгоднее постоянная сегментация на уровне 8-16 сегментов, как и при многопоточной записи файлов, см. выше. Отдельно отметим, что на этих операциях крайне вредным является большое сегментирование кэша — на уровне 64 сегментов. Однако оно оказывается полезным для операций с чтением мелкими файлами при большой очереди запросов:

Думаю, именно это использует Server Mode для выбора адаптивного режима — уж очень похожи их графики.

Вместе с тем, при записи мелких файлов по случайным адресам 64 сегмента снова провальны, а Server Mode здесь уступает постоянной сегментации с уровнем 8-16 сегментов на кэш, хотя видно старание Server Mode использовать оптимальные настройки (только с 32-64 сегментами на очереди 64 вышла незадача ;)).

Копирование крупных файлов — явная неудача Server Mode! Здесь явно выгоднее сегментирование с уровнем 16 (это оптимум, поскольку 8 и 32 хуже на очереди 4).

Что же касается копирования мелких файлов, то 8-16-32 сегмента здесь практически равноценны, обгоняя 64 сегмента (как это ни странно), а Server Mode немного «чудит».

По результатам геометрического усреднения данных для случайного чтения, записи и копирования крупных и мелких файлов получаем, что наилучший в среднем результат дает постоянное сегментирование с уровнем всего 4 сегмента на кэш (то есть размеры сегментов более 1,5 Мбайт!), тогда как 8 и 16 сегментов примерно равноценны и почти не отстали от 4 сегментов, а вот 64 сегмента явно противопоказаны. Адаптивная Server Mode в среднем лишь немного уступила постоянной сегментации — проигрыш одного процента вряд ли можно считать заметным.

Остается отметить, что при имитации дефрагментации мы наблюдаем примерное равенство всех уровней постоянной сегментации и небольшое преимущество Server Mode (на тот же 1%).

А в паттерне потоковых чтения-записи крупными и мелкими блоками слегка выгоднее использование малого количества сегментов, хотя снова отличия в быстродействии конфигураций кэш-памяти здесь, как ни странно, гомеопатичны.

 

Выводы

Проведя во второй части нашего обзора более детальное исследование влияния сегментирования кэш-памяти на быстродействие накопителя Seagate Cheetah 15K.4 в разнообразных задачах, хочется отметить, что разработчики недаром назвали режимы кэширования так, как они их назвали: в Server Mode действительно нередко проводится адаптация сегментирования кэш-памяти под выполняемую задачу и это, порой, приводит к весьма неплохим результатам — особенно при выполнении «тяжелых» задач, среди которых и серверные паттерны в Intel IOmeter, и тест High-End Disk WinMark 99, и случайное чтение мелких блоков по всему диску… Вместе с тем, нередко выбор уровня сегментирования кэш-памяти в Server Mode оказывается неоптимальным (и требует дальнейшей работы по улучшению критериев анализа потока команд хоста), и тогда вперед выходит Desktop Mode с фиксированным сегментированием на уровне 8, 16 или 32 сегментов на кэш. Причем, в зависимости от типа задачи иногда выгоднее использовать 16 и 32, а иногда — 8 или всего 4 сегмента памяти! Среди последних — многопотоковые чтения и запись (как случайные, так и последовательные), «трековые» тесты вроде PCMark04 и потоковые задачи с одновременным чтением и записью. Хотя «синтетика» на случайный доступ при записи явно показывает, что эффективность отложенной записи (по произвольным адресам) существенно снижается с уменьшением числа сегментов. То есть налицо борьба двух тенденций — и именно поэтому в среднем эффективнее использовать 16 или 32 сегмента на 8-мегабайтный буфер. При удвоении объема буфера можно предсказать, что выгоднее сохранить количество сегментов на уровне 16-32, но за счет пропорционального увеличения емкости каждого сегмента средняя производительность накопителя может существенно повыситься. Видимо, даже неэффективное нынче в большинстве задач сегментирование кэша с 64 сегментами при удвоении объем буфера может оказаться очень полезным, тогда как использование в этом случае 4 и даже 8 сегментов станет малоэффективным. Впрочем, данные выводы сильно зависят еще и от того, какими блоками операционная система и приложения предпочитают оперировать с накопителем, и файлы какого размера при этом используются. Вполне возможно, что при изменении окружения оптимум сегментирования кэш-памяти может сместиться в ту или иную сторону. Ну а мы пожелаем Seagate успехов в оптимизации «интеллекта» Server Mode, которая, в определенной мере, может сгладить эту «системозависимость» и «задачезависимость», научившись наилучшим образом подбирать самое оптимальное сегментирование в зависимости от потока команд хоста.






Дополнительно

Нашли ошибку на сайте? Выделите текст и нажмите Shift+Enter

Код для блога бета

Выделите HTML-код в поле, скопируйте его в буфер и вставьте в свой блог.