Det kan være meget udfordrende at være databaseadministrator på tidspunkter, hvor du skal fejlfinde problemer med ydeevnen. Databaseserveren er kun en komponent i applikationens økosystem, og den får rutinemæssigt skylden for at være ydelsesproblemet. SQL Server er en af de sorte bokse, som mange ikke forstår, ligesom SAN og netværk. Produktions-DBA'er, der overvåger deres servere, kan hurtigt identificere, om SQL Server yder uden for sin normale baseline, men der er to hovedområder, som vi har lidt synlighed i:SAN og netværket. DBA'er skal jævnligt samarbejde med andre ingeniører, når det kommer til fejlfinding af ydeevneproblemer, der ikke er direkte relateret til SQL Server. Vi kan nemt spore diskens ydeevne ved at overvåge sys.dm_io_virtual_file_stats , som jeg skrev om i Overvågning af læse-/skriveforsinkelse; Det er dog ikke så nemt at spore problemer med netværkets ydeevne i SQL Server.
Dårlig netværksydelse kan være en tavs dræber for applikationsydelse, og min personlige erfaring har vist, at dette er tilfældet ved mange lejligheder. Ofte ville en applikation begynde at have problemer med ydeevnen, og applikationsingeniøren ville sige, at applikationsserveren ser godt ud og begynder at pege fingeren på databasen. Jeg ville blive ringet op for at se på databaseserveren, og alle indikationer viste, at databaseserveren var ved godt helbred (og det er her, overvågning for nøglepræstationsindikatorer og at have en baseline hjælper!). Da applikations- og databaseteamene sagde, at alt var godt, ville vi bede netværksteamet om at tjekke tingene ud. Netværksteamet ville se på et par ting og give det hele klart på deres side også. Hvert teams fejlfinding og gennemgang af deres respektive systemer tog tid, mens applikationens ydeevne stadig led. Problemet ville derefter blive eskaleret, indtil alle holdene ville blive bedt om at slutte sig til en konferencebro for at fejlfinde sammen. Til sidst ville nogen starte en dybere netværkstest og fastslå, at vi enten havde en portmætning, routing eller et andet komplekst netværksproblem. Et par klik eller ændring af noget i deres ende ville i sidste ende løse programmets langsommelighed.
Det vigtigste netværksproblem, som jeg er stødt på med klienter, involverer typisk båndbredde, når jeg udfører sikkerhedskopier. Mange større organisationer migrerer til 10 Gb netværk til kerneinfrastruktur, men når du arbejder med både fysisk og virtuelt netværk, er det let at fejlkonfigurere en indstilling eller port og få den til at falde til 1 Gb. For almindelig applikationsnetværkstrafik vil du muligvis ikke bemærke forringelsen af ydeevnen, men så snart du begynder at prøve at kopiere 100'er af GB data til sikkerhedskopiering, vil den 1 Gb blive mættet, og dine backup- og gendannelsesjob vil lide.
For DBA'er kan det være udfordrende at få andre til at se så dybt ind i problemer, som de ikke tror er deres problem, fordi indledende indikatorer ikke afslører problemet. At være i stand til at bevæbne dig med data, før du når ud til andre teams, vil hjælpe med at få dem involveret. Ved at bruge iPerf til at lave en indledende båndbreddetest, kan du hurtigt afgøre, om du får de netværkshastigheder, du skal. For eksempel, hvis du bruger 10 Gb netværk mellem applikationsserveren og databaseserveren, og du kører en test og kun får 1 Gb, så ved du, at noget ikke er helt rigtigt. Hvis du kan dokumentere denne opdagelse, kan du med tillid bede dine netværksingeniører om at undersøge et båndbreddeproblem.
Hvordan kommer du i gang med at bruge iPerf? Først skal du downloade værktøjet fra iPerf.fr. Siden jeg arbejder på Windows Server 2012, har jeg downloadet Windows-binære filer til min maskine. Når du har downloadet og pakket pakken ud, skal du køre programmet fra en kommandolinje. Jeg downloadede iPerf 3.0.11, som har været ude i næsten et år. Sørg for at læse dokumentationen til dette hjælpeprogram. Da dette er et kommandolinjeværktøj, er der snesevis af muligheder, som du kan bruge. I eksemplet nedenfor vil jeg kun bruge nogle få af dem, men afhængigt af din situation skal du muligvis bruge andre muligheder, såsom at angive porten eller øge pakkestørrelsen. Bemærk venligst, at indstillingskommandoerne skelner mellem store og små bogstaver.
For at bruge iPerf skal du bruge mindst to servere til at teste båndbredden. Når du har kopieret binære filer til de to servere, skal du først starte iPerf-lytteren på en af serverne. For at gøre dette vil jeg køre følgende kommando:
iperf3 -sDenne kommando kører iPerf i servertilstand og tillader kun én forbindelse ad gangen.
På den anden server skal du starte iPerf ved hjælp af flere klientindstillinger. Først skal vi specificere -c for at angive klienttilstand. Vi vil også bruge -t til at angive tidspunktet for at køre hver test og -P til at angive antallet af samtidige forbindelser, der skal laves. Vi ønsker at specificere flere forbindelser, så vi kan belaste netværket ordentligt. Til denne test skal jeg køre følgende kommando:
iperf3 -c (servernavn eller ip-adresse på den første server) -t 30 -P 10Kommandoen ovenfor starter en 30 sekunders transmissionstest med 10 samtidige forbindelser.
Jeg kørte denne test på to virtuelle maskiner på min Dell M6800, så der var ikke et fysisk netværk for disse VM'er at gå igennem.
Fra server 2, der forbinder til server 1, fik jeg overført 7,57 GBytes med en båndbredde på 2,17 Gbits/sek. Ikke dårligt for et par VM'er på en bærbar computer.
Netværksstatistik / iPerf-output:Server 2 opretter forbindelse til server 1
Fra server 1, der forbinder til server 2, fik jeg overført 6,98 GBytes med en båndbredde på 2,00 Gbits/sek. Som du kan se er der en lille forskel i tallene, men stadig relativt tæt på. Hvis disse tal havde været drastisk anderledes, ville jeg være nødt til at undersøge årsagen.
Netværksstatistik / iPerf-output:Server 1 opretter forbindelse til Server 2
Det er vigtigt at køre disse tests, før de går i produktion, og at gøre det til en vane regelmæssigt at gentage disse test på dine produktionsservere. Du skal vide, hvad der er normalt, hvis du ikke overvåger det, så kan du ikke måle det. Hvis du ved, at firmwareopdateringer udføres på dine servere, den virtuelle vært eller ethvert kernenetværksudstyr, kan en iPerf-test før og efter ændringerne hurtigt gøre dig opmærksom på eventuelle negative bivirkninger.
Det er også vigtigt at udføre denne test mod alle servere, der har direkte grænseflader med databaseserveren og alle servere, som databaseserveren har direkte grænseflader med, såsom netværkssikkerhedskopieringsenheder. IPerf virker på både Windows og Linux, hvilket gør det nemt at teste mellem de to operativsystemer.
For DBA'er behøver netværket ikke længere være en sort boks, som du ikke ved noget om. Brug af iPerf kan advare dig om eventuelle båndbreddeproblemer med netværket mellem din databaseserver og enhver anden server. Der er ingen grund til kun at stole på PING og TRACERT til begrænset netværksfejlfinding. Download iPerf og begynd at dokumentere din netværksbåndbredde.