В тази публикация ще обсъдя обща методология за отстраняване на проблеми с производителността на процесора. Харесва ми да прилагам методологии по подразбиране и също така обичам да изграждам ефективност в начина, по който отстранявам проблеми въз основа на минал опит. Без обща рамка става твърде лесно да се пропусне истинската първопричина в средата на криза.
Стъпките, които ще опиша в тази публикация, са както следва:
- Дефинирайте проблема
- Проверете текущите условия
- Отговорете „SQL Server ли е“?
- Идентифицирайте потребителите на процесора
- Съгласувайте шаблона и разрешете
Тази статия ще обхване всяка от тези стъпки. Ще направя предположение, че може да не използвате инструмент за наблюдение на трета страна. Ако сте все пак, рамката тук все още е в сила, но вашите източници на данни и инструменти, с които разполагате, ще се различават от това, което описвам.
Дефинирайте проблема
Първо трябва да обхванем проблема. Когато някой дойде при вас и каже, че вижда проблем с производителността на процесора, това може да означава много различни неща. Така че първата задача е да разберем какво естеството на проблема с производителността на процесора в момента.
Някои често срещани категории включват:
- Наличността е засегната поради „обвързани процесори“. Например – всички планировчици работят на 100% навсякъде и пропускателната способност е в застой или значително намалена.
- Влошаване на производителността поради използване на процесора „по-високо от нормалното“. Така че не сме фиксирани, но процесорите ви работят с по-висок процент от обикновените и вероятно това оказва влияние върху производителността.
- Друга често срещана категория проблем с производителността на процесора е сценарият „победители и губещи“, при които работните натоварвания се конкурират едно срещу друго. Може би имате OLTP работно натоварване, което среща намалена пропускателна способност поради паралелно изпълнявана заявка за отчет.
- Друг проблем може да бъде срещата на повратна точка – когато общият капацитет и ограниченията за мащабируемост на вашата система са засегнати в определен момент.
Споменавам тези всеобхватни категории като отправна точка, но знам, че често може да има силни зависимости между тези проблеми и една категоризация може да се смеси с другата. С това казано, първата стъпка е да дефинирате симптомите и проблемите възможно най-ясно.
Проверете текущите условия
Независимо дали проблемът се е случил в миналото или се случва в момента, важно е да получите възможно най-много основна информация за системата, работното натоварване и конфигурациите. Ако използвате базови линии и run-books, в идеалния случай вече проследявате голяма част от тази информация. Ако не, запитайте се колко бързо бихте могли да получите отговори на тези въпроси в 2 часа сутринта в разгара на криза.
Следващите подраздели обхващат важни точки от данни, които обикновено ме интересуват за проблем с производителността на процесора.
- Колко гнезда и ядра?
- Активирана ли е хипернишковата обработка?
- Какъв е моделът на процесора, архитектурата (32-битова/64-битова)?
- Това виртуален гост ли е?
- Ако е така, вече ще се интересувате и от подробности за домакина и другите виртуални гости, с които споделяте ресурси.
- Има ли в сила настройки, свързани с процесора?
- Например Hyper-V CPU
- Колко vCPU са разпределени между гостите?
- Колко vCPU има този гост?
- Гостът беше ли мигриран наскоро към нов хост преди проблема?
- Настройка на максимална степен на паралелизъм
- Праг на разходите за опция за паралелизъм
- Настройка за афинитет на процесора
- Настройка за приоритетно усилване
- Настройка на максимален брой работни нишки
- Олекотена настройка за обединяване
- Каква е настройката на опцията за захранване? (ниво на ОС, VM Host или контролиран от BIOS)
- Висока производителност, балансирана, икономия на енергия?
- Конфигуриран ли е извън настройките по подразбиране?
- Виждате ли някакви необичайни предупреждения или грешки?
Подробности за физически сървър
Подробности за виртуалния сървър
Резервиране, VMware CPU Reservation, Hyper-V CPU Relative Weight и VMware CPU Shares.
Настройки за конфигурация на екземпляр на SQL сървър
Първите три конфигурации може да изискват допълнително обсъждане. Рядко има абсолюти по отношение на тези настройки.
По отношение на последните три настройки, като например „усилване на приоритета“, ако видя, че те са на стойности, които не са по подразбиране, определено ще настоявам за повече основна информация и история.
Настройки за захранване на процесора
Настройките на опциите за захранване под „Висока производителност“ все още са много често срещани и не трябва да се пренебрегват за сървъри, които хостват екземпляри на SQL Server.
Конфигурация на Resource Governor
Все още намирам, че рядко се срещат клиенти, използващи тази функция изобщо, но е лесно да се потвърди дали се използва и ще си струва за времето, когато е конфигурирана извън стандартната.
Регистър за грешки на SQL Server и регистрационни файлове за събития на Windows
Защо да търсите в регистрите за грешки и събития за проблем с процесора? Понякога проблемите нагоре по веригата могат да причинят проблеми с производителността надолу по веригата в SQL Server. Не искате да губите време за настройване на заявка или добавяне на нов индекс, когато сте нагоре по веригата, основната причина е проблем с влошаване на хардуерния компонент.
Отговорете „SQL Server ли е?“
Звучи очевидно, когато го попитам, но наистина не искате да отделяте значително време за отстраняване на проблем с високо ниво на процесора в SQL Server, ако виновникът всъщност не е SQL Server.
Вместо това отделете малко време, за да проверите кой процес консумира най-много процесор. Има няколко опции, от които да избирате, включително:
- Процес:% потребителско време (потребителски режим)
- Процес:% привилегировано време (режим на ядрото)
- Диспечер на задачите
- Process Explorer
- Последна информация за процесора чрез sys.dm_os_ring_buffers или сесията за здравето на системата за конкретните екземпляри на SQL Server, работещи в системата
Ако това е SQL Server и имате няколко екземпляра на SQL Server, от които да избирате, уверете се, че отстранявате правилния екземпляр на SQL Server на хоста. Има няколко начина да направите това, включително използването на SELECT SERVERPROPERTY('processid') за да получите PID и след това да го свържете с Task Manager или Process Explorer.
След като потвърдите, че това е SQL Server, виждате ли високо потребителско време или привилегировано време (ядрото)? Отново това може да бъде потвърдено чрез Process:% Privileged Time (sqlservr обект) и също така Windows Task Manager или Process Explorer.
Въпреки че проблемите с високо време на ядрото би трябвало да са редки, те все още изискват различни пътища за отстраняване на неизправности от стандартните проблеми с отстраняването на неизправности на CPU за потребителско време. Някои потенциални причини за високо време на ядрото включват дефектни филтърни драйвери (антивирусни, криптиращи услуги), остарели или липсващи актуализации на фърмуера и драйвери, или дефектни I/O компоненти.
Идентифицирайте потребителите на процесора
След като потвърдите кой екземпляр на SQL Server управлява използването на процесора от потребителско време в системата, в мрежата има много примери за предварително консервирани заявки, които можете да използвате.
По-долу е даден списък с DMV, които хората обикновено използват в различни форми по време на проблем с производителността. Структурирах това във формат за въпроси и отговори, за да ви помогна да разберете защо бихте искали да получите достъп до тях.
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_sessions
- sys.dm_exec_connections
- sys.dm_exec_query_plan
- sys.dm_os_waiting_tasks
- sys.dm_exec_query_stats
- Агрегиране по общо_време_работник
- Дефинирайте средните стойности с execution_count
- Ако ad hoc работни натоварвания, можете да групирате по query_hash
- Използвайте plan_handle с sys.dm_exec_query_plan, за да вземете плана
- sys.dm_os_tasks
- Поредено по session_id, request_id
- sys.dm_exec_query_plan
- Погледнете операторите на планове – но имайте предвид, че това е само прогнозният план
- sys.dm_exec_query_stats
- Филтрирайте total_elapsed_time по-малко от total_worker_time
- Но имайте предвид, че това може да бъде фалшиво отрицателно за сценарии за блокиране – при които продължителността е завишена поради изчакване на ресурс
Какви заявки се изпълняват в момента и какво е тяхното състояние?
Какво изпълнява?
Откъде е?
Какъв е прогнозният план? (но внимавайте да раздробявате xml на система, която вече е ограничена от процесора)
Кой чака ресурс и какво чака?
Кои заявки са заели най-много процесорно време от последното рестартиране?
Тази заявка използва ли паралелизъм?
Съгласувайте шаблона и разрешете
Вероятно се смеете на тази конкретна стъпка - тъй като тази може да бъде най-ангажирана (и е друга причина, поради която професионалистите на SQL Server са наети на работа). Има няколко различни модела и свързани резолюции – така че ще завърша тази публикация със списък на по-често срещаните драйвери за проблеми с производителността на процесора, които съм виждал през последните няколко години:
- Високи I/O операции (и според моя опит това е най-често срещаният драйвер на CPU)
- Проблеми с оценката на кардиналността (и свързаното с тях лошо качество на плана на заявките)
- Неочакван паралелизъм
- Прекомерна компилация/прекомпилиране
- Извиквания на UDF с интензивни изчисления, операции за раздробяване
- Агонизиращи редове операции
- Едновременни дейности по поддръжка (напр. АКТУАЛИЗИРАНЕ на статистика с FULLSCAN)
Всяка област, която идентифицирах, има голяма свързана работа за изследване. По отношение на консолидираните ресурси, все още смятам, че един от по-добрите все още е техническата статия „Отстраняване на проблеми с производителността в SQL Server 2008“, написана от Сунил Агарвал, Борис Баришников, Кийт Елмор, Юрген Томас, Кун Ченг и Бурзин Пател.
Резюме
Както при всяка методология, има граници за нейното използване и области, в които можете да импровизирате. Моля, имайте предвид, че не предлагам стъпките, които описах в тази публикация, да се използват като твърда рамка, а вместо това да ги считам за начална точка за вашите усилия за отстраняване на неизправности. Дори професионалистите с голям опит в SQL Server могат да направят нови грешки или да бъдат предубедени от по-скорошния си опит при отстраняване на неизправности, така че наличието на минимална методология може да помогне да се избегне отстраняването на неправилен проблем.
