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

Обосновывая обновление памяти, возьмите 2

Раньше я спрашивал вопрос какие показатели мне следует измерить (например, до и после), чтобы оправдать обновление памяти. Был предложен Перфмон.

Я хотел бы знать, какой конкретный счетчики perfmon, которые я должен измерить. Пока я получил:

PhysicalDisk/Avg. Disk Queue Length (for each drive)
PhysicalDisk/Avg. Disk Write Queue Length (for each drive)
PhysicalDisk/Avg. Disk Read Queue Length (for each drive)
Processor/Processor Time%
SQLServer:BufferManager/Buffer cache hit ratio

Какие еще мне следует использовать?

Это, наверное, не самые лучшие счетчики. Проблема с дисковым вводом-выводом заключается в том, что он не будет настолько полезным, потому что дисковый ввод-вывод намного больше зависит от оптимизации базы данных, если вся база данных не находится в памяти. Такие операции, как сканирование таблиц и сценарии создания отчетов / загрузки, будут перегружать вашу память. Сильная нагрузка ввода-вывода приведет к вводу-выводу в файл журнала, независимо от объема памяти.

Эти дисковые счетчики также не подходят для анализа диска - длина очереди не всегда ясна, потому что она зависит от схемы вашего оборудования. Например, 250 может быть неплохой длиной очереди для вашего диска, но, возможно, нет, если у вас есть большая сеть SAN, которая может обрабатывать множество параллельных запросов.

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

На память я бы взял:

  • Диспетчер памяти SQL: ожидающие предоставления памяти
  • SQL Buffer Manager: продолжительность жизни страницы

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

Сначала я предлагаю прочитать мою ответ как работает память Windows. После этого поговорим о счетчиках. С точки зрения чистого мониторинга производительности память сервера и производительность SQL Server не связаны прежде всего потому, что SQL Server (если он настроен правильно) использует возможность блокировки страниц в памяти, чтобы переопределить схему управления памятью Windows по умолчанию. Если посмотреть только на память, упомянутые ранее счетчики в порядке:

Диспетчер памяти SQL: ожидающие предоставления памяти

SQL Buffer Manager: продолжительность жизни страницы

Объект диспетчера буферов SQL Server: коэффициент попадания в буферный кэш

Я бы также добавил

SQLServer: диспетчер памяти: общий объем памяти сервера (КБ) - показывает, сколько SQL Server управляет.

SQLServer: Диспетчер памяти: Память целевого сервера (КБ) - это показывает, сколько, по мнению SQL Server, он хотел бы иметь, в зависимости от количества буферов, зарезервированных SQL Server при его первом запуске. Если общее количество меньше целевого, дополнительная оперативная память вряд ли поможет. Если цель больше, вы мощь извлеките выгоду из большего объема памяти.

Смотрите также, что следует отслеживать базовую производительность SQL Server.