Отстраняването на проблеми с производителността е изкуство и наука. Изкуството идва от опита (и ученето от опита на другите), а науката идва от добре познатите насоки за това какво да правим в кои сценарии.
Или поне това обичам да мисля и да преподавам.
В действителност много администратори на база данни и разработчици практикуват това, което аз наричам „отстраняване на неизправности в работата на коляно“. Това обикновено се случва, когато проблемът с производителността е достигнал критичния етап, например с изтичане на времето на заявките, бавно или неуспешно протичане на процесите, недоволни потребители, а ръководството иска бързо отговори и действия!
„Коляното“ идва от извършването на някакъв повърхностен анализ на проблема и прискачането до заключението (всъщност това е хващане за сламка), че най-разпространеният симптом трябва да е първопричината и опитите за справяне с нея, без или с малка полза, често използвайки погрешни или направо неправилни съвети, намерени онлайн. Това води до много неудовлетвореност и загуба на време и често води до загуба на пари, когато организацията реши да се опита да хвърли хардуер за проблема чрез надграждане на сървъра и/или I/O подсистемата, само за да открие, че проблемът все още е там , или се появява отново доста бързо отново.
Анализът на статистическите данни за чакане е една от областите, в които е най-лесно да се дръпнете и в тази публикация ще говоря за няколко от често срещаните типове изчакване и грешките, които хората правят около тях. В статия като тази няма възможност да навлизаме в голяма дълбочина какво да правите във всеки отделен случай, но ще ви дам достатъчно информация, за да ви насоча в правилната посока.
LCK_M_XX
Повечето хора приемат, че ако изчакванията за заключване са най-разпространените, тогава проблемът трябва да е някакъв проблем с блокирането. Често е така, като например липса на подходящ неклъстериран индекс, причиняващ сканиране на таблица в REPEATABLE_READ или SERIALIZABLE нива на изолация, което ескалира до S заключване на таблица. (И като бърз намек, ако не мислите, че някога използвате SERIALIZABLE, го правите, ако използвате разпределени транзакции – всичко се преобразува в SERIALIZABLE под кориците, което може да доведе до неочаквано блокиране и блокиране.)
Често обаче блокирането е причинено от нещо друго. При нивото на изолация по подразбиране READ_COMMITTED, заключванията, покриващи промените, се задържат, докато транзакцията не се завери и ще блокира четенията и други актуализации на същия ред(ове). Ако нещо попречи на транзакция да се извърши, това може да доведе до показване на блокиране.
Например, ако базата данни е синхронно огледална, тогава транзакцията не може да ангажира и освободи своите заключвания, докато регистрационните записи не бъдат изпратени до огледалото и записани в регистрационния диск на огледалото. Ако мрежата е силно претоварена или има огромни I/O спорове в огледалото, това може сериозно да забави операцията по дублиране и така да накара транзакцията да отнеме много повече време за извършване. Това би изглеждало като блокиране, но основната причина е спорът за ресурси, свързан с огледалното копиране.
За заключващи изчаквания, освен ако причината не е очевидна от разглеждането на плана на заявката, ресурса за заключване (напр. ниво на таблица, показващо ескалация на заключване, или ниво на изолация, следвайте блокиращата верига (използвайки скрипт, който обхожда колоната blocking_session_id в sys.dm_exec_requests и след това Вижте какво чака нишката в главата на блокиращата верига. Това ще сочи към първопричината.
ASYNC_NETWORK_IO
Името на това предизвиква много объркване. Върху коя дума се фокусирате? МРЕЖА. Причината за този тип чакане обикновено няма нищо общо с мрежата. Наистина трябва да се нарича WAITING_FOR_APP_ACK (nowledgement) или нещо подобно, тъй като точно това се случва:SQL Server е изпратил някои данни на клиент и чака клиентът да потвърди, че е използвал данните.
Една от любимите ми демонстрации, които трябва да правя, когато преподавам статистика за чакане, е да стартирам заявка, която връща голям набор от резултати в Management Studio и да гледам как сървърът натрупа ASYNC_NETWORK_IO изчаквания. Очевидно няма замесена мрежа - просто SSMS отнема много време, за да отговори на SQL Server. Той прави това, което е известно като RBAR (Row-By-Agonizing-Row), където само един ред в даден момент се изтегля от резултатите и се обработва, вместо да кешира всички резултати и след това незабавно да отговаря на SQL Server и да продължи да обработва кеширани редове.
Това е основната причина за изчакването на ASYNC_NETWORK_IO – лош дизайн на приложението. След това ще разгледам дали сървърът, изпълняващ кода на приложението, има проблем с производителността, дори ако самият код на приложението е добре проектиран. Понякога това е мрежата, но това е рядкост според моя опит.
OLEDB
Често срещаната реакция на коляно тук е да се приравни този тип чакане със свързани сървъри. Въпреки това, това време за изчакване стана по-често срещано, когато се появи SQL Server 2005, тъй като 2005 съдържаше множество нови DMV, а DMV предимно използват OLE DB под кориците. Преди да потърся проблеми със свързани сървъри, бих проверил дали инструмент за наблюдение изпълнява постоянно DMV на сървъра.
Ако имате свързани сървъри, продължете да отстранявате неизправности, като отидете на свързания сървър и разгледате статистиката за чакането там, за да видите кой е най-разпространеният проблем, и след това продължете същия анализ.
Друго нещо, което може да причини изчакване на OLEDB, е DBCC CHECKDB (и свързаните с него команди). Той използва набор от редове OLE DB, за да комуникира информация между своите подсистеми Процесор на заявки и Машина за съхранение.
Други изчаквания
Някои от другите изчаквания, които причиняват смущаващи реакции, са CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD и WRITELOG и ще ги разгледам в публикацията си следващия месец.
Резюме
Когато имате проблем с производителността, отделете време, за да разберете данните, които разглеждате, и извършете допълнителни проучвания, за да стесните до основната причина за проблема. Не се хващайте само за това, което изглежда, че е най-голямата статистика за чакане, и следвайте първия съвет, който срещнете онлайн (освен ако не е от добре познат и реномиран източник) или вероятно няма да разрешите проблема си и дори влоши нещата.
Що се отнася до общата статистика за чакане, можете да намерите повече информация за използването им за отстраняване на неизправности в производителността в:
- Поредица от публикации в моя блог, започваща със статистически данни за изчакване или моля, кажете ми къде боли
- Моята библиотека за типове чакане и класове на заключване тук
- Моят онлайн курс за обучение на Pluralsight SQL Server:Отстраняване на проблеми с производителността с помощта на статистика за чакане
- Съветник за производителност на SQL Sentry
Това беше първата от поредица публикации, които ще правя през тази година, които говорят за неудобни (ре)акции около SQL Server и защо те са грешно нещо. До следващия път, щастливо отстраняване на неизправности!
