Главная Storages, Windows, Новое ИОПСы и как их измерить.
  • ИОПСы и как их измерить.

    db_status Зачастую камнем преткновения в анализе производительности системы хранения является замер текущей производительности дисковой подсистемы в IOPS. Без таких данных очень сложно, а порой и невозможно спроектировать адекватную систему хранения для имеющихся данных. Ошибка в оценке необходимого уровня производительности может напрямую исчисляться в тысячах долларов, ушедших в «молоко» при создании системы с «перелетом», и не меньших тысячах долларов потраченных на систему, не выполняющую своих задач в случае «недолета».

    Грубой оценкой, но, как правило, достаточной для оценки текущей производительности для базы данных или иной системы, будут показания штатного Performance Monitor (perfmon) из Windows Server.

    В запущенном perfmon к имеющимся по умолчанию счетчикам Pages/sec, Avg.Disk Queue и %Processor следует добавить из группы Physical Disk параметры Disk Reads/sec и Disk Writes/sec для нужного диска (в том случае если исследуемая активность принадлежит одному физическому диску, если же нет – те же параметры из группы Logical Disk). Таким диском может быть, например, диск, содержащий базу данных, почтовую базу или любую другую информацию, которую вы намерены перенести на внешнее хранилище. Обратите внимание, что по умолчанию выбирается общая активность всей дисковой подсистемы (_Total).
    Очевидно, что сумма значений по Disk Writes/sec и Disk Reads/sec будет приблизительно искомой величиной в IOPS.

    Если же мы хотим не просто посмотреть загрузку по IOPS, а провести продолжительный анализ, например для вывявления пиков загрузки и средней величины, то следует воспользоваться так называемыми «журналами счетиков» того же perfmon.
    В Performance Logs and Alerts выбрать «Журналы счетчиков» и создать новый журнал с типом данных, например, csv. Добавить в этот журнал уже знакомые нам объекты Disk Reads/sec и Disk Writes/sec и установить желаемый интервал сбора данных. Следует обратить внимание, что включение счетчиков диска немного, но все же снижает общую производительность дисковой подсистемы дополнительной нагрузкой, это имеет смысл учитывать в интерпретации итоговых значений. Кроме того, слишком малый интервал считывания данных хоть и даст более детальный отчет, но, возможно, излишне нагрузит систему и даст черезмерно объемный файл журнала. Считывания раз в 3-5 секунд будет вполне достаточно. Для больших длительностей замеров имеет смысл выбрать большие интервалы, вплоть до минуты. Позаботьтесь о том, чтобы файл отчета не переполнил отведенное ему место, оставьте систему со включенным журналом регистрации и через искомое время вы получите csv-файл, наполненный значениями загрузки вашей дисковой подсистемы. Путем импорта и обработки в Excel вы сможете извлечь желаемые данные, например, средние и пиковые значения загрузки, время пиковых загрузок.

    Полезными для анализа параметрами будут также значения следующих объектов:
    Disk Bytes Read/sec и Disk Bytes Write/sec – показывают скорость передачи данных с диска. Должны быть близки к величине Disk Reads/sec и Disk Writes/sec помноженных на размер блока файловой системы. Показывают скорость передачи данных с диска. Полезно будет также отметить характер доступа, соотношение операций чтения к записи.
    Avg.Disk Queue – показывает величину «очереди запросов» к диску. Значение длительно удерживающееся заметно выше 1,5..2*количество шпинделей дисков показывает перегруженную дисковую подсистему или дисковый контроллер, величина показывает количество запросов стоящих в очередь к диску и ожидающих его освобождения после выполнения предшествующих запросов.
    %Processor – постоянная загрузка выше 60%-80% показывает слабость имеющегося процессора для выполняемой задачи, либо наличие какой-то «паразитной» загрузки сервера посторонними задачами.
    Pages/sec – показывает количество считываний и записей «страниц» в памяти для того, чтобы добраться до нужной для проводящийся в данный момент операции. Резко отличающиеся величины при работе указывают на недостаток оперативной памяти, приводящей к постоянным операциям «paging»-а, переключения страниц, снижающего быстродействия. Величина должна быть близка к нулю в нормальном, непиковом состоянии.

    Большое количество специфичных для себя счетчиков добавляет в perfmon установка MS SQL и MS Exchange. Среди них можно обнаружить объекты, измерение которых может помочь детализировать данные по отдельным базам данных или по определенным операциям.
    Полное описание всех средств Performance Monitor в Windows Server далеко выходит за рамки этого обзора поэтому ограничимся вышеприведенным.
    Интересующихся можно отослать к следующим статьям:

    «Семь наиболее полезных счетчиков эффективности» (SQL.ru)
    «Счётчики производительности SQL Server и Windows»

    Romx

    http://blog.aboutnetapp.ru/

