Назад | Перейти на главную страницу

IOMeter - С какими значениями мне следует тестировать?

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

У меня есть SAN для оценки, HP P4000. Я хотел бы использовать IOMeter, чтобы провести сравнительный анализ, чтобы увидеть, на что он способен.

Однако я понятия не имею, какая комбинация размера блока, разделения чтения / записи и случайного / последовательного разделения применима к различным применениям.

Например, как бы вы имитировали некоторую активность Exchange, некоторую активность SQL, некоторую общую активность виртуальных машин и т. Д.

Я знаю, как добавить рабочих и освободить их с различными настройками, но какие настройки мне следует использовать?

Спасибо.

С точки зрения SQL Server

На сервере SQL Server желательно протестировать диски со следующими параметрами, в зависимости от того, где вы будете хранить файлы MDF, NDF, LDF и TEMPDB:

Все диски (MDF, NDF, LDF, TEMPDB)

  • Размер запроса на передачу 8 КБ
  • Коэффициент чтения 80%
  • 95% случайных чтений
  • Время наращивания 10 (для обхода кеширования хранилища)
  • Максимальный размер диска (4 000 000 секторов = 2 ГиБ)

Последовательно записанные диски (LDF, TEMPDB)

  • Размер запроса на передачу 8 КБ
  • Коэффициент чтения 20% (журналы и TEMPDB интенсивно записываются)
  • 0% случайных чтений
  • Время наращивания 10 (для обхода кеша хранилища)
  • Максимальный размер диска (4 000 000 секторов = 2 ГиБ)

Последовательно читаемый диск (MDF, NDF)

64 КБайт чтения

  • Размер запроса на передачу 64 КБ
  • Коэффициент чтения 80% (в основном читаются файлы MDF и LDF)
  • 0% случайных чтений
  • Время наращивания 10 (для обхода кеша хранилища)
  • Максимальный размер диска (4 000 000 секторов = 2 ГиБ)

128 КБайт с опережением чтения

  • 128 КБ Размер запроса на передачу
  • Коэффициент чтения 80% (в основном читаются файлы MDF и LDF)
  • 0% случайных чтений
  • Время наращивания 10 (для обхода кеша хранилища)
  • Максимальный размер диска (4 000 000 секторов = 2 ГиБ)

256 КБайт с опережением чтения

  • Размер запроса на передачу 256 КБ
  • Коэффициент чтения 80% (файлы MDF и LDF в основном читаются)
  • 0% случайных чтений
  • Время наращивания 10 (для обхода кеша хранилища)
  • Максимальный размер диска (4 000 000 секторов = 2 ГиБ)

512 КБ с упреждающим чтением

  • Размер запроса на передачу 512 КБ
  • Коэффициент чтения 80% (в основном читаются файлы MDF и LDF)
  • 0% случайных чтений
  • Время наращивания 10 (для обхода кеширования хранилища)
  • Максимальный размер диска (4 000 000 секторов = 2 ГиБ)

1024 КБ с упреждающим чтением (Enterprise Edition)

  • Размер запроса на передачу 1024 КБ
  • Коэффициент чтения 80% (в основном читаются файлы MDF и LDF)
  • 0% случайных чтений
  • Время наращивания 10 (для обхода кеша хранилища)
  • Максимальный размер диска (4 000 000 секторов = 2 ГиБ)

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

Статья о передовых методах работы с SQL Server (MSDN)

Протестируйте комбинацию размеров ввода / вывода для чтения / записи и последовательного / случайного. Для развертываний, ориентированных на SQL, обязательно укажите размеры ввода-вывода 8 КБ, 64 КБ, 128 КБ, 256 КБ и 1024 для последовательного ввода-вывода. (Размер упреждающего чтения может составлять до 1024 КБ при запуске SQL Server Enterprise Edition). Для произвольного ввода-вывода обычно безопасно сосредоточиться только на вводе-выводе размером 8 КБ.

Устранение неполадок медленного дискового ввода-вывода в SQL Server (блоги MSDN)

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

Рекомендации по настройке SQL Server Perfmon (монитор производительности) (Брент Озар)

