Автор: Paul Randal, Page Life Expectancy isn’t what you think…
Существует много споров о счётчике производительности Buffer Manager — Page Life Expectancy, в основном вокруг того, что люди продолжают цитировать 300 в качестве порога для начала беспокойства о проблеме (что в наши дни является полной ерундой). Это слишком низкое значение, чтобы быть точкой, на которой стоит начинать беспокоиться, если ваш PLE падает и остаётся на этом уровне. Джонатан предложил лучшее число, основанное на размере вашего буферного пула — см. нижнюю часть его статьи здесь.
Но не поэтому я пишу сегодня: я хочу объяснить, почему в настоящее время Page Life Expectancy в большинстве случаев не даёт вам полезной информации.
Большинство новых систем сегодня используют NUMA, поэтому буферный пул разделён и управляется на каждый узел NUMA, причём каждый узел NUMA получает собственный поток «ленивого писателя» (lazy writer), управляет собственным списком свободных буферов и обрабатывает локальные для узла выделения памяти. Думайте о каждом из них как о мини-буферном пуле.
Счётчик Buffer Manager:Page Life Expectancy вычисляется путём сложения PLE каждого мини-буферного пула и последующего расчёта среднего значения. Но это не среднее арифметическое, как мы все думали всегда, это среднее гармоническое (см. Википедию здесь), поэтому значение ниже, чем среднее арифметическое. (05.11.2015: Спасибо Мэтту Слокуму (Matt Slocum) (б | т) за указание на расхождение со средним арифметическим в большой NUMA-системе и за то, что он побудил меня копать глубже, и моему другу Бобу Дорру (Bob Dorr) из CSS за изучение кода.)
Что это означает? Это означает, что общий PLE не даёт вам истинного представления о том, что происходит на вашей машине, так как один узел NUMA может испытывать нехватку памяти, но общий PLE лишь незначительно снизится. У одного из моих друзей, который является инженером Premier Field Engineer и MCM, сегодня как раз возникла такая ситуация, которая и побудила меня написать это. Загадка заключалась в том, как может быть более 100 операций lazy writes в секунду, когда общий PLE относительно стабилен, — и вот в этом и была проблема.
Например, для машины с 4 узлами NUMA, где PLE каждого узла равен 4000, общий PLE равен 4000.
Расчёт таков: сложите обратные величины от (1000 × PLE) для каждого узла, разделите это на количество узлов, а затем разделите на 1000.
В моём примере это: 4 / (1/(1000 × 4000) + 1/(1000 × 4000) + 1/(1000 × 4000) + 1/(1000 × 4000)) / 1000 = 4000.
Теперь, если один из них упадёт до 2200, общий PLE упадёт только до: 4 / (1/(1000 × 2200) + 1/(1000 × 4000) + 1/(1000 × 4000) + 1/(1000 × 4000)) / 1000 = 3321.
Если бы у вас было настроено оповещение на падение PLE на 20%, оно бы не сработало, даже если один из буферных узлов испытывал высокую нагрузку.
И нужно быть осторожным, чтобы не переусердствовать с реакцией. Если один из них упадёт до 200, общий PLE упадёт только до: 4 / (1/(1000 × 200) + 1/(1000 × 4000) + 1/(1000 × 4000) + 1/(1000 × 4000)) / 1000 = 695, что может заставить вас думать, что сервер серьёзно страдает повсеместно.
На NUMA-машинах вам нужно смотреть на счётчики Buffer Node:Page Life Expectancy для всех узлов NUMA, иначе вы не получите точного представления о нехватке памяти в буферном пуле и можете упустить проблемы с производительностью или отреагировать на них чрезмерно. И скорректируйте пороговое значение Джонатана в соответствии с количеством узлов NUMA, которое у вас есть.
Вы можете увидеть активность «ленивого писателя» для каждого узла NUMA, найдя потоки lazywriter в sys.dm_exec_requests.
Комментариев нет:
Отправить комментарий