При диагностике проблем с производительностью с помощью программного обеспечения поставщика, работающего под управлением 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)
HDD (C: /): ОС + расположение временного файла
RAID 1
2x 36 ГБ SCSI-320 (15k об / мин)
HDD (D: /): Расположение файла БД
RAID 5
4x 73 ГБ SCSI-320 (15 тыс. Об / мин)
HDD (E: /): файл подкачки ОС + расположение файла журнала (зеркального журнала нет)
RAID 5
4x 73 ГБ SCSI-320 (15 тыс. Об / мин)
Примечания: RAID1 и первый RAID5 (D: /) находятся на одном контроллере RAID. Мы планировали обновить оба RAID5 с дисками 146 ГБ (15k RPM) в RAID10. Поможет ли это изменение решить нашу очевидную проблему с пропускной способностью ввода-вывода?
При работе с RAID традиционные счетчики Disk в perfmon могут дать неверные результаты. Они будут отображать ввод-вывод кеша, а не дисковый ввод-вывод. Убедитесь, что вы также смотрите на % Idle Time счетчик. Вероятно, это будет наиболее точный результат, но он будет инвертирован (более низкий процент соответствует более загруженным дискам)
Статистика CurrIO небезопасна для SMP в SA. Вам лучше взглянуть на счетчики "PhysicalDisk", предоставляемые Windows perfmon. В частности: «Текущая длина очереди диска», «Средняя длина очереди диска», «Средняя длина очереди записи на диск» и «Средняя длина очереди чтения с диска».
Не знаю, откуда взялось значение «3 + # дисков». Если вы ожидаете, что на диске будет выполнено много операций ввода-вывода, вполне разумно иметь несколько невыполненных операций ввода-вывода на этом диске.
Еще один способ узнать, сколько операций ввода-вывода выполняется базой данных, - это посмотреть статистику кеша. Если база данных читает из кеша, она не выполняет столько дискового ввода-вывода. Два свойства базы данных, которые можно просмотреть, это «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» могут быть неверными, относительное падение также было резким после этого изменения.