Автор: Konstantin Kosinsky
Довольно часто приходится слышать утверждения типа: «Фичу «A» стоит отключить, так как она может тормозить систему». Такие утверждения обычно стоиться на том, что каждая дополнительная фича стоит серьезных системных ресурсов, особенно, если она связана с журналированием операций или дополнительными проверками целостности. Постепенно системы обрастают набором рекомендаций по тюнингу, и многие ищу решения проблем производительности не в дизайне базы данных и запросах к ней, а в таких наборах рекомендаций.
Например, когда только вышел в свет SQL Server 2005, было немало комментариев и споров, что работает быстрее SQL Server 2000 и SQL Server 2005. В некоторых из них поднималась тема включенных по умолчанию опций, которые могли замедлить работу любых операций. Таких опций две:
-
Page Checksum
Данная опция включает постоянную проверку контрольной суммы для Data Page, которая в свою очередь является единицей хранения и чтения/записи данных в SQL Server 2005. Ее включение полезно, т.к. позволяет на ранних стадиях упреждать порчу файлов базы данных.
-
Default Trace
Многие пользовались SQL Profiler’ом при помощи которого можно протоколировать события, происходящие в базе данных, в частности запросы которые к ней отсылаются. Но не многие знают, что запустить профилирование можно и из T-SQL, без использования графического интерфейса, что дает возможность постоянно накапливать журнал, а просматривать его только когда это действительно нужно. Кроме того, если в качестве места для хранения такого журнала выбрать таблицу базы данных, то можно его анализировать при помощи SQL запросов. Создается такой Trace, при помощи хранимых процедур: sp_trace_create, sp_trace_setevent, sp_trace_setfilter. А просмотреть список запущенных Trace’ов при помощи функции fn_trace_getinfo или таблицы sys.traces. По умолчанию в SQL Server 2005 один такой Trace включен.
В рекомендациях по тюнингу SQL Server 2005 рекомендовалось обе опции отключить, т.к. они существенно замедляют систему (от 10-ок процентов до нескольких раз).
Что же есть на самом деле?
Linchi Shea в своем блоге представил результаты тестирования SQL Server 2005 в разными комбинациями этих опций. При тестировании использовался стандартный TCP/C тест с достаточно большой базой данных (150Гб), мощным сервером (4 процессорный сервер с 16Гб ОЗУ) и серьезной нагрузкой (до 400 одновременных пользователей). Результаты показаны на картинках ниже:
Результаты теста говорят о том, что отличия находятся на уровне погрешности эксперимента.
В этом же блоге, представлен результат тестирования влияния частых обращений к DMV, и схожий результат.
В качестве вывода хочу добавить старое как мир утверждение: Если вы хотите улучшить производительность, сначала оцените ее при помощи некоторых тестов в числовом виде.
PS. Для выполнения TPC/C теста можно воспользоваться утилитой Benchmark Factory либо Visual Studio Team System. В последнем случае нужно создать Database Unit Test’ы для каждой из 5-ти типов транзакций TPC/C (см. Team Edition for Database Professionals) и создать на их базе Load Test (см. Team Edition for Software Testers).
P.S. Из личного опыта наибольший выигрыш в производительности дают оптимизация схемы и запросов, а не настройка сервера.