В раскрывающемся списке «Объект производительности» выберите «Физический диск» и выберите счетчик «% времени на диске». Обратите внимание, что снова в правом боковом окне мы получаем несколько экземпляров; на этот раз мы получаем по одному на физический диск. С точки зрения производительности, физический диск означает один диск, показанный в инструменте управления дисками Computer Management. Один физический диск может иметь несколько разделов, каждый со своей буквой диска, но для настройки производительности мы хотим знать, насколько усердно работает этот физический диск.

Этот один «физический диск» может иметь несколько реальных физических дисков, как в системах RAID. Однако Windows недостаточно умен, чтобы точно знать, сколько дисков в массиве RAID, поэтому термин «физический диск» здесь немного вводит в заблуждение.

Как исследовать задержки подсистемы ввода-вывода из SQL Server (SQLSkills)

Большинство современных SQL-серверов связаны с вводом-выводом - это общепринятое утверждение администраторов баз данных и консультантов в этой области. Это означает, что основным фактором производительности сервера является его способность быстро выполнять операции ввода-вывода. Если подсистема ввода-вывода не справляется с возлагаемыми на нее требованиями, рабочая нагрузка SQL Server будет испытывать проблемы с производительностью.

Теперь, говоря это, одна ловушка, в которую попадают многие люди, приравнивает увеличенные задержки подсистемы ввода-вывода к низкой производительности подсистемы ввода-вывода. Часто это совсем не так. Обычно подсистема ввода-вывода работает нормально, когда возникает запланированная рабочая нагрузка ввода-вывода, но становится узким местом производительности, когда рабочая нагрузка ввода-вывода увеличивается за пределы проектной точки подсистемы ввода-вывода. Причиной проблемы является увеличение нагрузки ввода-вывода, а не подсистема ввода-вывода - если вы проектируете подсистему ввода-вывода для поддержки 1000 операций ввода-вывода в секунду (операций ввода-вывода в секунду) и убедитесь, что вы используете правильный ввод-вывод. Размер O и характеристики рабочей нагрузки имеет смысл определять в терминах числа случайных операций ввода-вывода в секунду), а SQL Server пытается повысить производительность до 2000 операций ввода-вывода в секунду, поэтому пострадает производительность.

Анализ производительности системы хранения с помощью Iometer: http://communities.vmware.com/docs/DOC-3961

Активность Exchange и SQL имеет тенденцию к частому и меньшему количеству операций ввода-вывода в конце шкалы. Exchange имеет несколько больших пакетов ввода-вывода, поскольку вложения записываются / извлекаются. Интервалы резервного копирования и длительные запросы тоже могут сыграть роль, и, вероятно, являются вашими пиковыми экземплярами ввода-вывода. Exchange Online Defrag - это пик ввода-вывода для Exchange, а резервное копирование SQL - это пик ввода-вывода для нашего SQL-сервера.

Exchange Online Defrag включает в себя множество операций ввода-вывода, но невысокую пропускную способность, поэтому средний размер передачи небольшой, 512 байт, а их много. Соотношение чтения / записи сильно различается, но для хорошо обслуживаемой базы данных Exchange это в основном чтение. Это будет в значительной степени случайным, но с достаточным последовательным доступом, чтобы было интересно (нет, у меня нет точных соотношений).

Резервные копии SQL могут иметь разные размеры, но, в отличие от интерактивной дефрагментации, пропускная способность также высока. Запланируйте сочетание размеров передачи от 512 до 4 КБ. Соотношение чтения / записи зависит от того, где заканчиваются данные! Запись может быть очень быстрой, но (в зависимости от сценария резервного копирования) почти полностью последовательной. Чтения будут на 100% случайными.

Общая активность ВМ зависит от того, что находится на ВМ. Если у вас есть Exchange или SQL, следите за этим. Если под общим вы имеете в виду «общее обслуживание файлов», такое как совместное использование Интернета или CIFS, ну, это зависит от того, что они делают; У инженеров САПР совсем другие схемы доступа, чем в офисе, полном клерков из отдела закупок. Не существует универсального шаблона ввода-вывода для «общей активности ВМ». Вы должны спланировать, что на самом деле есть в виртуальной машине.