Essere un amministratore di database può essere molto impegnativo a volte in cui devi risolvere i problemi di prestazioni. Il server di database è solo un componente dell'ecosistema delle applicazioni e viene regolarmente accusato di essere il problema delle prestazioni. SQL Server è una di quelle scatole nere che molti non capiscono, proprio come la SAN e la rete. I DBA di produzione che monitorano i propri server possono identificare rapidamente se SQL Server sta eseguendo prestazioni al di fuori della normale linea di base, tuttavia ci sono due aree principali su cui abbiamo poca visibilità:la SAN e la rete. I DBA devono collaborare regolarmente con altri ingegneri quando si tratta di risolvere problemi di prestazioni che non sono direttamente correlati a SQL Server. Possiamo facilmente monitorare le prestazioni del disco monitorando sys.dm_io_virtual_file_stats , di cui ho parlato in Monitoraggio della latenza di lettura/scrittura; tuttavia, tenere traccia dei problemi di prestazioni della rete all'interno di SQL Server non è così facile.
Le scarse prestazioni di rete possono essere un killer silenzioso per le prestazioni delle applicazioni e la mia esperienza personale ha dimostrato che è così in molte occasioni. Spesso un'applicazione inizia ad avere problemi di prestazioni e l'ingegnere dell'applicazione afferma che il server delle applicazioni ha un bell'aspetto e inizia a puntare il dito contro il database. Ricevevo una chiamata per esaminare il server del database e tutte le indicazioni mostravano che il server del database era in buone condizioni (ed è qui che il monitoraggio degli indicatori chiave delle prestazioni e la disponibilità di una linea di base aiuta!). Poiché i team dell'applicazione e del database dicevano che tutto andava bene, avremmo chiesto al team di rete di controllare le cose. Il team di rete guarderebbe ad alcune cose e darebbe il via libera anche dalla loro parte. Ogni team per la risoluzione dei problemi e la revisione dei rispettivi sistemi ha richiesto tempo, mentre le prestazioni dell'applicazione continuavano a soffrire. Il problema sarebbe quindi intensificato fino a quando a tutti i team non sarebbe stato chiesto di unirsi a un bridge di conferenza per risolvere insieme i problemi. Alla fine qualcuno avrebbe avviato un test di rete più approfondito e determinato che abbiamo avuto una saturazione della porta, un routing o qualche altro problema di rete complesso. Pochi clic o modifiche da parte loro alla fine risolverebbero la lentezza dell'applicazione.
Il problema di rete più significativo che ho riscontrato con i client in genere riguarda la larghezza di banda durante l'esecuzione dei backup. Molte organizzazioni più grandi stanno migrando a reti da 10 Gb per l'infrastruttura principale, tuttavia quando si lavora con reti fisiche e virtuali, è facile configurare erroneamente un'impostazione o una porta e farla scendere a 1 Gb. Per il normale traffico di rete delle applicazioni potresti non notare il degrado delle prestazioni, tuttavia non appena inizi a provare a copiare 100 GB di dati per i backup, quel 1Gb diventerà saturo e i tuoi processi di backup e ripristino ne risentiranno.
Per i DBA può essere difficile convincere gli altri a guardare così in profondità i problemi che non pensano siano il loro problema perché gli indicatori iniziali non rivelano il problema. Essere in grado di armarsi di dati prima di contattare altri team aiuterà a coinvolgerli. Utilizzando iPerf per eseguire un test di larghezza di banda iniziale, puoi determinare rapidamente se stai ottenendo le velocità di rete che dovresti. Ad esempio, se stai utilizzando una rete da 10 Gb tra il server delle applicazioni e il server del database ed esegui un test e ottieni solo 1 Gb, allora sai che qualcosa non va. Se riesci a documentare questa scoperta, puoi tranquillamente chiedere ai tuoi tecnici di rete di esaminare un problema di larghezza di banda.
Come si inizia a utilizzare iPerf? Per prima cosa devi scaricare lo strumento da iPerf.fr. Dato che sto lavorando su Windows Server 2012, ho scaricato i binari di Windows sul mio computer. Dopo aver scaricato e decompresso il pacchetto, dovrai eseguire il programma da una riga di comando. Ho scaricato iPerf 3.0.11 che è uscito da quasi un anno. Assicurati di leggere la documentazione di questa utilità. Poiché questo è uno strumento da riga di comando, ci sono dozzine di opzioni che puoi utilizzare. Nell'esempio seguente ne utilizzerò solo alcuni, tuttavia, a seconda della situazione, potrebbe essere necessario utilizzare altre opzioni come specificare la porta o aumentare la dimensione del pacchetto. Tieni presente che i comandi delle opzioni fanno distinzione tra maiuscole e minuscole.
Per utilizzare iPerf, devi utilizzare almeno due server per testare la larghezza di banda. Dopo aver copiato i binari sui due server, devi prima avviare il listener iPerf su uno dei server. Per fare ciò eseguirò il seguente comando:
iperf3 -sQuesto comando esegue iPerf in modalità server e consentirà solo una connessione alla volta.
Sul secondo server dovrai avviare iPerf utilizzando diverse opzioni client. Per prima cosa specificheremo -c per specificare la modalità client. Useremo anche -t per specificare il tempo di esecuzione di ogni test e -P per specificare il numero di connessioni simultanee da effettuare. Vogliamo specificare più connessioni in modo da poter mettere a dura prova la rete. Per questo test eseguirò il seguente comando:
iperf3 -c (nome server o indirizzo ip del primo server) -t 30 -P 10Il comando precedente avvierà un test di trasmissione di 30 secondi con 10 connessioni simultanee.
Ho eseguito questo test su due macchine virtuali sul mio Dell M6800 quindi non c'era una rete fisica per queste VM da attraversare.
Dal server 2 che si collega al server 1 ho ricevuto 7,57 GByte trasferiti con una larghezza di banda di 2,17 Gbit/sec. Non male per un paio di macchine virtuali su un laptop.
Statistiche di rete / Output iPerf:Server 2 connesso al Server 1
Dal server 1 che si collega al server 2 ho ricevuto 6,98 GByte trasferiti con una larghezza di banda di 2,00 Gbit/sec. Come puoi vedere c'è una leggera differenza nei numeri ma ancora relativamente vicino. Se questi numeri fossero stati drasticamente diversi, avrei bisogno di indagare sulla causa.
Statistiche di rete / Output iPerf:Server 1 connesso al Server 2
È importante eseguire questi test prima di entrare in produzione e prendere l'abitudine di ripetere regolarmente questi test sui server di produzione. Devi sapere cosa è normale, se non lo stai monitorando, non puoi misurarlo. Se sai che gli aggiornamenti del firmware vengono eseguiti sui tuoi server, sull'host virtuale o su qualsiasi apparecchiatura di rete principale, un test iPerf prima e dopo le modifiche potrebbe avvisarti rapidamente per identificare eventuali effetti collaterali negativi.
È anche importante eseguire questo test su tutti i server che si interfacciano direttamente con il server di database e su tutti i server con cui il server di database si interfaccia direttamente, ad esempio i dispositivi di backup di rete. IPerf funziona sia su Windows che su Linux, semplificando il test tra i due sistemi operativi.
Per i DBA, la rete non deve più essere una scatola nera di cui non sai nulla. L'uso di iPerf può avvisarti di eventuali problemi di larghezza di banda con la rete tra il server del database e qualsiasi altro server. Non c'è motivo di fare affidamento solo su PING e TRACERT per la risoluzione dei problemi di rete limitata. Scarica iPerf e inizia a documentare la larghezza di banda della tua rete.
