Показателят за продължителност на живота на страницата на SQL Server (PLE) отдавна се счита за ключов показател за ефективността на администраторите на база данни, които разглеждат цялостното здраве на техните екземпляри от база данни. PLE показва дали системата е под напрежение във вътрешната памет, като използва броячи, предоставени от обекта Buffer Manager.
По-подробен поглед върху продължителността на живота на страницата
PLE е мярка за продължителността на времето (в секунди), през което се очаква страница с файл с данни да остане в буферния пул на SQL Server. Този показател не е сбор или натрупване, а просто стойност в даден момент, която DBA ще поиска от Buffer Manager.
SQL Server чете страници с данни само от буферния пул (т.е. логическо четене), така че ако страницата не е в буферния пул, той я намира на диска (т.е. физическо четене) и премества страницата в буферния пул, така че може да направи логично четене. Това е отнемащ време процес и може да повлияе негативно на производителността.
Какво е „добра“ PLE стойност?
Висока стойност на PLE означава, че една страница остава в буферния пул по-дълго, така че е по-малко вероятно SQL Server да отиде на диск, търсейки страницата с данни, което кара системата да работи по-бързо.
В исторически план DBA смятат 300 секунди (пет минути) за сладкото място на PLE. Това число обаче е доста произволно. Microsoft препоръча 300 като стандарт PLE още през 2000-те, когато паметта беше ограничена.
Днес DBA не се фокусират върху „правилния“ номер, тъй като пакетите с памет са стандартни за повечето системи. Не е необичайно SQL Server да работи на система, която разполага с TB RAM, така че DBA са възприели шаблонен подход за идентифициране на „добра“ PLE стойност:
Продължителност на живота на страницата =300 секунди за всеки 4 GB RAM на вашия сървър
Въпреки това, може би е по-важно непрекъснато да наблюдавате стойностите на PLE за промени в последователността, за да можете да идентифицирате проблеми с паметта и да ги разрешите бързо.
Ако работите с голям обем данни, важно е да се отбележи, че по-големите сървъри често имат множество PLE. Всеки възел за неравномерен достъп до паметта (NUMA) получава своя собствена стойност на PLE и след това тези числа се изчисляват, за да се получи PLE стойността на сървъра. Например вземете PLE стойността на възела x 1000 (направете това за всички NUMA възли). Добавете стойностите на всички възли, след това разделете на общия брой възли NUMA, след което отново разделете на 1000. Това ще ви даде сървъра PLE.
Как да определим дали има проблем с продължителността на живота на страницата
Колебанията в PLE са нормални, защото се основават на натоварването. Проследяването на високи, средни и ниски тенденции може да ви покаже дали определени процеси, като сканиране на таблици или промиване на буферния кеш, трябва да бъдат настроени, за да се подобри PLE.
Добър начин да определите дали има проблем е ако нормалният диапазон на стойностите на PLE спадне и остане нисък. Това показва, че вероятно има повишено търсене и натиск върху буферния пул.
Това означава ли, че трябва да хвърлите още малко памет за проблема? Може би. Може би не.
Отстраняване на ниска продължителност на живота на страницата на SQL Server
Има няколко причини, поради които стойностите на PLE може да са ниски. Важно е да отстраните проблема, защото решението не е едно и също за всяка първопричина. Ето три от виновниците, които най-вероятно ще забавят вашия PLE:
Недостатъчно памет
Ако работното натоварване непрекъснато нараства и PLE намалява, вероятно имате недостиг на памет. Добавянето на памет може да помогне за увеличаване на PLE, но няма да накара заявките да работят по-ефективно.
Скъпи операции
Ако работното натоварване не се е променило, но има повишено търсене на буферния пул, може да се окаже, че отклоненията използват повече памет. Проверете дали има изпълнявани задачи за поддръжка или се извършва възстановяване на индекса.
Застояли статистически данни
Застоялите статистически данни могат да причинят промени в плана на заявката. Това увеличава търсенето на буферния пул, като води до изпълнение на скъпи операции, тъй като те не се синхронизират с нови статистически данни.
Как да коригираме ниската продължителност на живота на страницата чрез оптимизиране на заявките
Най-добрият начин да коригирате ниските стойности на PLE е като отидете до източника и оптимизирате вашите SQL Server заявки. Това идва с допълнителен бонус, тъй като оптимизирането на заявките ще подобри цялостната производителност на вашата система в същото време.
Има няколко неща, които ще искате да направите, които ще ви помогнат да оптимизирате заявките за максимално подобряване на PLE:
- Изхвърлете неизползваните индекси
- Обединяване на дублиращи се индекси
- Търсете големи заявки
- Разберете какво има в буферния пул
- Дефрагментиране на индекси
- Актуализиране на статистическите данни
- Изчистване на данните
Проследяване на продължителността на живота на страницата във времето
Въпреки че PLE е показател за момента, разглеждането на PLE във времето е важен начин за ранно идентифициране на проблемите и тяхното бързо отстраняване, преди производителността да бъде значително засегната.
Има много начини да наблюдавате PLE метриката във времето и да идентифицирате заявките, чиито транзакции причиняват голямо количество четения. DMV и разширените събития в SQL Server са изпитаните методи и са били инструментални в този процес на събиране на данни. Но те също са ръчни и отнемат време и предлагат ограничени ползи, когато става въпрос за придобиване на историческа перспектива за метричната ефективност с течение на времето.
Търговско решение като Spotlight Cloud не само предоставя на DBA възможността да проследяват PLE във времето направо от кутията, но също така анализира работното натоварване, за да идентифицира кои заявки и извънредни дейности причиняват натиск върху буферния пул, за да можете да изолирате и коригирате проблем и оптимизирайте производителността на вашия SQL Server.
Първоначално публикувано през април 2019 г. и актуализирано през септември 2020 г.
