Назад | Перейти на главную страницу

Оценка производительности SQL Server?

Что вы делаете в первую очередь, если вам позвонят или поговорят о проблеме с производительностью SQL-сервера?

Начать след? Всплывающий Perfmon? Открыть монитор активности?

Каждый из этих инструментов полезен, но какова ваша «последовательность» устранения неполадок?

Смотря как.

Это внезапная, неожиданная проблема с производительностью - очень медленная проблема или это долгосрочный случай общей низкой производительности?

Если это первое, я начну с DMV, связанных с выполнением (sys.dm_exec_requests). Есть ли блокировки? Есть ли запрос, который выполняется слишком долго или использует большие ресурсы? В основном я буду искать что-то ненормальное (обратите внимание, чтобы увидеть это, я должен знать, что нормально)

Если последнее, я воспользуюсь методом, о котором писал в этих статьях.

http://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server,-part-1/

http://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server,-part-2/

Первым делом? Поговорите с пользователем.

Что изменилось?

Эта низкая производительность - новая вещь, возникла она внезапно или только нарастает?

Что показывают ваши исторические отчеты (SQLH2) за последний месяц?

Проверьте сервер на наличие дискового пространства, использования оперативной памяти, использования процессора (в указанном порядке). Правильно ли была настроена в первую очередь сервер (настройки оперативной памяти) - taskmgr.

Проверьте работоспособность самостоятельно. Вам это кажется медленным?

Привык ли пользователь к «мгновенной» производительности новой системы (нет данных) и теперь начинает тащить?

... Затем вы можете приступить к исследованию возможных проблем. Сначала вы должны установить эталон, иначе вы никогда не узнаете, когда закончите.

Прежде чем я сделаю все вышеперечисленные предложения, я бы сделал следующее:

SELECT 

        @@total_read AS 'Total Read', 
        @@total_write AS 'Total Write', 
        @@total_errors AS 'Total Error',
        @@io_busy AS 'IO Processing Time (ms)',
        @@cpu_busy AS 'CPU Processing Time (ms)',
        @@idle AS 'Idle Time (ms)'

[Я ссылаюсь на свое сообщение в блоге: http://dbalink.wordpress.com/2009/04/28/monitoring-sql-server-performance-quickie-edition/ ]

Использовать SQLIO. Вы можете прочитать целую кучу материалов о том, какие переключатели / заклинания использовать, но просто запустив его на дисках, на которых хранятся ваши MDF / LDF (например, sqlio.exe / dCDE), вы получите отличный заголовок «МБ / с». для сравнений. Я отследил низкую производительность нашего приложения на сайте клиента, вплоть до конкуренции за диск / LUN в Hitachi AMS (дисковая система Fibre Channel). Диск моего ноутбука работал в 10 раз лучше! Вскоре, когда наша база данных получила собственный LUN, наше приложение снова стало счастливым.

Проверьте файлы журналов, особенно любые журналы «длинных запросов», которые у вас могут быть. Если не горит, включите.

Проверьте общее состояние машины - это может быть не SQL-сервер, это может быть вся машина - проверьте, нет ли неуправляемых процессов, общего использования процессора, общего использования памяти - вы графически изображаете эти вещи с помощью кактусов или тому подобного для исторического сравнения, верно? Так что проверьте графики и посмотрите, когда все, что медленное, начало замедляться.

Чтобы добавить в список:

Найдите в журнале ошибок:

  • признаки коррупции (823s, 824s, 825s)
  • признаки проблем с производительностью ввода-вывода (операции ввода-вывода занимают больше времени, чем X ошибок)
  • проблемы с конфликтом защелок в базе данных tempdb
  • Рабочий набор SQL Server выгружается на 64-разрядный компьютер

Проверьте фрагментацию индекса. Убедитесь, что у вас правильно настроено автоматическое увеличение и включена мгновенная инициализация. Убедитесь, что у вас не включено автоматическое сжатие.

Много информации обо всем этом в моем блоге - могу разместить ссылки, если хотите.

Изолируйте проблему

  1. Проверьте сеть в порядке
  2. Убедитесь, что серверная машина не забита
  3. Проверить журнал событий
  4. Проверьте заблокированные ресурсы сервера sql (sp_lock или sys.dm_tran_locks)

Изолирование от хранимой процедуры или представления

  1. Проверьте код на наличие очевидных проблем, например @tables должно быть #tables
  2. Проверить план выполнения для scans которые должны быть seeks
  3. Изолируйте SQL, который работает медленнее всего
  4. Включите статистику ввода-вывода и процессора (SET STATISTICS IO ON и т.д.), чтобы получить базовые показатели производительности
  5. Поиграйте с SQL, индексами и т. Д.
  6. Еще раз измерить производительность ввода-вывода и процессора
  7. Если недостаточно улучшено goto 5 else goto pub

Это зависит от проблемы, но первое, что я обычно делаю, это смотрю на код, чтобы увидеть, не является ли он причиной неэффективности. Затем я обычно проверяю затронутые таблицы и убеждаюсь, что у них есть все соответствующие индексы и т. Д.