Att vara databasadministratör kan vara mycket utmanande ibland när du måste felsöka prestandaproblem. Databasservern är bara en komponent i applikationens ekosystem och den får rutinmässigt skulden för att vara prestandaproblemet. SQL Server är en av de svarta rutorna som många inte förstår, ungefär som SAN och nätverk. Produktions-DBA:er som övervakar sina servrar kan snabbt identifiera om SQL Server fungerar utanför sin normala baslinje, men det finns två huvudområden som vi har liten insyn i:SAN och nätverket. DBA:er måste regelbundet arbeta med andra ingenjörer när det gäller att felsöka prestandaproblem som inte är direkt relaterade till SQL Server. Vi kan enkelt spåra diskprestanda genom att övervaka sys.dm_io_virtual_file_stats , som jag skrev om i Monitoring Read/Write Latency; Det är dock inte lika lätt att spåra nätverksprestandaproblem inom SQL Server.
Dålig nätverksprestanda kan vara en tyst mördare för applikationsprestanda och min personliga erfarenhet har visat att så är fallet vid många tillfällen. Ofta skulle en applikation börja ha prestandaproblem och applikationsingenjören skulle säga att applikationsservern ser bra ut och börjar peka med fingret på databasen. Jag skulle få ett samtal för att titta på databasservern och alla indikationer visade att databasservern var i god hälsa (och det är här övervakning av nyckelprestandaindikatorer och att ha en baslinje hjälper!). Eftersom applikations- och databasteamen sa att allt var bra, skulle vi be nätverksteamet att kolla upp saker och ting. Nätverksteamet skulle titta på några saker och ge allt klart på sin sida också. Varje team att felsöka och granska sina respektive system tog tid, samtidigt som applikationens prestanda fortfarande var dålig. Frågan skulle sedan eskaleras tills alla team skulle bli ombedda att gå med i en konferensbrygga för att felsöka tillsammans. Så småningom skulle någon starta ett djupare nätverkstest och fastställa att vi antingen hade en portmättnad, routing eller något annat komplext nätverksproblem. Ett par klick eller att ändra något på deras sida skulle så småningom lösa programmets långsamhet.
Det viktigaste nätverksproblemet som jag har stött på med klienter involverar vanligtvis bandbredd vid säkerhetskopiering. Många större organisationer migrerar till 10Gb-nätverk för kärninfrastruktur, men när man arbetar med både fysiska och virtuella nätverk är det lätt att felkonfigurera en inställning eller port och få den att sjunka till 1Gb. För vanlig applikationsnätverkstrafik kanske du inte märker försämringen i prestanda, men så fort du börjar försöka kopiera 100-tals GB data för säkerhetskopiering kommer den 1 Gb att bli mättad och dina säkerhetskopierings- och återställningsjobb kommer att lida.
För DBA:er kan det vara utmanande att få andra att titta så djupt in i problem som de inte tror är deras problem eftersom initiala indikatorer inte avslöjar problemet. Att kunna beväpna dig med data innan du når ut till andra team kommer att hjälpa dem att engagera sig. Genom att använda iPerf för att göra ett första bandbreddstest kan du snabbt avgöra om du får de nätverkshastigheter som du ska. Om du till exempel använder 10 Gb-nätverk mellan applikationsservern och databasservern och du kör ett test och bara får 1 Gb, så vet du att något inte stämmer. Om du kan dokumentera denna upptäckt kan du med förtroende be dina nätverksingenjörer att undersöka ett bandbreddsproblem.
Hur kommer du igång med iPerf? Först måste du ladda ner verktyget från iPerf.fr. Eftersom jag arbetar på Windows Server 2012 har jag laddat ner Windows-binärfilerna till min dator. När du har laddat ner och packat upp paketet måste du köra programmet från en kommandorad. Jag laddade ner iPerf 3.0.11 som har varit ute i nästan ett år. Se till att läsa dokumentationen för detta verktyg. Eftersom detta är ett kommandoradsverktyg finns det dussintals alternativ som du kan använda. I exemplet nedan kommer jag bara att använda ett fåtal av dem, men beroende på din situation kan du behöva använda andra alternativ som att ange porten eller öka paketstorleken. Observera att alternativkommandona är skiftlägeskänsliga.
För att använda iPerf måste du använda minst två servrar för att testa bandbredden. När du har kopierat binärfilerna till de två servrarna måste du först starta iPerf-lyssnaren på en av servrarna. För att göra detta kör jag följande kommando:
iperf3 -sDetta kommando kör iPerf i serverläge och tillåter endast en anslutning åt gången.
På den andra servern måste du starta iPerf med flera klientalternativ. Först kommer vi att specificera -c för att specificera klientläge. Vi kommer också att använda -t för att ange tiden för att köra varje test och -P för att ange antalet samtidiga anslutningar som ska göras. Vi vill specificera flera anslutningar så att vi kan belasta nätverket ordentligt. För detta test kommer jag att köra följande kommando:
iperf3 -c (servernamn eller ip-adress för den första servern) -t 30 -P 10Kommandot ovan startar ett 30 sekunders överföringstest med 10 samtidiga anslutningar.
Jag körde det här testet på två virtuella maskiner på min Dell M6800 så det fanns inget fysiskt nätverk för dessa virtuella datorer att gå igenom.
Från server 2 som ansluter till server 1 fick jag 7,57 GByte överförda med en bandbredd på 2,17 Gbits/sek. Inte illa för ett par virtuella datorer på en bärbar dator.
Nätverksstatistik / iPerf-utgång:Server 2 ansluter till Server 1
Från server 1 som ansluter till server 2 fick jag 6,98 GByte överförda med en bandbredd på 2,00 Gbits/sek. Som du kan se är det en liten skillnad i siffrorna men ändå relativt nära. Hade dessa siffror varit drastiskt annorlunda skulle jag behöva undersöka orsaken.
Nätverksstatistik / iPerf-utgång:Server 1 ansluter till Server 2
Det är viktigt att köra dessa tester innan du går i produktion och att ta för vana att regelbundet upprepa dessa tester på dina produktionsservrar. Du måste veta vad som är normalt, om du inte övervakar det kan du inte mäta det. Om du vet att firmwareuppdateringar utförs på dina servrar, den virtuella värden eller någon kärnnätverksutrustning, kan ett iPerf-test före och efter ändringarna snabbt varna dig för att identifiera eventuella negativa biverkningar.
Det är också viktigt att utföra detta test mot alla servrar som har ett direkt gränssnitt mot databasservern och alla servrar som databasservern har direkt gränssnitt med, såsom enheter för säkerhetskopiering av nätverk. IPerf fungerar på både Windows och Linux vilket gör det enkelt att testa mellan de två operativsystemen.
För DBA:er behöver nätverket inte längre vara en svart låda som du inte vet något om. Att använda iPerf kan varna dig för eventuella bandbreddsproblem med nätverket mellan din databasserver och vilken annan server som helst. Det finns ingen anledning att bara lita på PING och TRACERT för begränsad nätverksfelsökning. Ladda ner iPerf och börja dokumentera din nätverksbandbredd.