Als uw databasegebruikers mopperen dat de prestaties van SQL Server de laatste tijd matig zijn, is het mogelijk dat u de effecten ervaart van een of meer SQL Server-knelpunten. Deze knelpunten treden om verschillende redenen op, maar ze treden vaak op als gevolg van problemen met geheugen, I/O of CPU.
Hoewel het niet altijd gemakkelijk is om te bepalen of prestatieproblemen het gevolg zijn van een SQL Server-bottleneck of van een andere bron, kunt u deze veelvoorkomende symptomen van bottlenecks opzoeken om uw zoektocht naar de bron van het probleem te verfijnen.
Veelvoorkomende symptomen van SQL Server-knelpunten
- SQL-server belast de processor
- Langere uitvoeringstijden voor zoekopdrachten
- Overmatige I/O
- Toepassingslogboek met berichten over onvoldoende geheugen
- Extreme activiteit op de schijven
- Lange wachttijden per I/O
De plotselinge verschijning van een of meer van deze symptomen is een goede indicatie dat u ergens in uw systeem een SQL Server-bottleneck heeft. Nu is het jouw taak om het te vinden.
Soorten SQL Server-knelpunten
Er zijn drie hoofdtypen SQL Server-knelpunten:geheugen, I/O en CPU. Het is belangrijk dat DBA's bekend zijn met de oorzaken, symptomen en oplossingen van elk, zodat ze de knelpunten snel kunnen identificeren en verwijderen en de impact van slechte prestaties kunnen minimaliseren. We hebben ook enkele van de beste prestatiemeteritems toegevoegd om te controleren, waarmee u knelpunten in de prestaties onmiddellijk kunt identificeren.
Geheugenknelpunten
Geheugenknelpunten zijn meestal het gevolg van onvoldoende geheugenbronnen of SQL Server-activiteiten die het beschikbare geheugen opslokken. De symptomen waar u op moet letten zijn onder meer langere uitvoeringstijden van query's, overmatige I/O, berichten over onvoldoende geheugen in het toepassingslogboek en frequente systeemcrashes.
De beste manieren om geheugengerelateerde knelpunten te voorkomen, zijn door een query-optimalisatieprogramma te gebruiken om onnodige of verouderde zoekopdrachten te verwijderen en om de levensduur van de pagina te configureren in combinatie met de buffer-cache-hitverhouding om trips naar de schijf te beperken. Als het te laat is om het knelpunt te vermijden, probeer dan query's te bekijken en af te stemmen, het geheugen opnieuw te configureren of fysiek geheugen toe te voegen.
Tellers om te controleren:beschikbaar geheugen, totaal servergeheugen, doelservergeheugen, pagina's/sec, buffercache-hitverhouding
I/O-knelpunten
Als er niet voldoende opslagruimte beschikbaar is om reguliere databasebewerkingen zoals TempDB te ondersteunen, zullen er waarschijnlijk I/O-knelpunten optreden. Lange responstijden, vertragingen van applicaties en frequente time-outs voor taken zijn allemaal belangrijke indicatoren dat u een I/O-knelpunt heeft.
U kunt dit type bottleneck voorkomen door monitoring in te stellen met alarmen en drempelwaarschuwingen om te identificeren welke activiteiten buitensporige hoeveelheden opslagruimte gebruiken. Als er een I/O-knelpunt optreedt, beperk dan het lezen en schrijven van databasepagina's van en naar de schijf. Dit vereist dat u frequente indexscans, inefficiënte zoekopdrachten en verouderde statistieken controleert en corrigeert.
Tellers om te controleren:gemiddelde schijfwachtrijlengte, gemiddelde schijfsec/lees, gemiddelde schijfsec/schrijftijd, % schijftijd, gemiddelde schijfleesbewerkingen/sec, gemiddelde schijfschrijfbewerkingen/sec
CPU-knelpunten
De belangrijkste oorzaak van CPU-knelpunten zijn onvoldoende hardwarebronnen. Het is vrij eenvoudig om dit knelpunt te identificeren door uw logboeken te controleren om te bepalen of SQL Server overmatige CPU gebruikt.
In een ideale wereld zou je CPU-knelpunten kunnen vermijden door een dedicated SQL Server-only server te hebben en alle andere software op een andere machine uit te voeren. Omdat dat voor de meeste DBA's geen optie is, moet u weten hoe u uw CPU kunt oplossen.
De eerste stap is het identificeren van de CPU-varkens. Als u eenmaal weet waar het probleem ligt, kunt u query's afstemmen, uw uitvoeringsplannen verbeteren of het systeem opnieuw configureren.
Tellers om te controleren:% processortijd, batchverzoeken/sec, SQL-compilaties/sec, SQL-hercompilaties/sec
Een verhaal over knelpunten in de prestaties van SQL Server
"We hebben wat knelpunten in de prestaties van SQL Server om op te lossen", zei mijn baas op een vrijdag laat.
"Hoe weet je dat?" Ik vroeg.
“Sales klaagt dat hun database de laatste tijd trager wordt. We moeten kijken wat ermee aan de hand is.'
"OKÉ. Ik zal een vergaderruimte boeken, zodat we kunnen gaan zitten en daaraan kunnen werken.'
'Doe geen moeite', zei de baas. “Het is laat op een vrijdagmiddag. Dat betekent dat we knelpunten het beste kunnen onderzoeken met een paar van ons. We gaan naar Pike Pub op de markt.'
We liepen de bar in die weggestopt was in Pike Place Market en vonden een tafeltje bij het raam.
"Wat is je favoriete bottleneck?" vroeg de baas.
Ik zei dat ik een voorliefde had voor een Naughty Nellie in de 22-ounce bottleneck.
"Goede keuze", zei de baas. "Als jij dat bestelt, heb ik de Citrus Summer Ale."
Terwijl we wachtten tot onze knelpunten arriveerden, gingen we aan de slag met de knelpunten in de prestaties van SQL Server.
"We zullen op verschillende plaatsen moeten controleren op problemen", zei de baas. "Het kunnen problemen zijn met geheugen, opslag of processors, maar ze zien er allemaal ongeveer hetzelfde uit voor gebruikers, toch? Slechte prestaties.
“CPU-problemen zijn niet zo moeilijk te vinden. Als dat het probleem is, zullen we zien dat SQL Server de processor overbelast en ervoor zorgt dat deze de hele tijd piekt.
“Als het een geheugenprobleem is, zullen we dingen zien zoals langere uitvoeringstijden op de queries en meer I/O omdat de applicatie steeds maar vol naar de schijf moet blijven lopen. We kunnen ook het applicatielogboek controleren op berichten met onvoldoende geheugen.
"En als de bottleneck in de opslag zit, zien we extreme activiteit op de schijven en lange wachttijden per I/O."
Onze knelpunten zijn gearriveerd. We hebben ze zorgvuldig bestudeerd terwijl we dieper ingingen op het prestatieprobleem.
De vele potentiële bronnen van knelpunten in de prestaties van SQL Server
"Wat als het een I/O-probleem is?" Ik vroeg. “We moeten kijken of de wachttijd voor WRITELOG te hoog is in vergelijking met de totale wachttijd. Of, over I/O gesproken, misschien is er een probleem in de SQL zelf. Als er inefficiënte code is, zoals een NESTED LOOP JOIN op een enorme tafel, kan de SQL ontelbare keren vragen om rijen in de binnenste tabel te lezen. Dat zou de prestaties echt afstraffen.”
'Zou kunnen', zei de baas. “Complexe joins en sorteerbewerkingen kunnen moeilijk zijn, vooral wanneer de tempdb-database niet correct is geconfigureerd. Tempdb-conflicten zien eruit als gewone databasevergrendelingen, maar het is eigenlijk een vergrendelde contentie vanwege gelijktijdige processen die allemaal op hun beurt wachten op de toewijzingspagina's."
“Welke tools kunnen we gebruiken om al deze dingen te onderzoeken?” Ik vroeg.
“SQL Server had een profiler voor het onderzoeken van opgeslagen procedures, maar die is verouderd. Zoiets is een goede manier om probleemvragen te vinden en te diagnosticeren, ook al is het maar de eerste stap. Dan zijn er dynamische beheerweergaven en -functies die u helpen de gezondheid van uw server en database te bewaken, problemen op te lossen en uw SQL af te stemmen.”
"Maar SQL Server heeft zoveel bewegende delen", zei ik. "Ik heb liever een tool die het hele plaatje van buiten naar binnen bekijkt."
"Ik ook. Bij voorkeur vanuit de cloud, zodat we niet meer hardware en software ter plaatse nodig hebben."
Verhelpen van prestatieknelpunten in SQL Server
Pike begon druk te worden. En hoe graag de baas en ik ook in een café zaten te praten, het was tenslotte vrijdagavond. We hadden andere plaatsen om naartoe te gaan, andere mensen om te zien en andere dingen om over te praten.
“Wat moeten we doen als we de knelpunten hebben gevonden?” Ik vroeg.
'We pakken de gebruikelijke verdachten op', zei de baas. "Om te voorkomen dat we te veel geheugen gebruiken, moeten we de databaseontwikkelaars vertellen welke van hun code en query's geheugen lekken. Als we bewerkingen vinden die vier, vijf of zes tabellen samenvoegen, moeten we de ontwikkelaars enkele SQL Server-afstemmingstips en best practices geven om de database opnieuw te ontwerpen. Of misschien hebben we te veel indexen en verspillen we cycli door ze bij te werken; dat is net zo zwaar voor de CPU en I/O als het hebben van te weinig indexen. We hebben mogelijk een probleem met de fragmentatie van de SQL Server-index, of we moeten de verouderde en gedupliceerde indexen verwijderen."
'Begrijpelijk,' zei ik. “Misschien moeten we er meer hardware tegenaan gooien. Snellere schijven kunnen helpen bij I/O-knelpunten. Meer en snellere CPU's maken een verschil in de responstijden van query's. En het toevoegen van RAM betekent meer schaalbaarheid van SQL Server, toch?”
"Ja", zei de baas, "maar eerst wil ik zeker weten dat de oorzaak geen ontwikkelings- of DevOps-probleem is. Zodra ik ervan overtuigd ben dat dat niet zo is, speel ik de Buy More Hardware-kaart.”
We bleven even zitten en keken hoe de kroeg volliep met feestvierders op vrijdagavond.
"Baas," vroeg ik, "denk je dat al deze mensen weten hoe zorgeloos een bestaan ze allemaal leiden, zonder de last van het omgaan met geblokkeerde sessies, maximale I/O-wachttijd, pagina-levensverwachting en buffer-cache hit ratio's?"
"Het is een kruis om te dragen, nietwaar?" antwoordde de baas. “De meeste mensen hebben geen idee wat we doormaken. Het is maar goed dat we de knelpunten in de prestaties van SQL Server zo stil, met zoveel gratie onder druk en met zo'n goede smaak aanpakken. Over goede smaak gesproken, hoe gaat het met je bottleneck?”
Ik controleerde. “Mijn bottleneck is leeg. Mijn fles ook."
"Ook van mij. Tijd om te gaan. We hebben werk te doen.”
Is een nul SQL Server-knelpuntsysteem mogelijk?
We weten dat er stappen zijn die we kunnen nemen om deze drie veelvoorkomende typen SQL Server-knelpunten te vermijden. Maar is het mogelijk om een SQL Server-database zo goed te configureren dat er geen knelpunten zijn?
Het korte antwoord is waarschijnlijk niet. Zelfs de meest ijverige DBA zal zo nu en dan SQL Server-knelpunten hebben. Maar u kunt wel stappen ondernemen om knelpunten proactief te voorkomen en hun impact op de prestaties te minimaliseren. Brent Ozar biedt bijvoorbeeld enkele geweldige tips voor het bewaken van Perfmon-tellers om uw SQL Server af te stemmen, en u kunt de weergave sys.dm_os_performance_counters gebruiken om knelpunten te identificeren en deze snel te corrigeren.
SQL Server-knelpunten zijn een feit van het leven van DBA. Gelukkig kunnen prestatieproblemen met adequaat toezicht, zorgvuldige monitoring en frequente afstemming van zoekopdrachten worden opgelost voordat gebruikers zelfs maar weten dat er een probleem is.