Главная 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. Ну, как видно из графика, приведенного в blog.aboutnetapp.ru/archives/442

    многое в определении IOPS дисков зависит от принятого responce time.

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

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

    ::

    ::

    set «counter=\\DB5\PhysicalDisk (_Total)\Avg. Disk Queue Length»

    ::set «counter=\\DB5\PhysicalDisk (_Total)\Disk Writes/sec»

    ::set «counter=\\DB5\PhysicalDisk (_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 Files\Log Parser 2.2\LogParser.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 Files\Log Parser 2.2\LogParser.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 Files\Log Parser 2.2\LogParser.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, сильно рекомендую наиболее свежую статью на этут тему у меня в блоге:

    blog.aboutnetapp.ru/archives/1204

    Еще полезно почитать:

    habrahabr.ru/post/154235/

Опубликовать

Я не робот.