IOMeter - С какими значениями я должен протестировать?
Если у Вас есть набор, доступный, я всегда загружаю и тестирую на другой машине сначала. Для наших живых размещенных серверов мы тестируем на локальном VMs их - не идеальный тест, но мы можем, по крайней мере, исключить большинство проблем, которые обновление вызвало бы с нашим программным обеспечением, прежде чем мы обновим живой.
Если Вы не можете протестировать - по крайней мере, делают установку ручным процессом, таким образом, Вы управляете тем, что установлено и когда - можно искать KBS для проверки то, что будет затронуто и подготовлено вместо того, чтобы реагировать на проблему.
Действие Exchange и SQL склоняется к частому, меньшему концу IO/Ops масштаба. Exchange имеет довольно много больших пакетов ввода-вывода, поскольку пишутся/вытягиваются вложения. Резервные интервалы и длительные запросы могут действительно играть конфорку также и являются, вероятно, Вашим пиком экземпляры ввода-вывода. Exchange Дефрагментацией Онлайн является наш IO-пик для Exchange и Резервные копии SQL, является нашим пиком ввода-вывода для нашего SQL-сервера.
Exchange Дефрагментация Онлайн включает много операции в секунду ввода-вывода, но не много пропускной способности так средний размер передачи, является маленьким, 512b маленький, и многие из них. Отношение чтения-записи варьируется чрезвычайно, но для хорошо сохраняемого Exchange DB это должны быть главным образом чтения. Это будет значительно случайно, но с достаточным последовательным доступом для хранения этого интересным (не у меня нет точных отношений).
Резервные копии SQL включают множество размеров, но в отличие от дефрагментации онлайн пропускная способность на самом деле высока также. Запланируйте соединение 512b к размерам передачи 4 КБ. Отношения чтения-записи зависят от того, где данные заканчиваются! Записи могут быть сверхвысокой скоростью, но (в зависимости от резервного сценария) почти совершенно последовательный. Чтения будут случайными 100%.
Общее действие VM зависит от того, что находится в VMs. Если Вы имеете Exchange или SQL там, то контролируете для этого. Если генералом Вы имеете в виду "общее обслуживание файлов", такое как сеть или CIFS, совместно использующий, ну, в общем, который зависит от того, что они делают; у инженеров CAD есть совсем другие схемы доступа, чем офис, полный клерков Закупочной конторы. Нет никакого универсального шаблона ввода-вывода для 'общего действия VM'. Необходимо запланировать то, что Вы на самом деле имеете в VM.
Анализ производительности систем хранения с Iometer: http://communities.vmware.com/docs/DOC-3961
С точки зрения SQL-сервера
На блоке SQL-сервера предпочтительно тестировать диски со следующими параметрами, в зависимости от того, где вы будете хранить файлы MDF, NDF, LDF и TEMPDB:
Все диски (MDF, NDF, LDF, TEMPDB)
- 8 Размер запроса на передачу KiB
- 80% Соотношение чтения
- 95% Случайное чтение
- Время нарастания 10 (чтобы обойти кэш хранения)
- Максимальный размер диска (4'000'000 секторов = 2 Гигабайта)
Диски, записанные последовательно (LDF, TEMPDB)
- 8 Размер запроса на передачу KiB
- 20% Скорость чтения (Журналы и TEMPDB интенсивно записываются)
- 0% Случайное чтение
- Ramp Up Time 10 (чтобы обойти кэш хранения)
- Максимальный размер диска (4'000'000 секторов = 2 Гигабайта)
Последовательное чтение диска (MDF, NDF)
64 Расширение KiB Чтение
- 64 Размер запроса на передачу KiB
- 80% Скорость чтения (MDF и LDF файлы в основном читаются из)
- 0% Случайное чтение
- Ramp Up Time 10 (чтобы обойти кэш хранения)
- Максимальный размер диска (4'000'000 секторов = 2 Гигабайта)
128 KiB Чтение... Впереди
- 128 Запрос на передачу KiB Размер
- 80% Чтение Соотношения (MDF и LDF файлы в основном читаются из)
- 0% Случайное чтение
- Ramp Up Time 10 (чтобы обойти кэш хранения)
- Максимальный размер диска (4'000'000 секторов = 2 Гигабайта)
256 KiB Чтение... Впереди
- 256 КиБ запрос на передачу Размер
- 80% Чтение Соотношение (MDF и LDF файлы в основном читаются от)
- 0% Случайное чтение
- Ramp Up Time 10 (чтобы обойти кэш хранения)
- Максимальный размер диска (4'000'000 секторов = 2 гигабайта)
512 КиБ Чтение... Ahead
- 512 Размер запроса на передачу KiB
- 80% Чтение Соотношение (MDF и LDF файлы в основном читаются из)
- 0% Случайное чтение
- Ramp Up Time 10 (чтобы обойти кэш хранения)
- Максимальный размер диска (4'000'000 секторов = 2 гигабайта)
1024 KiB Чтение... Ahead (Enterprise Edition)
- 1024 Размер запроса на передачу KiB
- 80% Соотношение чтения (MDF и LDF файлы в основном читаются с)
- 0% Случайное чтение
- Ramp Up Time 10 (для обхода кэша хранилища)
- Максимальный размер диска (4'000'000 секторов = 2 Гб)
Вы можете варьировать процент случайного чтения, чтобы увидеть, если ваши результаты меняются, но я нашел вышеприведенные значения довольно хорошей отправной точкой.
SQL Server Best Practices Article (MSDN)
Test a combination of I/O sizes for read/write and sequential/random (Тестирование комбинации размеров входов/выходов для чтения/записи и последовательного/случайного чтения). При установке, ориентированной на SQL, не забудьте указать размер ввода/вывода 8 КБ, 64 КБ, 128 КБ, 256 КБ и 1024 для последовательного ввода/вывода. (Объем считывания может быть до 1024 КБ при работе SQL Server Enterprise Edition). Для случайных входов/выходов, как правило, безопасно сосредоточиться только на 8 КБ ввода/вывода.
Устранение неполадок медленного дискового ввода/вывода в SQL Server (Blogs MSDN)
Если вы подозреваете, что испытываете проблемы с производительностью диска, вы можете использовать внутренние DMV в сочетании с коллекцией Performance Monitor, чтобы получить хорошее представление о состоянии дисковой подсистемы ввода/вывода, а также о любой задержке, которую испытывает SQL Server из-за ее плохой производительности.
SQL Server Perfmon (Performance Monitor) Best Practices (Brent Ozar)
В раскрывающемся списке объектов Performance выберите пункт Physical Disk (Физический диск) и счетчик "% Disk Time" (Время диска). Обратите внимание, что снова в правом окне мы получаем несколько экземпляров; на этот раз мы получаем по одному на физический диск. С точки зрения производительности, физический диск означает один диск, показанный в инструменте управления дисками Computer Management's Disk Management tool (Управление компьютером). Один физический диск может иметь несколько разделов, каждый из которых имеет свою собственную букву диска, но для настройки производительности мы хотим знать, как тяжело работает один физический диск.
Этот один "физический диск" может иметь кучу реальных физических дисков, как в системах RAID. Однако, Windows не достаточно умна, чтобы точно знать, сколько дисков находится в RAID-массиве, поэтому термин "физический диск" здесь немного вводит в заблуждение.
Как исследовать задержки подсистемы ввода-вывода изнутри SQL Server (SQLSkills)
Большинство SQL-серверов сегодня связаны вводом-выводом - это общепринятое утверждение DBA и консультантов в этой области. Это означает, что основным фактором производительности сервера является его способность быстро выполнять операции ввода/вывода. Если подсистема ввода/вывода не может соответствовать предъявляемым к ней требованиям, то нагрузка на SQL-сервер будет страдать от проблем с производительностью
Теперь, говоря о том, что одна из ловушек, в которую попадает много людей, приравнивает увеличенные задержки подсистемы ввода/вывода к плохой производительности подсистемы ввода/вывода. Часто это совсем не так. Обычно так и происходит, когда подсистема ввода/вывода работает нормально, но становится узким местом в производительности, когда нагрузка на ввод/вывод увеличивается мимо точки проектирования подсистемы ввода/вывода. Увеличение нагрузки на ввод/вывод - это то, что вызывает проблему, а не подсистема ввода/вывода - если вы проектируете подсистему ввода/вывода для поддержки 1000 операций ввода/вывода (IOPS) (Операции ввода/вывода в секунду - и убедившись, что вы используете правильный размер ввода/вывода и характеристики нагрузки имеют смысл быть определены с точки зрения количества случайных IOPS) и SQL Server пытается подтолкнуть 2000 IOPS, производительность будет страдать.