Измерение IOPS дисковой подсистемы с помощью PowerShell | Windows для системных администраторов

Измерение IOPS дисковой подсистемы с помощью PowerShell

Одной из основных метрик, позволяющих оценить производительность существующей или проектируемой системы хранения данных некого сервиса является IOPS (Input/Output Operations Per Second) количество операций ввода/вывода. Говоря простым языком, IOPS – этой количество блоков, которое успевает считаться или записаться на носитель или файловую систему в единицу времени. Чем это число больше – тем больше производительность данной дисковой подсистемы (откровенно говоря, само по себе значение IOPS стоит рассматривать в комплексе с другими характеристиками СХД, таким как средняя задержка, пропускная способность и т.п.).

Довольно грубо оценить уровень производительности дисковой подсистемы можно с помощью счетчиков производительности из Performance Monitor (счетчики Disk Reads/sec, Disk Writes/sec, Current Disk Queue Length).

Мне понадобилось иметь под рукой более наглядный и удобный инструмент на PowerShell, позволяющий быстро измерить текущую производительность в IOPS используемой системы хранения данных, будь то локальный жесткий,  твердотельный (SSD) диск, сетевая папка (SMB), CSV том или LUN-а на сетевом хранилище данных (SAN).

На глаза попался PowerShell скрипт (автор Microsoft MVP, Mikael Nystrom), являющийся по сути надстройкой над утилитой SQLIO.exe (набора тестов для расчета производительности файлового хранилища). И хотя в названии утилиты (прямо говоря, не самом удачном) присутствует SQL, наличие MSSQL совсем не обязательно, и ее можно использовать на любой Windows системе.

Примечание. В декабре 2015 года Microsoft объявила о прекращении поддержки утилиты и замене SQLIO на более универсальный инструмент — Diskspd, удалив файлы с дистрибутивом SQLIO со своего сайта. Поэтому, вам придется искать sqlio.exe самостоятельно, либо скачать с нашего сайта (находится в архиве со скриптом).

Итак, скачайте архив содержащий 2 файла: SQLIO.exe и DiskPerformance.ps1 (disk-perf-iops.ZIP — 73Кб) и распакуйте архив в произвольный каталог.

Скрипт DiskPerformance и утилита sqlio.exe

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

Пример запуска скрипта определения IOPS:

.\DiskPerformance.ps1 -TestFileName test.dat –TestFileSizeInGB 1 -TestFilepath C:\temp -TestMode Get-LargeIO -FastMode True -RemoveTestFile True -OutputFormat Out-GridView

Оценка диска в IOPS с помощью Powershell

Посмотрим на аргументы скрипта:

-TestFileName test.dat

Имя файла, создаваемого утилитой FSUTIL

–TestFileSizeInGB 1

Размер файла для тестов. Допустимые варианты 1,5,10,50,100,500,1000 Гб. Размер файла должен быть больше, чем размер кэша системы. Иначе будет измеряться IOPS для данных в кэше, а не на диске.

-TestFilepath C:\Temp

Здесь указывается диск, для которого будет выполняться расчет производительности и каталог на диске, в котором будет создаваться тестовый файл. Допустимо указать UNC путь к сетевой папке.

-TestMode Get-LargeIO

Есть два варианта измерения нагрузки, Get-SmallIO – измеряются IOPS, Get-LargeIO – измеряется скорость передачи данных. Разница между аргументами SmallIO и LargeIO, в размерах блоков при замере скорости 8 Кбайт и 512 Кбайт, и типе доступа Random или Sequential соответственно.

-FastMode True

В режиме Fastmode каждый тест выполняется 10 секунд, иначе 60 сек.

-RemoveTestFile True

Удалить тестовый файл по окончании

-OutputFormat Out-GridView

Возможен вывод результатов измерения в консоль PowerShell (Format-Table) или в отдельное окно графической таблицы (Out-Gridview)

Производительность диска в IOPS

В нашем случае дисковый массив (тестировалось виртуальный vmdk диск на VMFS хранилище, расположенном на дисковой полке HP MSA 2040 с доступом через SAN) показал среднее значение IOPS около 15000 и скорости передачи данных (пропускная способность) около 5 Гбит/сек.

В следующей таблице указаны примерные значения IOPS для различных типов дисков:

Тип IOPS
SSD(SLC) 6000
SSD(MLC) 1000
15K RPM 175-200
10K RPM 125-150
7.2K RPM 50-75

Удалось найти ряд рекомендаций по производительности в IOPS для распространенных сервисов:

  • Microsoft Exchange 2010 – с 5000 пользователей, каждый из которых получает 75 и отправляет 30 писем в день, потребует как минимум 3750 IOPS
  • Microsoft SQL 2008 Server – с 3500 SQL транзакциями в секунду (TPS)- 28000 IOPS
  • Обычный сервер приложений Windows на 10-100 пользователей — 10-40 IOPS
Еще записи по теме: PowerShell, Windows Server 2012 R2
Понравилась статья? Скажи спасибо и расскажи друзьям!
Назад:
Вперед:

Комментариев: 5

Оставить комментарий
  1. Roman | 12.02.2016

    Еще в прошлом году пробовал аналогичный скрипт под diskspd. Под рукой не осталось, но думаю легко гуглиться.

    Ответить
  2. Дмитрий | 25.02.2016

    Как-то криво замеры происходят. Как будто вся база в кэш влезает, хотя уже пробовал размер указывать 2х от объема оперативы плюс памяти контроллера. На Adaptec 5405 с 4мя SATA 7.2K дисками в Raid10 показал 800 IOPS при размере 1ГБ (кэш 4гб). При размере тестовой базы 5ГБ — 5000IOPS, а при 10ГБ уже около 20000. Хотя ожидал не больше 300-400.

    Ответить
    • itpro | 26.02.2016

      Хм, интересный эффект.
      Какая ОС и сколько памяти установлено на сервере, какие параметры файла подкачки?

      Ответить
      • Дмитрий | 26.02.2016

        Установлен на железо ESXi 6, замер производился в гостевой Windows 2012R2. Виртуальной машине выделено 4ГБ RAM, 2 ядра, адаптер контроллера Paravirtual, своп по выбору системы, текущее значение 1.7ГБ. На дисках write cache включен. Еще служба дедупликации данных работает. Может последняя дает эффект. Будет время, посмотрю на каких дисках активна и попробую директорию в исключения добавить.

        Ответить
        • unisol-ua | 24.05.2016

          Ничего удивительного, IOPS для дисков — это функция от близости расположения запрашиваемых данных на диске, если совсем забыть о кэшах — с ними ещё вероятность «оказалось в кэше» (ESX — точно ничего сам не накэшировал?).
          track-to-track seek — 2 мс, «full stroke» — 20мс. Хотим быстро — делаем рейд из разделов поменьше, радуемся быстрому перемещению головок… Хотим читать ещё быстрее — добавляем зеркал или подобные способы (ZFS raidz/raidz2/raidz3 — умеет нагружать с пользой все диски при чтении, а не просто проверять чексумы) Да, железные контроллеры «так» зачастую не могут, их ценность только в наличии батарейки. Хотим быстро писать — журналирование на ФС превращает процесс в линейную запись…

          Ответить
Полные правила комментирования на сайте winitpro.ru. Вопросы, не связанные с содержимым статьи или ее обсуждением удаляются.

Сказать Спасибо! можно на этой странице или (еще лучше) поделиться с друзями ссылкой на понравившуюся статью в любимой социальной сети(специально для этого на сайте присуствуют кнопки популярных соц. сетей).

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Я не робот( Обязательно отметьте)



MAXCACHE: 0.25MB/0.00172 sec