Комментарии

  1. Полезная статья.
    “количество шпинделей” – это количество жестких дисков?
    P.S. Я читал, что при нагрузке дисковой подсистемы полезно обращать внимание на счетчик Avg. Disk sec /Transfer. Если значение больше 50 миллисекунд, то дисковая подсистема не справляется с нагрузкой. 🙂

  2. “количество шпинделей” если я правильно понимаю это кол-во “блинов” в жестком диске. Если мне неизменяет память, то в большинстве винтов их от 2 до 3. И это легко понять по толщине винта.

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

  4. Небольшое дополнение к статье. Если на полученном журнале счетчиков в консоли Производительность щелкнуть правой кнопкой мыши и выбрать “сохранить параметры как” то полученные CSV файлы можно будет просматривать не в EXCEL, а в виде html через IE.
    Думаю что все как бы в курсе, но на всякий случай 😉

  5. Да, но часто полезны не столько raw data, сколько “аналитика” по ним разная, графики всякие и т.д.
    А это удобно как раз в Excel делать.

  6. >Avg.Disk Queue – показывает величину «очереди запросов» к диску. Значение длительно удерживающееся заметно выше 1,5…2*количество шпинделей дисков показывает перегруженную дисковую подсистему или дисковый контроллер, величина показывает количество запросов стоящих в очередь к диску и ожидающих его освобождения после выполнения предшествующих запросов.

    Данное утверждение верно только для дисковых массивов построенных средствами операционной системы (софтовый RAID-массив). В случае использования RAID-контроллера Avg.Disk Queue > 2 будет указывать на перегрузку дисковой и колличество дисков в самом массиве уже не играет никакой роли. Ибо такой массив выглядит для системы как один диск.

  7. Кстати, есть еще пара добавлений.
    1) Write IOPS < Read IOPS (видел в качестве примера Seagate SAS15k);
    2) Общался с Владимиром Стригиным, архитектором из системного интегратора. Попутно он является преподавателем курсов по HP SAN и СХД XP24k в Москве. Он предлагает брать на диск не более 120 IOPS.

  8. Ну, как видно из графика, приведенного в http://blog.aboutnetapp.ru/archives/442
    многое в определении IOPS дисков зависит от принятого responce time.
    И, таки да, особенно в многодисковых системах, в которых при оценке их быстродействия показатель IOPS одного диска умножается на сотни, было бы разумно занижать его величину, чтобы не получить, в результате переоценки быстродействия одного диска “завышенных ожиданий” для системы в целом.

  9. Написал такой скриптик для парсинга логов perfmon:

    ::
    ::
    set “counter=\DB5PhysicalDisk(_Total)Avg. Disk Queue Length”
    ::set “counter=\DB5PhysicalDisk(_Total)Disk Writes/sec”
    ::set “counter=\DB5PhysicalDisk(_Total)Disk Reads/sec”
    set “selectasfieldname=Highest Avg. Disk Queue Length”
    set inputfilename=SAN-Total_000001.csv
    set outputfilename=SAN-Total_report.csv
    ::
    “C:Program FilesLog Parser 2.2LogParser.exe” -i:CSV -o:CSV “SELECT TOP 20 TO_REAL(EXTRACT_PREFIX([%counter%],0,’.’)) AS [%selectasfieldname%] INTO %outputfilename% FROM %inputfilename% ORDER BY [%selectasfieldname%] DESC”
    ::
    ::
    set “selectasfieldname=Hits Avg. Disk Queue Length”
    echo %selectasfieldname% >>%outputfilename%
    ::
    “C:Program FilesLog Parser 2.2LogParser.exe” -i:CSV -o:CSV -fileMode:0 “SELECT TOP 20 TO_REAL(EXTRACT_PREFIX([%counter%],0,’.’)) AS [%selectasfieldname%], COUNT (*) AS Hits INTO %outputfilename% FROM %inputfilename% GROUP BY [%selectasfieldname%] ORDER BY [Hits] DESC”
    ::
    ::
    set “selectasfieldname=Average Avg. Disk Queue Length”
    echo %selectasfieldname% >>%outputfilename%
    ::
    “C:Program FilesLog Parser 2.2LogParser.exe” -i:CSV -o:CSV -fileMode:0 “SELECT EXTRACT_PREFIX(TO_STRING(AVG(TO_REAL(EXTRACT_PREFIX([%counter%],0,’.’)))),0,’.’) AS [%selectasfieldname%] INTO %outputfilename% FROM %inputfilename%”
    ::
    type %outputfilename%
    ::
    pause
    ::

    Результаты за двое суток таковы (для _Total):

    *Writes*

    Highest Disk Writes/sec
    2255.000000
    2217.000000
    1944.000000
    1883.000000
    1878.000000
    1732.000000
    1716.000000
    1646.000000
    1635.000000
    1595.000000
    1583.000000
    1533.000000
    1498.000000
    1457.000000
    1374.000000
    1365.000000
    1304.000000
    1290.000000
    1277.000000
    1206.000000
    Hits Disk Writes/sec
    146.000000,97
    153.000000,91
    133.000000,91
    127.000000,91
    140.000000,86
    131.000000,86
    138.000000,86
    132.000000,85
    142.000000,84
    130.000000,84
    167.000000,84
    175.000000,84
    143.000000,83
    145.000000,83
    162.000000,82
    135.000000,82
    125.000000,82
    139.000000,80
    169.000000,80
    147.000000,80
    Average Disk Writes/sec
    193

    *Reads*

    Highest Disk Reads/sec
    6679.000000
    6617.000000
    6592.000000
    6584.000000
    6576.000000
    6574.000000
    6428.000000
    6350.000000
    6345.000000
    6268.000000
    6144.000000
    6087.000000
    6002.000000
    5950.000000
    5843.000000
    5719.000000
    5719.000000
    5583.000000
    5422.000000
    5385.000000
    Hits Disk Reads/sec
    129.000000,70
    124.000000,70
    135.000000,68
    127.000000,67
    147.000000,66
    136.000000,65
    163.000000,64
    126.000000,64
    130.000000,64
    128.000000,61
    117.000000,61
    118.000000,61
    150.000000,60
    125.000000,59
    160.000000,59
    132.000000,59
    152.000000,59
    142.000000,58
    121.000000,58
    106.000000,58
    Average Disk Reads/sec
    479

    *Avg. Disk Queue Length*
    Highest Avg. Disk Queue Length
    1123.000000
    794.000000
    666.000000
    636.000000
    620.000000
    567.000000
    560.000000
    547.000000
    528.000000
    509.000000
    497.000000
    494.000000
    487.000000
    482.000000
    481.000000
    470.000000
    463.000000
    458.000000
    442.000000
    440.000000
    Hits Avg. Disk Queue Length
    0.000000,3283
    1.000000,1675
    2.000000,1187
    3.000000,872
    4.000000,597
    5.000000,456
    6.000000,345
    10.000000,292
    9.000000,282
    11.000000,268
    7.000000,261
    8.000000,232
    12.000000,224
    13.000000,143
    14.000000,116
    16.000000,95
    15.000000,84
    17.000000,82
    86.000000,70
    88.000000,63
    Average Avg. Disk Queue Length
    27

    Верно ли я понимаю что мои IOPS для DB5 = 479 + 193 = 672 ?

    TOP Reads:
    6679.000000
    6617.000000
    6592.000000
    6584.000000
    Это я так понимаю кеш помогает получить такие цифры, т.к. у нас RAID1-2SAS + RAID10-4SAS – 2.5x15K(MBC2073RC) ?

  10. Слава:

    Хотя пост уже порядочно старый, я, оказывается, все еще получаю на него уведомления 🙂

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

    А вообще, для разбирательства с IOPS, сильно рекомендую наиболее свежую статью на этут тему у меня в блоге:
    http://blog.aboutnetapp.ru/archives/1204
    Еще полезно почитать:
    http://habrahabr.ru/post/154235/