как видеть уровень удачного обращения в кэш SQL Server?
Инструменты Google Analytics и Google Webmaster делают в значительной степени все, в чем я нуждаюсь. Хороший и свободный.
Взгляните на BOL: SQL Server, Объект Buffer Manager.
Две области, что необходимо посмотреть сначала:
Кэш процедур является областью памяти, где SQL хранит Ваши планы запросов.
Кэш-буфер является областью памяти, где страницы данных хранятся.
Соответствующие счетчики perfmon:
- Процент совпадений кэш-буфера
- Продолжительность жизни страницы
- Страница, reads/sec
Главные Проблемы производительности SQL Server 2005 для Приложений OLTP содержат следующее:
Узкое место ЦП, если …
Signal ожидает>, 25% общего количества ожидают. См., что sys.dm_os_wait_stats для Signal ожидает, и Total ожидает. Signal ожидает, измеряют время, проведенное в выполнимой очереди, ожидающей ЦП. Высокий сигнал ожидает, указывают на узкое место ЦП.
Запланируйте повторное использование <90%. План запросов используется для выполнения запроса. Запланируйте повторное использование желательно для рабочих нагрузок OLTP, потому что воссоздание того же плана (для подобных или идентичных транзакций) является тратой ресурсов ЦП. Сравните SQL Statistics SQL Server: пакетные запросы/секунда к компиляциям/секунда SQL. Вычислите повторное использование плана следующим образом: Запланируйте повторное использование = (Пакетные запросы - компиляции SQL) / Пакетные запросы. Специальное исключение к правилу повторного использования плана: Нулевые планы стоимости не будут кэшироваться (не снова использованный) в SQL 2005 SP2. Приложения, которые используют нулевые планы стоимости, будут иметь более низкое повторное использование плана, но это не проблема производительности.
Параллельный тип ожидания cxpacket> 10% общего количества ожидает. Параллелизм жертвует ресурсами ЦП за скорость выполнения. Учитывая большие объемы OLTP, параллельные запросы обычно уменьшают пропускную способность OLTP и должны избежаться. См. sys.dm_os_wait_stats для статистики ожидания.
Узкое место памяти, если …
Последовательно низкая средняя продолжительность жизни страницы. См. Средний Счетчик Продолжительности жизни Страницы, который находится в Buffer Manager SQL Server объекта Perfmon (это представляет, среднее число секунд, страница остается в кэше). Для OLTP средняя продолжительность жизни страницы 300 составляет 5 минут. Что-либо меньше могло указать на давление памяти, пропустив индексы или очистку кэша.
Внезапное большое понижение продолжительности жизни страницы. Приложения OLTP (например, маленькие транзакции) должны иметь устойчивое (или медленно увеличивающийся) продолжительность жизни страницы. См. Buffer Manager SQL Server объекта Perfmon.
Незаконченные предоставления памяти. Посмотрите, что встречные Предоставления Памяти Ожидают в Диспетчере памяти SQL Server объекта Perfmon. Маленькие транзакции OLTP не должны требовать предоставления памяти большой емкости.
Внезапные отбрасывания или consistenty низкое отношение Удачного обращения в кэш SQL. Приложения OLTP (например, маленькие транзакции) должны иметь высокое отношение удачного обращения в кэш. Так как транзакции OLTP являются маленькими, не должно быть (1) большие падения уровней Удачного обращения в кэш SQL или (2) последовательно низкие уровни удачного обращения в кэш <90%. Отбрасывания или низкое удачное обращение в кэш могут указать на давление памяти или недостающие индексы.