`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Мониторинг и оптимизация дисковой подсистемы сервера

+1111
голосов

Вычислительная мощность центральных процессоров далеко не всегда является определяющим параметром производительности серверов в массовых приложениях. Опытные пользователи платформы 1С:Предприятие знают это как никто другой.

Говоря об 1С как «пожирателе ресурсов», надо понимать, что половину предприятий страны эта система делопроизводства устраивает и у них нет достаточных оснований для перехода на другую. Можно сколько угодно пенять на издержки архитектуры приложения и качество программного кода, но .... «жизнь такова, какова она есть, и больше никакова». Но даже если свобода действий сводится к оптимизации одного только серверного оборудования, ею нужно пользоваться. Вдумчивому администратору мониторинг подсистем собственного сервера под реальной нагрузкой дает много больше информации, чем ковровые бомбардировки всех продавцов вместе взятых.

Вклад в производительность сервера его основных подсистем: центральных процессоров , оперативной памяти, дискового и сетевого ввода/вывода зависит от приложений и типов данных, с которыми они работают. По многообразию решаемых задач нет равных дисковой подсистеме, которая отвечает за сохранность и доступность данных, производительность дисковых операций, восстановление информации после отказа накопителей. При такой «многовекторности» исключено появление единого стандарта или законодателя мод, подобного Intel на рынке процессоров. Тем не менее, существующая мешанина подходов/интерфейсов/типов накопителей/политик — не повод для крайностей: перебора всех возможных комбинаций или, наоборот, бездумной веры в бренд. Существует стандартный инструментарий оценки вычислительной нагрузки. Тому, кто не ленится приложить усилия к замерам параметров и анализу результатов, наградой будет точное соответствие проектируемого сервера задачам, а значит — существенная экономия как стартовых, так и операционных затрат. Попробуем разложить характеристики нагрузки по полочкам. Сделаем это на примере базовой ОС Microsoft Windows Server 2008 R2 и ее встроенного инструмента Windows Performance Monitor (Системный монитор Windows), параметр за параметром. Типичный вид результатов мониторинга приведен на Рис 1.

Мониторинг и оптимизация дисковой подсистемы сервера

Включение датчиков - физический диск

1. % Free Space — процент свободного пространства на логическом диске. Если свободно менее 15% емкости диска, он считается перегруженным, а его дальнейший анализ некорректным — на него будет влиять фрагментированность данных. Рекомендуемый объем свободного места на серверном диске — не менее 20%.

2. Avg. Disk sec/Transfer — среднее время обращения к диску. Параметр показывает усредненное время в секундах, требуемое для одной операции обмена данными с диском. Для слабо нагруженных систем (например, файловых хранилищ) его значение не должно превышать 0,25 секунды. Для высоконагруженных серверов (SQL, Exchange, VDI) — 0,1 секунды. Большие значения параметра говорят о перегрузке дисковой подсистемы. Для понимания, какие именно операции, чтения или записи, и в какой пропорции съедают время, считывают показатели Avg. Disk sec/Read (среднее время чтения с диска в секундах) и Avg. Disk sec/Write (среднее время обращения к диску на запись). К примеру, интегральный показатель Avg. Disk sec/Transfer в RAID5 при существенном преобладании операций чтения может быть в пределах нормы, но при этом операции записи проходить чрезвычайно медленно. Особенно важен параметр Avg. Disk sec/Write для массивов на дисках SSD, массивах с SSD-кешированием, любых массивах RAID 5 и RAID 6.

Радикально снижает значение Avg. Disk sec/ Read переход с HDD на SSD, с размещением на твердотельных накопителях «горячих» (наиболее востребованных) данных, особенно если их объем невелик. Приложениям с преимущественно линейным чтением данных большого объема (к примеру, видеопотоков) традиционно помогает увеличение количества дисков HDD в массиве. При большом показателе Avg. Disk sec/Write в первую очередь нужно обратить внимание на уровень RAID—массива, его «штраф на запись». Дело в том, что для записи избыточной информации в массиве необходимо вместо одной операции записи выполнить две и более. Штраф на запись для одиночного диска и RAID 0 равен «1» (на запись данных тратится одно обращение RAID-контроллера к дискам). Для RAID 1 и RAID 10 — штраф на запись равен «2» (для записи одного блока данных контроллер делает два обращения на запись к дискам — что, в свою очередь, приводит к общему снижению производительности дисковой подсистемы RAID 1 и RAID 10 в IOPS на запись в два раза относительно производительности этих же дисков в IOPS в RAID 0). Штраф на запись для RAID 5 равен «4», а для RAID 6 — «6». Если собран массив RAID 5 или RAID 6 и его среднее время отклика высоко — надо либо переходить к менее ресурсоемкому на запись RAID 10, либо увеличивать количество физических дисков в RAID-массиве.

Мониторинг и оптимизация дисковой подсистемы сервера

PerfMon за работой

SSD — хороший инструмент и для снижения задержек записи, особенно в приложениях класса SQL Server или Exchange Server. Самый революционный эффект дают SSD, устанавливаемые напрямую в слот PCI Express — как Fusion’s ioDrive (SLC и MLС), LSI WarpDrive (SLC и MLC) или Intel 910 (MLC), хоть и в разной степени, с разбросом цен от $2K до $15K. Более привычно подключение автономных накопителей SSD к высокопроизводительному RAID-контроллеру. Для массива из одних только SSD можно рекомендовать контроллеры LSI MegaRAID SAS 926x/928x со включенной опцией FastPath или 7-й серию Adaptec. Самым «бархатным» вариантом считается SSD-кеширование (LSI CacheCade 2.0, Adaptec MaxCache 3.0) — когда SSD включаются в массивы HDD в качестве кеша второго уровня RAID-контроллеров. Обсуждая SSD под корпоративные приложения, мы говорим о накопителях как минимум уровня Seagate Pulsar.2 (MLC) или Intel 710 (MLC) . Ожидать высокой производительности в серверных задачах и под существенной нагрузкой десктопных дисков класса Intel 520 не приходится (хоть они и бьют HDD SAS 15K rpm по паспортной производительности).

3. Интегральный показатель Avg. Disk Queue Length (средняя длина очереди диска), и его составляющие: Avg. Disk Read Queue Length (средняя длина очереди к диску на чтение) и Avg. Disk Write Queue Length (средняя длина очереди к диску на запись). Данный показатель указывает, сколько операций ввода/вывода в среднем ожидают, когда жесткий диск станет доступным. Он не измеряется, а вычисляется по закону Литтла из теории очередей как (Disk Transfers/sec) *(Disk sec/Transfer) или N = A * Sr, где N — число ожидающих запросов в системе, A — скорость поступления запросов, Sr — время отклика. Для нормально работающей дисковой подсистемы этот показатель не должен превышать больше чем на 1 количество дисков в RAID-группе. В приложениях класса SQL Server, Exchange Server его среднее значение лучше удерживать на уровне менее 0.2. Его уменьшению способствует SSD-кеширование, перенос «горячих» данных на SSD, на худой конец — традиционное увеличение количества дисков в RAID-группе. Среднюю длину очереди к диску на чтение снижает переход на SSD, а среднюю длину очереди на запись — отказ от вариантов RAID с большим штрафом на запись RAID 5 и RAID 6 — в пользу RAID 10.

4. Current Disk Queue Length (текущая длина очереди диска) показывает число не выполненных и ожидающих обработки запросов, адресованных выбранному диску. Это текущее значение, моментальный показатель, а не среднее значение за интервал времени. Время задержки пропорционально длине очереди. В установившемся режиме количество ожидающих запросов не должно превышать количество физических дисков в массиве более чем в 1,5-2 раза. При этом массив из нескольких дисков может одновременно выбирать из очереди по одному запросу на каждый диск. Текущую очередь укорачивают теми же методами, что и среднюю, с одной оговоркой: кратковременные пики нагрузки хорошо гасятся скоростными RAID-контроллерами с большим объемом кеш-памяти. При длительных пиках стоит применить SSD-кеширование, перевести «горячие» данные на SSD или в гибридный том SSD/HDD, увеличить число дисков в RAID-группе.

Мониторинг и оптимизация дисковой подсистемы сервера

Avg. Disk sec/Read + Avg. Disk sec/Write

5. % Disk Time (% активности диска), % Disk Read Time (% активности диска при чтении), % Disk Write Time (% активность диска при записи) — процент времени, затраченного дисковым устройством на обработку запросов (всего, по чтению и по записи). Показания этого счетчика в массиве охватывают больше чем один физический диск, и могут превышать 100%. Тем не менее, желательно, чтобы общая загрузка не превышала 80 — 90% (особенно важно для массивов из SSD). Этот счетчик не всегда показателен, его надо анализировать вместе с % Idle Time (процент времени бездействия).

Править эти показатели можно по-разному. Например, разместить данные на различных массивах в зависимости от типа нагрузки: таблицы SQL на одной RAID-группе дисков, а лог-файлы SQL — на другой. Помогает установка RAID-контроллера с большим объемом кеша (или SSD-кешем) и включенным кешированием записи — отложенная запись в пакетном режиме снижает зависимость от латентности дисков. Хорошо работает традиционный способ увеличения количества дисков в массиве, замена дисков на более быстрые HDD или SSD.

6. % Idle Time (% времени бездействия) — доля интервала между измерениями, в течение которого физический диск бездействовал. Фактически, зеркальный параметр для % Disk Time и применим исключительно к физическим дискам. Желательно, чтобы в сервере параметр был не менее 15-20% для HDD и не менее 20-25% для SSD. Инструменты его улучшения — точно такие же, как для предыдущего параметра: RAID-контроллер с большим кешем и/или SSD-кеширование, больше дисков в RAID-группе, переход на более быстрые диски HDD и SSD.

Мониторинг и оптимизация дисковой подсистемы сервера

Avg. Disk Queue Length - пример нагруженного сервера

7. Disk Transfers/sec (обращений к диску/сек) — количество отдельных дисковых запросов ввода-вывода, завершённых в течение одной секунды. Показывает реальные потребности приложений по случайному чтению и записи к дисковой подсистеме. Для дисков, работающих в нормальном режиме, нагрузка не должна превышать их физические пределы, с учетом количества дисков в массиве и его уровня RAID. Так, для RAID 10 (штраф на запись «2») штатные значения такие:

  • до 80 IOPS на каждый SATA или NL SAS диск;

  • до 160 IOPS на каждый SAS диск;

  • до 1800 IOPS на каждый бытовой SSD

  • до 5000 IOPS на каждый серверный SSD.

Как и любой показатель, суммирующий несколько отдельных счетчиков — не очень информативен, позволяет лишь оценить «обстановку в целом». Надо анализировать более содержательные Disk Reads/sec (обращений чтения с диска/сек) и Disk Writes/sec (обращений записи на диск/сек).

Disk Reads/sec — количество обращений чтения в секунду, то есть частота выполнения операций чтения с диска. Важнейший параметр для приложений класса SQL Server, Exchange Server, определяющий реальную производительность дисковой подсистемы. В нормальном устоявшемся режиме интенсивность обращений не должна превышать физические возможности дисков — их индивидуальным пределам, умноженным на количество дисков в массиве. Для RAID 10 это:

  • 100-120 IOPS на каждый SATA или NL SAS диск;

  • 200-240 IOPS на каждый SAS 15000 rpm диск;

  • 30 000-40 000 IOPS на каждый диск SSD класса интеловских серий 320 или 710;

  • до 90 000 IOPS для Intel SSD 910-й серии 400GB .

В режиме чтения для различных типов RAID могут учитываться не все диски. В том же RAID-6 в массиве из шести дисков скорость чтения равна скорости чтения с четырех дисков (с оставшихся двух считываются контрольные суммы).

Disk Writes/sec — количество обращений записи в секунду, то есть частота выполнения операций записи на диск. Чрезвычайно важный параметр для приложений класса SQL Server , чуть менее важный для Exchange Server. При работе в нормальном режиме интенсивность обращений не должна превышать физические пределы дисков, умноженные на их количество в массиве и с учетом штрафа на запись для выбранного типа RAID. Для RAID 10 (штраф на запись «2»):

  • 40-50 IOPS на каждый SATA или NL SAS диск;

  • 80-100 IOPS на каждый SAS диск;

  • 150-300 IOPS на бытовой SSD;

  • 1100-2400 IOPS на серверный SSD;

  • до 38 000 IOPS для Intel SSD 910-й серии 400GB.

Анализировать корректно Disk Reads/sec и Disk Writes/sec можно только с учетом текущей длины очереди Current Disk Queue Length и средней длины очередей чтения/записи Avg. Disk Read Queue Length и Avg. Disk Write Queue Length. Если Current Disk Queue Length или Avg. Disk Read Queue Length и Avg. Disk Write Queue Length существенно выходят за штатные пределы — скорее всего, реальная потребность в IOPS дисковой подсистемы будет в разы, а то и на порядок выше, чем фиксируют Disk Reads/sec и Disk Writes/sec. К примеру, если Current Disk Queue Length для массива RAID 10 из 4 дисков в какие-то интервалы времени достигает показателей 12-16, с пиками до 100 — то реальный спрос на операции ввода/вывода в эти моменты у приложений почти наверняка превышает возможности дисковой подсистемы в 2-3 раза. Если устоявшееся значение Current Disk Queue Length составляет 30-40, с пиками до 140-180 — значит реальный спрос на IOPS у приложений превосходит физические возможности дисковой подсистемы в 4-8 раз.

Влияние средней длины очередей чтения и записи на показатели Disk Reads/sec и Disk Writes/sec более сложно, и сильно зависит от характера приложений. К примеру, для того же RAID 10 из 4 дисков в режиме файл-сервера под нагрузкой вполне допустимы значения 2-4. Для базы данных приложения «1С:Предприятие 8.2» под MS SQL Server 2008R2 превышение значения 0.2 — уже повод задуматься, тогда как приближение к 0.8-1 — четкий сигнал к модернизации дисковой подсистемы.

Способы повышения производительности дисковой подсистемы в IOPS традиционны — увеличение количества дисков в RAID группе, применение технологий SSD-кеширования на чтение и запись, применение гибридных RAID и массивов из одних только SSD, переход к SSD-устройствам с интерфейсом PCI Express. Сгладить большие и непродолжительные пики Current Disk Queue Length поможет объемный кеш RAID-контроллера, но при длительных высоких нагрузках он будет малоэффективен.

Мониторинг и оптимизация дисковой подсистемы сервера

Current Disk Queue Length - длительные периоды пиков говорят о перегрузке по IOPS

8. Disk Bytes/sec — скорость обмена с диском в байт/сек, пропускная способность дисковой системы при выполнении операций чтения и записи. Этот параметр важен для задач потокового чтения/записи и редко бывает критичным для баз данных. Как и предыдущий параметр, привязан к физическим возможностям дисков. Приведенные ниже цифры — ориентировочные, реальные показатели очень сильно зависят от параметров конкретного диска, а для HDD снижаются почти в 2 раза при переходе с внешних на внутренние дорожки. Для интерфейсов SATA 2 и SAS 1.0 значения ограничены пропускной способностью интерфейса (300 MB/s) и составляют на больших блоках и последовательных операциях от 250 до 140 MB/s на каждый SATA, NL SAS, SAS, и порядка 300 MB/s на каждый SSD диск. Для интерфейсов SATA 3, SAS 2.0 на больших блоках и последовательных операциях — от 250 до 140 MB/s на каждый SATA, NL SAS, SAS , и до 550-600 MB/s на каждый SSD диск на последовательных операциях. SSD с интерфейсом PCI Express класса Intel SSD 910-й серии выдают до 1000 MB/s на чтение и до 750 MB/s на запись.

Disk Read Bytes/sec — скорость чтения с диска в байт/сек. Для корректного расчета предела возможностей дисков в различных вариантах RAID необходимо учитывать те из них, которые выдают информацию (для RAID 6 из 6 дисков — учитываем 4 диска, для RAID 10 из 6 дисков — учитываем 6 дисков).

Disk Write Bytes/sec — скорость записи на диск в байт/сек. Необходимо учитывать те диски, которые одновременно сохраняют различные данные (для RAID 6 из 6 дисков — учитываем 4 диска, для RAID 10 из 6 дисков — учитываем 3 диска). Наиболее эффективный способ повышения производительности дисковой подсистемы по скорости обмена — увеличение количества дисков в RAID-группе.

Мониторинг и оптимизация дисковой подсистемы сервера

Недостаточная производительность в IOPS по параметрам Disk Reads/sec и Disk Writes/sec приводит к длительным перегурзкам и снижению общей производительности, что видно по Avg. Disk Queue Length

9. Avg. Disk Bytes/Transfer — среднее количество байт данных, переданных при выполнении операций чтения или записи. Показывает средний объём операций ввода — вывода. Чем больше объем одного «пакета» — тем меньше нагрузка на дисковую подсистему. При нормальной работе этот параметр должен быть больше 20 Кбайт, значения меньше 20 Кбайт сигнализируют о неэффективности использования дисков приложением. Avg. Disk Bytes/Read — среднее количество байт данных, полученных с диска при выполнении операций чтения. Avg. Disk Bytes/Write — среднее количество байт данных, переданных на диск при выполнении операций записи.

Безусловно, основным путем улучшения данного параметра является оптимизация приложения. Для приложений класса SQL Server будет эффективным выделение большего пространства в оперативной памяти (RAM) под программный кеш. Помогает применение RAID-контроллера с включенным кешированием на запись и переход к использованию SSD во всех возможных вариантах — как более уместного накопителя для работы с короткими запросами случайного доступа.

10. Split IO/sec — частота расщепления операций ввода-вывода диска на несколько операций. Крайне редко используемый в реальной жизни параметр. Может сигнализировать, что приложением запрашиваются слишком большие блоки данных, которые не могут быть переданы за одну операцию. Для нагруженных дисков HDD с малыми показателями — % Free Space и % Idle Time может говорить о высоким уровне фрагментации диска.

Все перечисленные выше параметры, их рабочие диапазоны, возможные причины выхода за их пределы и рекомендации по их возврату в штатные рамки сведены в одну таблицу. Хотя универсальных советов по интерпретации реальных замеров быть не может, один общий вывод все-таки есть: «информирован — значит вооружен».

 

Счётчик (counter)

Толкование

Нормальный диапазон

Причины выхода за него

Рецепты

Avg. Disk sec/Transfer

Среднее время обращения к диску (сек)

Avg. Disk sec/Read

Среднее время чтения с диска (сек)

Avg. Disk sec/Write

Среднее время обращения к диску на запись (сек)

 

Physical Disk / Logical Disk

Среднее время в секундах, требуемое для одной операции обмена данными с диском.

 

Среднее время в секундах, требуемое для чтения данных с диска.

 

Среднее время в секундах, требуемое для записи данных на диск.

< 0.25 секунды для файловых серверов

< 0.10 секунды для SQL Server, Exchange Server, VM/VDI.

Большое значение говорит о перегрузке дисковой подсистемы. Возможно, контроллер повторяет попытки обращения к неисправному диску.

 

Увеличить количество дисков в массиве.

Заменить на боле
е быстрые HDD или SSD.

Применить технологии кеширования.

Заменить диск.

Current Disk Queue Length

Текущая длина очереди диска

 

Physical Disk / Logical Disk

Число невыполненных и ожидающих обработки запросов, адресованных выбранному диску. Текущее значение, моментальный показатель, не является средним значением по интервалу времени.

В установившемся режиме количество ожидающих запросов не должно превышать количество физических дисков в массиве более чем в 1.5-2 раза.

Допустимы моментальные пики.

 

При перегрузках дисковой подсистемы значение счетчика будет постоянно большим.

Увеличить количество дисков в массиве.

Заменить на боле
е быстрые HDD или SSD.

Перенести часть данных на другие диски.

% Disk Time

% активности диска

 

% Disk Read Time

% активности диска при чтении

 

% Disk Write Time

% активности диска при записи

 

Physical Disk / Logical Disk

Процент времени, затраченного дисковым устройством на обработку запросов.

Процент времени на обработку запросов чтения.

 

Процент времени на обработку запросов записи.

 

Данные счетчика в массиве охватывают больше чем один физический диск, и могут превышать 100%.

Необходимо анализировать вместе с параметром % Idle Time.

до 80 - 90%

Постоянные высокие нагрузки.

Разместить  данные на различных массивах по типу нагрузки (например, таблицы БД и лог-файлы).

Увеличить количество дисков в массиве.

Заменить на боле
е быстрые HDD или SSD.

% Idle Time

% времени бездействия

 

Physical Disk

Время бездействия диска между измерениями.

Анализировать совместно с параметром  % Disk Time

Не менее 20%

Постоянные высокие нагрузки.

Разместить  данные на различных массивах по типу нагрузки (например, таблицы БД и лог-файлы).

Увеличить количество дисков в массиве.

Заменить на боле
е быстрые HDD или SSD.

Avg. Disk Queue Length

Средняя длина очереди диска

 

Avg. Disk Read Queue Length

Средняя длина очереди к диску на чтение

 

Avg. Disk Write Queue Length

Средняя длина очереди к диску на запись

 

Physical Disk / Logical Disk

 

Среднее количество незавершенных операций ввода/вывода в очереди к диску.

 

Среднее количество запросов чтения в очереди к диску.

 

Среднее количество запросов на запись в очереди к диску.

 

Это производное значение, а не прямое измерение, равно (Disk Transfers/sec) *(Disk sec/Transfer)

Рекомендуемое для многопоточных ресурсоёмких (SQL Server, Exchange Server, VM/VDI, 1С) не более 0,2.

Допустимое =  количество дисков в массиве + 1.

Большое значение говорит о перегрузке дисковой подсистемы.

Увеличить количество дисков в массиве.

Заменить на боле
е быстрые HDD или SSD.

Disk Transfers/sec

Обращений к диску/сек

 

 

Disk Reads/sec

Обращений чтения с диска/сек

 

Disk Writes/sec

Обращений записи на диск/сек

 

 

 

Physical Disk / Logical Disk

 

Количество отдельных дисковых запросов ввода-вывода, завершённых в течение одной секунды.

Частота выполнения операций чтения с диска.

 

 

Частота выполнения операций записи на диск.

Равняются произведению показателей одного диска на их количество. Для различных типов RAID на чтение могут учитываться не все диски.  

Для записи полученная сумма  делится на штраф на запись: 1 (RAID 0), 2 (RAID 1, 10), 4 (RAID5), 6 (RAID 6).

Disk Transfers/sec
для
RAID 10 (штраф на запись  2):
- до 80 IOPS на каждый SATA или NL SAS диск;
- до 160
IOPS на каждый SAS диск;
- до 1800
IOPS на каждый десктопный SSD
- до 5000
IOPS  на каждый серверный SSD.

Disk Reads/sec для RAID 10:
- 100
IOPS на каждый SATA или NL SAS диск;
220
IOPS на каждый SAS диск;
- до 30
 000 IOPS на SSD;
 -
Intel SSD 910 series 400GB – 90 000 IOPS.

Disk Writes/sec для RAID 10 (штраф на запись  2):
- 40
IOPS на каждый SATA или NL SAS диск;
80
IOPS на каждый SAS диск;
- до 150-300
IOPS на десктопный SSD;
- до 1100 - 2400
IOPS на серверный SSD;
 -
Intel SSD 910 series 400GB – 38 000 IOPS.

Постоянные высокие нагрузки случайного чтения и/или случайной записи.

Увеличить количество дисков в массиве.

Заменить на боле
е быстрые HDD или SSD.

Перейти на массив из SSD.

Применить технологии кеширования на
SSD.

Перейти на PCIe SSD.

 

Disk Bytes/sec

Скорость обмена с диском (байт/сек)

 

 

Disk Read Bytes/sec

Скорость чтения с диска (байт/сек)

 

Disk Write Bytes/sec

Скорость записи на диск (байт/сек)

 

Physical Disk / Logical Disk

Пропускная способность дисковой системы (скорость обмена данными с диском) при выполнении операций чтения и записи.

Скорость передачи данных с диска при выполнении операций чтения.

 

 

Скорость передачи данных на диск при выполнении операций записи.

Сильно зависит от спецификаций на конкретный диск.


SATA 2, SAS 1.0:
- до  300
MB/s на каждый SATANL, SAS, SAS, SSD диск на последовательных операциях.

SATA 3, SAS 2.0:
- до  600
MB/s на каждый SATANL, SAS, SAS, SSD диск на последовательных операциях.

PCIe SSD: Intel SSD 910 series 400GB
 - до 1000
MB/s на чтение,
- до 750
MB/s на запись.

Постоянные высокие нагрузки линейного чтения и/или линейной записи.

Увеличить количество дисков в массиве.

Avg. Disk Bytes/Transfer

Средний размер одного обмена с диском (байт)

 

Avg. Disk Bytes/Read

Средний размер одного чтения с диска (байт)

 

Avg. Disk Bytes/Write

Средний размер одной записи на диск (байт)

Physical Disk / Logical Disk

Среднее количество байт данных, переданных при выполнении операций чтения или записи.

 

Среднее количество байт данных, полученных с диска при выполнении операций чтения.

 

Среднее количество байт данных, переданных на диск при выполнении операций записи.

>20 Кбайт

Значение меньше 20 Кбайт будут в случае, если приложение использует диск неэффективно.

Большое количество слишком мелких запросов.

Оптимизировать приложения.

Выделить большой объем в оперативной памяти под кеш приложения.

Использовать режим отложенной записи RAID-контроллера.

Перейти на SSD.

% Free Space

% свободного места

Logical Disk

Доля свободного места на логическом диске, по отношению к его общему объему.

15%

Постепенное исчерпание свободного пространства.

Заменить диск на более емкий.
Добавить диски в
RAID-массив.

Free Megabytes

Свободно мегабайт

Logical Disk

Объем незанятого пространства на логическом диске в мегабайтах.

 

 

 

Split IO/sec

Расщепления ввода/вывода/сек

Physical Disk / Logical Disk

Частота, с которой операции ввода-вывода диска расщепляются на несколько операций ввода-вывода.

Запрашиваются слишком большие блоки данных, которые не могут быть переданы за одну операцию.

Высокий уровень фрагментации диска.

 

Проанализировать приложения, работающие с данными.

Дефрагментировать диски.

Таблицу можно загрузить отдельным файлом doc и pdf.

+1111
голосов

Напечатать Отправить другу

Читайте также

Юрий, а можешь выложить табличку не в HTML виде? Сложно ее читать?

Могу.
Куда и в каком формате?
У меня она в MS Word в альбомной ориентации нормально читается.
Здесь ширина колонок ограничена форматированием сайта.
А картинка - получается слишком длинная и с очень мелким шрифтом.

На какой-то файловик забрось исходник. типа ex.ua

Сейчас сделаем линк прямо с сайта на экселовский файл.

Спасибо!

Отличная статья, спасибо! Узнал много нового.

кто понимает неизбежное - тот не дёргается понапрасну...

> Сергей Матяр
> Теперь когда с процессорами все разобрались, пришла очередь дисков :)

Где-то похоже:-).
Правда, более точно было бы сказать, что процессоры "разобрались" с задачами до такой степени, что в 9 из 10 случаев перестали быть узким местом.
А вот вариативность дисковой подсистемы с появлением SSD, да еще и в куче разных форматов - резко возросла. А значит, появились новые возможности оптимизации по соотношению цена/производительность под конкретный класс задач.

Мой клиент прочитал Вашу статью и теперь хочет, чтобы я подобрал ему сервер так: я говорю ему сколько иопсов должно быть у сервера, а он самостоятельно идет на рынок и выбирает самостоятельно, главное чтобы иопсов столько получилось. Ваша позиция? Считаете что 2 SSD эквиваленты 24 HDD, если количество иопсов одинаковое?

Добрый день, Вячеслав.

1. Относительно позиции клиента "главное чтобы иопсов столько получилось" - она с технической точки зрения некорректна.
Потому как не только на IOPS завязана реальная производительность дисковой подсистемы.
Производительность сервера - это комплексная характеристика, и исходить только из производительности дисковой подсистемы в IOPS - крайне опрометчиво.
Как пример - загрузка в 1С 8 больших объемов данных от удаленных подразделений (БД). Здесь идет и распаковка файла обмена (диск), и работа с tempDB (диск), и разбор xml-данных (процессора), создание транзакции по куче объектов (память, процессор, дисковая). В данной задаче может быть великолепная дисковая подсистема, а производительность будет упираться в всего 1 ядро процессора. Либо же загрузка резко может замедлится (а то и сорваться запись транзакции) при недостаточном объеме оперативной памяти.

2. Относительно "самостоятельно идет на рынок".
Это право любого Заказчика, т.к. деньги - его.
При этом ответственность за принятое решение и последствия в полной мере переходит к самому Заказчику.
Такая позиция чрезвычайно опасна именно для заказчика, т.к. не будучи профессионалом в узкой области, он наверняка не учтет огромное количество нюансов.
На мой взгляд, это очень подобно ситуации, когда при угрозе жизни и здоровью со стороны 3-х лиц спросить у профессионального телохранителя, как что необходимо сделать для обеспечения безопасности, взять одну из рекомендаций, проигнорировав как остальные рекомендации, так и предложение профессиональной помощи. А затем удивляться, почему таки "встретили" в темном уголке, почему следующий месяц нужно провести на больничной койке, и сетовать на непрофессионализм телохранителей.

3. "Считаете что 2 SSD эквиваленты 24 HDD, если количество иопсов одинаковое?" - не совсем корректный вопрос без привязки к конкретной задаче, типу данных, с которыми работает задача, условий эксплуатации.
Если вернуться к тем же обменам, то на 2 шт. SSD Intel 710 200GB в "зеркале" на бортовом контроллере получалось порядка 1900 - 2100 IOPS на запись с текущей очередью до 4-х. При этом БД - порядка 70GB.
Для такого же количества IOPS на HDD мне понадобилось бы как раз ваши 24 HDD SAS 15000 prm в RAID 10.
Дальше оцениваем "цену вопроса" - по стоимости оборудования (здесь нам нужен и хороший RAID-контроллер, и корпус с корзинами для дисков, и избыточный БП), занимаемому месту, потреблению электроэнергии (помним, что на отвод 1 кВт нужно потратить еще 1,4 кВт на систему охлаждения), и "обвязки" (стоимости подвода энергоснабдежиня, UPS и т.д.).
В случае же, если мне необходимо было бы работать с видеоданными в высоком разрешении - я бы предпочел 24 HDD SATA 7200 prm, т.к. при вдвое меньшем количестве IOPS (которые мне не нужны) они обеспечат существенно большую производительность в линейном чтении в MBps и больше емкость.
Поэтому ответ на вопрос:
а) В общем случае 2 SSD не эквиваленты 24 HDD;
б) В задачах, требовательных к IOPS, при этом не требовательных к MBps и объему хранения - современные северные SSD превосходят 24 HDD.
Как пример - Intel SSD 3700 series
https://www-ssl.intel.com/content/dam/www/public/us/en/documents/product....

И еще раз подчеркну основною идею:
- Важна комплексная производительность сервера, его сбалансированность в соответствии с поставленными перед ним конкретными задачами, а не какой-то один показатель.

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

P.S.: Возможно, я чего-то не понимаю.
На мой взгляд, промониторить дисковую подсистему на IOPS с помощью PerfMon - не самая сложная теологическая задача, к которой даже есть пошаговые инструкции.
Подбор "железа", тем более конфигурирование ПО - куда более сложная.
Если конечный заказчик не может / не хочет самостоятельно промониторить дисковую нагрузку, как он собирается выбирать, и тем более настраивать сервер?

благодарю за ответ, эйфория у моего заказчика закончилась :)

Юрий, для показателя Avg. Disk sec/Transfer вы используете значения 0.25 секунды, 0.1 секунды. При этом в статьях Microsoft для подобных параметров используются милисекунды и все приводимые значения получаются не больше 0.05 сек. Например 0.05, 0.02 для Logical Disk\Avg. Disk sec/Read (http://technet.microsoft.com/en-us/library/aa995945%28v=exchg.80%29.aspx)

Вы имели ввиду именно эти значения (0.25 сек, 0.1 сек) ?

Алексей, спасибо - в тексте действительно ошибка, "пропущен нолик".
Попробую исправить.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT