Microsoft SQL Server располагает системными объектами Dynamic Management Objects, которые предоставляют исчерпывающие метаданные, относящиеся к характеристикам производительности экземпляров SQL Server. В частности, использование одного из них, sys.dm_io_virtual_file_stats, позволяет специалисту в области данных оценить влияние ввода-вывода хранилища данных, структуры файлов и даже плохо спроектированных запросов и гиперактивных конечных пользователей. В предлагаемой статье мы рассмотрим, как определить самые высокие задержки чтения и записи данных и файлов журналов соответственно.

Вечные проблемы

В 2010 году я написал книгу о динамических объектах управления в соавторстве с Луисом Дэвидсоном, обладателем сертификата SQL Server MVP. Теперь, по прошествии нескольких лет, я еще выше ценю возможности, которые открывают эти конструкции как перед администраторами баз данных, так и перед разработчиками при идентификации проблем с производительностью. Данная статья стала результатом споров с аналитиком приложений относительно причин низкой производительности приложений, в которой обычно винят «медленное хранилище данных».

Когда я спросил, на чем основаны предположения моего оппонента, он упомянул как системный монитор, так и средство Performance Analysis of Logs (http://pal.codeplex.com/), более известное как PAL и доступное на сайте CodePlex. PAL — средство, которое читает журналы системного монитора и предоставляет отчеты о производительности на основе этих журналов. Оба инструмента предоставляются компанией Microsoft, и в основе их предупреждений лежат иные представления о порогах производительности ввода-вывода, нежели готова признать Microsoft, или мягкие стандарты «реального мира». PAL выдает предупреждение об операциях чтения длительностью более 20 миллисекунд (мс) и записи более 5 мс. Всеми признано, что приемлемо время менее 100 мс для чтения и 20 мс для записи. Однако кому не захочется обвинить «медленный ввод-вывод», увидев, как PAL выдает показатели ввода-вывода, едва превышающие пороговые значения (см. экран 1).

 

Показатели ввода-вывода утилиты PAL
Экран 1. Показатели ввода-вывода утилиты PAL 

Этот пример для меня не нов. В течение длительного времени данная проблема докучала нашей группе администраторов баз данных. Мы уже выполнили миграцию с хранилища VNX «уровня 2» на платформу хранения данных «уровня 1» (HP 9500 SAN.) Мне также было известно, что приложение CA Service Desk имеет существенные изъяны, и в дополнение к ним два человека в нашей компании направляли в базу данных чрезвычайно неэффективные запросы и никак не реагировали на рекомендации по настройке производительности от администраторов баз данных. Среда созрела для повышения производительности как внутренних, так и подготовленных внешним поставщиком запросов, но аналитики хотели только одного: чтобы инженеры, отвечающие за инфраструктуру (сервер, хранилище данных, администраторы баз данных), добавляли оборудование, вместо того чтобы внедрять оптимальные стандарты проектирования и кодирования.

Медлительность целиком объяснялась тем обстоятельством, что в отчетах PAL задержка ввода-вывода для чтения и записи измеряется миллисекундами. Другими словами, реальные задержки ввода-вывода приемлемы. Но поскольку PAL выделила эти элементы как проблемные, не было смысла обращаться к аналитикам. Я воспользовался своим любимым средством, динамическими объектами управления, чтобы решить задачу с учетом фактов и метаданных, применяя знание математики и личный опыт.

Далее в статье мы рассмотрим способы...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.
Купить номер с этой статьей в PDF