IOMeter - с какими значениями я должен тестировать?
В некотором смысле, я предполагаю, что это частичный вопрос, однако даже если есть ответ "это подходит для большинства ситуаций", я понятия не имею, что это такое, так что...
У меня есть SAN на оценке, HP P4000. Я хотел бы использовать IOMeter, чтобы сделать несколько тестов, чтобы увидеть, на что он способен.
Однако я понятия не имею, какая комбинация размера блока, разделения чтения / записи и случайного / последовательного разделения применима к различным применениям.
Например, как бы вы имитировали некоторые действия Exchange, некоторые операции SQL, некоторые общие действия с виртуальными машинами и так далее.
Я знаю, как добавлять рабочих и освобождать их с другими настройками, но какие настройки я должен использовать?
Благодарю.
3 ответа
Деятельность Exchange и SQL имеет тенденцию к частому, меньшему концу шкалы ввода-вывода. Exchange имеет довольно много больших пакетов ввода / вывода при записи / извлечении вложений. Интервалы резервного копирования и длительные запросы также могут сыграть роль конфорки и, вероятно, являются вашими пиковыми экземплярами ввода-вывода. Exchange Online Defrag - наш пик ввода-вывода для Exchange, а резервные копии SQL - наш пик ввода-вывода для нашего SQL-сервера.
В Exchange Online Defrag задействовано много операций ввода-вывода, но не большая пропускная способность, поэтому средний объем передачи небольшой, 512 байт небольшой, и их много. Соотношение чтения / записи сильно варьируется, но для хорошо обслуживаемой базы данных Exchange она должна быть в основном для чтения. Это будет значительно случайным, но с достаточным последовательным доступом, чтобы сделать его интересным (нет, у меня нет точных соотношений).
Резервные копии SQL имеют различные размеры, но, в отличие от онлайн-дефрагментации, пропускная способность на самом деле также высока. Запланируйте сочетание размеров передачи от 512 до 4 КБ. Коэффициенты чтения / записи зависят от того, где заканчиваются данные! Запись может быть очень высокой, но (в зависимости от сценария резервного копирования) почти полностью последовательной. Чтения будут на 100% случайными.
Общая активность ВМ зависит от того, что находится в ВМ. Если у вас есть Exchange или SQL, следите за этим. Если под общим вы подразумеваете "общее обслуживание файлов", такое как обмен веб-файлами или CIFS, то это зависит от того, что они делают; Инженеры САПР имеют совершенно разные схемы доступа, чем офис, полный клерков в отделе закупок. Не существует универсального шаблона ввода / вывода для "общей активности ВМ". Вы должны планировать то, что у вас есть в ВМ.
Анализ производительности системы хранения данных с помощью Iometer: http://communities.vmware.com/docs/DOC-3961
С точки зрения 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 (Performance Monitor) (Брент Озар)
В раскрывающемся списке "Производительность" выберите "Физический диск" и выберите счетчик "% времени на диске". Обратите внимание, что снова в правом окне мы получаем несколько экземпляров; на этот раз мы получаем по одному на физический диск. С точки зрения производительности под физическим диском понимается один диск, показанный в средстве управления дисками в разделе "Управление компьютером". Один физический диск может иметь несколько разделов, каждый из которых имеет собственную букву диска, но для настройки производительности мы хотим знать, насколько тяжело работает этот физический диск.
Этот один "физический диск" может иметь несколько реальных физических дисков, как в системах RAID. Однако Windows не достаточно умна, чтобы точно знать, сколько дисков в RAID-массиве, поэтому термин "физический диск" здесь немного вводит в заблуждение.
Как проверить задержки подсистемы ввода-вывода изнутри SQL Server (SQLSkills)
На сегодняшний день большинство SQL Server связаны с вводом / выводом - это, как правило, согласованное заявление администраторов баз данных и консультантов на местах. Это означает, что основным фактором производительности сервера является его способность быстро выполнять операции ввода-вывода. Если подсистема ввода-вывода не может удовлетворить требования, предъявляемые к ней, то рабочая нагрузка SQL Server будет страдать от проблем с производительностью.
Теперь, говоря об этом, одна ловушка, в которую попадают многие люди, - это приравнивание увеличенных задержек подсистемы ввода-вывода к низкой производительности подсистемы ввода-вывода. Это часто совсем не так. Обычно бывает так, что подсистема ввода-вывода работает нормально, когда происходит рабочая нагрузка, предназначенная для ввода-вывода, но становится узким местом производительности, когда рабочая нагрузка ввода-вывода превышает точку проектирования подсистемы ввода-вывода. Причиной проблемы является увеличение рабочей нагрузки ввода-вывода, а не подсистема ввода-вывода - если вы разрабатываете подсистему ввода-вывода для поддержки 1000 операций ввода-вывода (операций ввода-вывода в секунду) и убедитесь, что используете правильный ввод-вывод Размер O и характеристики рабочей нагрузки имеют смысл быть определены с точки зрения количества случайных операций ввода-вывода в секунду), а SQL Server пытается увеличить 2000 операций ввода-вывода в секунду, производительность будет снижаться.