Ако потребителите на вашата база данни мрънкат, че производителността на SQL Server е слаба напоследък, възможно е да изпитвате ефектите от едно или повече тесни места на SQL Server. Тези тесни места възникват по различни причини, но често се случват в резултат на проблеми с паметта, I/O или CPU.
Въпреки че не винаги е лесно да се определи дали проблемите с производителността произтичат от тесно място на SQL Server или от друг източник, можете да потърсите тези често срещани симптоми на тесни места, за да стесните търсенето на източника на проблема.
Чести симптоми на тесни места на SQL сървър
- SQL сървър претоварва процесора
- По-дълго време за изпълнение на заявки
- Прекомерен вход/изход
- Регистър на приложението, показващ съобщения за липса на памет
- Екстремна активност на дисковете
- Дълго време за изчакване на I/O
Внезапната поява на един или повече от тези симптоми е добра индикация, че имате проблем с SQL Server някъде във вашата система. Ваша работа е да го намерите.
Типове тесни места на SQL Server
Има три основни типа тесни места на SQL Server:памет, I/O и CPU. Важно е администраторите на база данни да са запознати с причините, симптомите и корекциите на всеки от тях, за да могат бързо да идентифицират и премахнат пречките и да намалят до минимум въздействието на лошото представяне. Включихме и някои от най-добрите броячи на производителността за наблюдение, които ще помогнат за незабавно идентифициране на тесните места в производителността.
Тесни места в паметта
Тесните места в паметта обикновено са резултат от недостатъчни ресурси на паметта или дейности на SQL Server, които изяждат наличната памет. Симптомите, за които трябва да внимавате, включват по-дълго време за изпълнение на заявка, прекомерно I/O, съобщения за липса на памет в дневника на приложението и чести системни сривове.
Най-добрите начини за избягване на затруднения, свързани с паметта, са да използвате оптимизатор на заявки, за да се отървете от ненужни или остарели заявки и да конфигурирате продължителността на живота на страницата във връзка със съотношението на попадане в кеша на буфера, за да ограничите пътуванията до диска. Ако е твърде късно да избегнете затруднението, опитайте да прегледате и настроите заявките, да преконфигурирате паметта или да добавите физическа памет.
Броячи за наблюдение:налична памет, обща памет на сървъра, памет на целевия сървър, страници/сек, съотношение на попадане в буферния кеш
Тесни места за I/O
Когато няма достатъчно място за съхранение за поддържане на редовни операции с база данни, като TempDB, има вероятност да възникнат тесни места за вход/изход. Дългото време за реакция, забавянето на приложенията и честите изтичания на задачите са всички ключови индикатори, че имате I/O затруднение.
Можете да избегнете този тип затруднения, като настроите мониторинг с аларми и сигнали за прагове, за да идентифицирате кои дейности използват прекомерно количество съхранение. Ако възникне пречка за вход/изход, ограничете четенето и записването на страници от база данни към и от диска. Това ще изисква от вас да проверявате и коригирате чести сканирания на индекси, неефективни заявки и неактуални статистически данни.
Броячи за наблюдение:средна дължина на дисковата опашка, средна дискова сек/четене, средна дискова сек/запис, % време на диск, средно четене на диск/сек, средно записване на диск/сек
Тесни места на процесора
Водещата причина за тесните места на процесора е недостатъчните хардуерни ресурси. Доста лесно е да идентифицирате това тесно място, като проверите вашите регистрационни файлове, за да определите дали SQL Server използва прекомерно CPU.
В идеалния свят бихте могли да избегнете тесните места на процесора, като имате специален сървър само за SQL Server и изпълнявате целия друг софтуер на друга машина. Тъй като това не е опция за повечето DBA, ще трябва да знаете как да премахнете тесното място на вашия процесор.
Първата стъпка е да се идентифицират свинете на процесора. След като разберете къде е проблемът, можете да настроите заявките, да подобрите плановете си за изпълнение или да преконфигурирате системата.
Броячи за наблюдение:% процесорно време, пакетни заявки/сек, SQL компилации/сек, SQL рекомпилации/сек
История за тесните места в производителността на SQL Server
„Имаме някои проблеми с производителността на SQL Server, с които да се справим“, каза шефът ми късно един петък.
"Откъде знаеш?" Попитах.
„Продажбите се оплакват, че тяхната база данни се забавя напоследък. Трябва да видим какво се случва с него."
"ДОБРЕ. Ще резервирам конферентна зала, за да можем да седнем и да работим върху това.”
— Не се притеснявай — каза шефът. „Късно е в петък следобед. Това означава, че най-добрият начин за изследване на тесните места е с няколко наши собствени. Отиваме до Pike Pub на пазара.“
Влязохме в бара, скътан на пазара Pike Place и намерихме малка масичка до прозореца.
„Кой е любимият ви вид тесни места?“ — попита шефът.
Казах, че съм пристрастен към една Naughty Nellie в 22-унции тясно място.
„Добър избор“, каза шефът. „Ти поръчай това, а аз ще имам цитрусовата лятна бира.“
Докато чакахме да пристигнат нашите тесни места, ние се заехме с тесните места в производителността на SQL Server.
„Ще трябва да проверим за проблеми на няколко места“, каза шефът. „Те може да са проблеми с паметта, съхранението или процесорите, но всички изглеждат еднакво за потребителите, нали? Грозно изпълнение.
„Проблемите с процесора не са толкова трудни за намиране. Ако това е проблемът, тогава ще видим, че SQL Server претоварва процесора и го кара да скача през цялото време.
„Ако е проблем с паметта, ще видим неща като по-дълги времена за изпълнение на заявките и повече I/O, защото приложението трябва да продължава да изтича на диска. Можем също да проверим регистрационния файл на приложението за съобщения за изчерпване на паметта.
„И ако тесното място е в хранилището, ще видим изключителна активност на дисковете и дълго време на изчакване на I/O.“
Нашите тесни места пристигнаха. Проучихме ги внимателно, докато разглеждахме проблема с производителността по-задълбочено.
Многото потенциални източници на пречки в производителността на SQL Server
„Ами ако това е I/O проблем?“ Попитах. „Трябва да видим дали времето за изчакване на WRITELOG е твърде голямо в сравнение с общото време за изчакване. Или, като говорим за I/O, може би има проблем в самия SQL. Ако има неефективен код, като NESTED LOOP JOIN в огромна таблица, SQL може да иска да прочете редове във вътрешната таблица милиони пъти. Това наистина ще накаже представянето.”
— Възможно е — каза шефът. „Сложните операции за свързване и сортиране могат да бъдат трудни, особено когато базата данни tempdb не е конфигурирана правилно. Съперничеството за Tempdb изглежда като обикновени заключване на база данни, но всъщност е задържано спорове поради едновременни процеси, всички чакащи своя ред на страниците за разпределение."
„Кои инструменти можем да използваме, за да изследваме всички тези неща?“ Попитах.
„SQL Server имаше профайлър за проверка на съхранените процедури, но той е отхвърлен. Нещо подобно е добър начин за намиране и диагностициране на проблемни заявки, дори ако това е само първата стъпка. След това има динамични изгледи и функции за управление, които ви помагат да наблюдавате здравето на вашия сървър и база данни, да отстранявате проблеми и да настройвате SQL."
„Но SQL Server има толкова много движещи се части“, казах аз. „Предпочитам да имам инструмент, който разглежда цялата картина отвън навътре.“
„И аз също. За предпочитане от облака, така че нямаме нужда от повече хардуер и софтуер на място, за да го направим.“
Облекчаване на тесните места в производителността в SQL Server
Пайк започваше да става претъпкан. И колкото и да желаехме с шефа да седнем в кръчма и да говорим, все пак беше петък вечерта. Имахме други места, които да отидем, други хора, които да видим и други неща, за които да говорим.
„Какво да правим, след като открием тесните места?“ Попитах.
„Ние събираме обичайните заподозрени“, каза шефът. „За да не използваме твърде много памет, трябва да кажем на разработчиците на бази данни кой от техния код и заявки изпуска памет. Ако открием операции, които обединяват четири, пет или шест таблици, ще трябва да дадем на разработчиците някои съвети за настройка на SQL Server и най-добри практики за препроектиране на базата данни. Или може да имаме твърде много индекси и да губим цикли, актуализирайки ги; това е толкова трудно за процесора и I/O, колкото да има твърде малко индекси. Може да имаме проблем с фрагментацията на индекса на SQL Server или може да се наложи да отсеем остарелите и дублирани индекси.“
— Има смисъл — казах аз. „Може би трябва да хвърлим повече хардуер в него. По-бързите дискове могат да помогнат при I/O тесни места. Повече и по-бързи процесори правят разлика във времето за отговор на заявката. А добавянето на RAM означава повече мащабируемост на SQL Server, нали?”
„Да“, каза шефът, „но първо искам да съм сигурен, че основната причина не е проблем с разработката или DevOps. След като се убедя, че не е така, ще изиграя картата Купи още хардуер."
Седнахме за момент и наблюдавахме как кръчмата се пълни с петъчна вечер гуляйджии.
„Шефе“, попитах аз, „мислиш ли, че всички тези хора знаят колко безгрижно съществуване водят всички, без тежестта да се справят с блокирани сесии, максимално изчакване на вход/изход, продължителност на живота на страницата и съотношения на удари в буферния кеш?“ P>
— Това е кръст за носене, нали? – отговори шефът. „Повечето хора нямат представа през какво преминаваме. Добре, че се справяме с тесните места в производителността на SQL Server толкова тихо, с толкова много изящество под напрежение и с толкова добър вкус. Говорейки за добър вкус, как се справяте с тесното си място?”
Проверих. „Тясното ми място е празно. Моята бутилка също.“
"Моят също. Време за тръгване. Имаме работа за вършене."
Възможна ли е нулева система с тесни места на SQL Server?
Знаем, че има стъпки, които можем да предприемем, за да избегнем тези три често срещани типа тесни места на SQL Server. Но възможно ли е да се конфигурира база данни на SQL Server толкова добре, че да има нула тесни места?
Краткият отговор вероятно не е. Дори и най-старият DBA ще има тесни места на SQL Server от време на време. Но можете да предприемете стъпки за проактивно избягване на тесните места и да сведете до минимум тяхното въздействие върху производителността. Например, Brent Ozar предлага няколко страхотни съвета за наблюдение на броячите на Perfmon, за да настроите вашия SQL Server, и можете да използвате изгледа sys.dm_os_performance_counters, за да ви помогне да идентифицирате тесните места и да ги коригирате бързо.
Тесните места на SQL Server са факт от живота на DBA. За щастие, с адекватен надзор, усърдно наблюдение и честа настройка на заявките, проблемите с производителността могат да бъдат разрешени, преди потребителите дори да разберат, че има проблем.
