Диагностика пропускной способности ввода-вывода в SQL Anywhere
При диагностике проблем с производительностью программного обеспечения вендора, работающего на SQL Anywhere (9.0.2), я наткнулся на некоторые интересные данные, касающиеся пропускной способности ввода-вывода. Согласно руководству по 9.0.2, свойство базы данных "CurrIO" показывает "Текущее количество операций ввода-вывода файлов, которые были выпущены сервером, но еще не завершены". Однако неясно, каким должно быть это число, учитывая конфигурацию оборудования и / или использование базы данных.
После небольшого поиска я обнаружил, что руководство по SQL Anywhere 10.0.0 подробно описывает этот параметр в их главе о производительности:
Чтобы определить, является ли пропускная способность ввода-вывода ограничивающим фактором, проверьте статистику базы данных CurrIO. Если эта статистика отсутствует на графике, нажмите кнопку Добавить статистику и выберите CurrIO. Ищите наибольшее устойчивое число для этой статистики. Например, посмотрите на высокое плато на графике; чем оно шире, тем значительнее воздействие. Если график имеет постоянные значения, равные или превышающие 3 + числа физических дисков, используемых сервером базы данных, это может указывать на то, что дисковая система не может соответствовать уровню активности сервера базы данных.
Это говорит о том, что, например, если у меня есть 5 дисков на сервере, это число в идеале должно быть ниже 8? Значение этого значения для версии 9.0.2 такое же, как для 10.0.0? Причина, по которой мне трудно в это поверить, заключается в том, что результаты следующей команды немного отличаются в моем конкретном случае:
SELECT db_property ( 'CurrIO' ), db_property ( 'MaxIO' )
Приведенная выше команда возвращает более 900 для CurrIO и 1150 для MaxIO. Я наблюдаю за этим числом в течение нескольких часов, и среднее значение составляет приблизительно 950 (благодаря монитору Foxhound от RisingRoad). Эти показания были взяты при нормальной загрузке базы данных.
Действительно ли пропускная способность моего ввода / вывода настолько неадекватна, насколько это выглядит, или я неверно истолковываю эти цифры?
Вот текущая конфигурация сервера:
ОС: Windows Server 2003 R2 32-разрядная
Версия базы данных: SQL Anywhere (Adaptive Server Anywhere) 9.0.2.3381
Процессор: 4x Intel Xeon Dual Core 3,00 ГГц
Оперативная память: 26 ГБ (22 ГБ выделено для кэша SQL Anywhere)
Жесткий диск (C:/): OS + временное местоположение файла
RAID 1
2x 36 ГБ SCSI-320 (15 000 об / мин)
HDD (D: /): расположение файла БД
RAID 5
4x 73 ГБ SCSI-320 (15 000 об / мин)
Жесткий диск (E: /): файл подкачки ОС + расположение файла журнала (зеркальный журнал отсутствует)
RAID 5
4x 73 ГБ SCSI-320 (15 000 об / мин)
Примечания: RAID1 и первый RAID5 (D: /) находятся на одном контроллере RAID. Мы планировали обновить оба RAID5 с 146 ГБ (15k RPM) дисков в RAID10. Поможет ли это изменение нашей очевидной проблеме пропускной способности ввода / вывода?
3 ответа
При работе с RAID традиционные счетчики дисков в perfmon могут давать неверные результаты. Они будут показывать кэш-ввод, а не дисковый ввод-вывод. Поэтому убедитесь, что вы также посмотрите на % Idle Time счетчик. Это будет, вероятно, самый точный результат, но он будет инвертирован (более низкий процент равен занятым дискам)
Другой способ узнать, сколько операций ввода-вывода выполняется базой данных, - посмотреть статистику кеша. Если база данных читает из кеша, она не делает столько дискового ввода-вывода. Два свойства базы данных, которые можно просмотреть, это "CacheRead" и "CacheHits", например:
SELECT db_property ( 'CacheRead' ), db_property ( 'CacheHits' )
Руководство SQL Anywhere 10.0.0 рекомендует, как минимум, 70% -ный процент попаданий в кеш. Если он ниже, вам может потребоваться выделить больше кэша для сервера. Вы можете получить процент прямо так:
SELECT STRING(((db_property ( 'CacheHits' ) / db_property ( 'CacheRead' )) * 100), '%')
В моем конкретном случае, когда база данных имела кэш-память 22 ГБ, процент попаданий составлял около 58%. После установки кеша на 55 ГБ процент попаданий вырос до 97%. Хотя точные числа свойств "CurrIO" и "MaxIO" могут быть неправильными, относительное падение также было резким после этого изменения.
Статистика CurrIO не является безопасной для SMP в SA. Вам лучше взглянуть на счетчики "PhysicalDisk", предоставляемые Windows perfmon. В частности: "Текущая длина очереди диска", "Средняя длина очереди диска", "Средняя длина очереди записи на диск" и "Средняя длина очереди чтения с диска".
Я не уверен, откуда пришло значение "3+# диски". Если вы ожидаете, что на диске будет выполнено много операций ввода-вывода, очень разумно иметь на этом диске несколько выдающихся операций ввода-вывода.