SQL Server offre due metodi per raccogliere dati di diagnostica e risoluzione dei problemi relativi al carico di lavoro eseguito sul server:traccia SQL ed eventi estesi. A partire da SQL Server 2012, l'implementazione di eventi estesi offre funzionalità di raccolta dati comparabili a SQL Trace e può essere usata per confrontare l'overhead sostenuto da queste due funzionalità. In questo articolo esamineremo il confronto dell'"overhead dell'osservatore" che si verifica quando si utilizza SQL Trace ed eventi estesi in varie configurazioni per determinare l'impatto sulle prestazioni che la raccolta dei dati può avere sul nostro carico di lavoro tramite l'uso di un carico di lavoro di riproduzione acquisizione e riproduzione distribuita.
L'ambiente di prova
L'ambiente di test è composto da sei macchine virtuali, un controller di dominio, un server SQL Server 2012 Enterprise Edition e quattro server client su cui è installato il servizio client Distributed Replay. Per questo articolo sono state testate diverse configurazioni host e risultati simili sono stati ottenuti dalle tre diverse configurazioni testate in base al rapporto di impatto. Il server SQL Server Enterprise Edition è configurato con 4 vCPU e 4 GB di RAM. I restanti cinque server sono configurati con 1 vCPU e 1 GB di RAM. Il servizio controller di riproduzione distribuita è stato eseguito sul server SQL Server 2012 Enterprise Edition perché richiede una licenza Enterprise per utilizzare più client per la riproduzione.
Test del carico di lavoro
Il carico di lavoro di prova utilizzato per l'acquisizione della riproduzione è il carico di lavoro della documentazione in linea AdventureWorks che ho creato l'anno scorso per generare carichi di lavoro fittizi su SQL Server. Questo carico di lavoro usa le query di esempio della documentazione in linea sulla famiglia di database AdventureWorks ed è guidato da PowerShell. Il carico di lavoro è stato impostato su ciascuno dei quattro client di riproduzione ed eseguito con quattro connessioni totali a SQL Server da ciascuno dei server client per generare un'acquisizione della traccia di riproduzione da 1 GB. La traccia di riproduzione è stata creata utilizzando il modello TSQL_Replay di SQL Server Profiler, esportata in uno script e configurata come traccia lato server in un file. Una volta che il file di traccia della riproduzione è stato acquisito, è stato preelaborato per l'uso con Distributed Replay, quindi i dati della riproduzione sono stati utilizzati come carico di lavoro della riproduzione per tutti i test.
Configurazione di riproduzione
L'operazione di riproduzione è stata configurata per utilizzare la configurazione della modalità di stress per guidare la quantità massima di carico rispetto all'istanza di test di SQL Server. Inoltre, la configurazione utilizza una scala temporale di Think and Connect ridotta, che regola il rapporto di tempo tra l'inizio della traccia di riproduzione e quando un evento si è effettivamente verificato fino a quando viene riprodotto durante l'operazione di riproduzione, per consentire la riproduzione degli eventi a scala massima. Anche la scala dello stress per la riproduzione è configurata per spid. I dettagli del file di configurazione per l'operazione di riproduzione erano i seguenti:
<?xml version="1.0" encoding="utf-8"?>
<Options>
<ReplayOptions>
<Server>SQL2K12-SVR1</Server>
<SequencingMode>stress</SequencingMode>
<ConnectTimeScale>1</ConnectTimeScale>
<ThinkTimeScale>1</ThinkTimeScale>
<HealthmonInterval>60</HealthmonInterval>
<QueryTimeout>3600</QueryTimeout>
<ThreadsPerClient>255</ThreadsPerClient>
<EnableConnectionPooling>Yes</EnableConnectionPooling>
<StressScaleGranularity>spid</StressScaleGranularity>
</ReplayOptions>
<OutputOptions>
<ResultTrace>
<RecordRowCount>No</RecordRowCount>
<RecordResultSet>No</RecordResultSet>
</ResultTrace>
</OutputOptions>
</Options> Durante ciascuna delle operazioni di riproduzione, i contatori delle prestazioni sono stati raccolti a intervalli di cinque secondi per i seguenti contatori:
- Processore\% Tempo di elaborazione\_Totale
- SQL Server\SQL Statistics\Richieste batch/sec
Questi contatori verranno utilizzati per misurare il carico complessivo del server e le caratteristiche di throughput di ciascuno dei test per il confronto.
Configurazioni di prova
Un totale di sette diverse configurazioni sono state testate con Distributed Replay:
- Linea di base
- Traccia lato server
- Profiler sul server
- Profiler da remoto
- Eventi estesi a event_file
- Eventi estesi a ring_buffer
- Eventi estesi a event_stream
Ciascun test è stato ripetuto tre volte per garantire che i risultati fossero coerenti tra i diversi test e per fornire una serie media di risultati per il confronto. Per i test di base iniziali, non è stata configurata alcuna raccolta di dati aggiuntiva per l'istanza di SQL Server, ma le raccolte di dati predefinite fornite con SQL Server 2012 sono state lasciate abilitate:la traccia predefinita e la sessione dell'evento system_health. Ciò riflette la configurazione generale della maggior parte dei server SQL, poiché in genere non è consigliabile disabilitare la sessione predefinita di trace o system_health a causa dei vantaggi che offrono agli amministratori di database. Questo test è stato utilizzato per determinare la linea di base complessiva per il confronto con i test in cui veniva eseguita la raccolta di dati aggiuntivi. I test rimanenti si basano sul modello TSQL_SPs fornito con SQL Server Profiler e raccoglie i seguenti eventi:
- Controllo di sicurezza\Accesso al controllo
- Audit di sicurezza\Esci dall'audit
- Sessioni\Connessione esistente
- Procedure memorizzate\RPC:avvio
- Procedure memorizzate\SP:Completato
- Stored procedure\SP:Inizio
- Procedure memorizzate\SP:StmtStarting
- TSQL\SQL:BatchStarting
Questo modello è stato selezionato in base al carico di lavoro utilizzato per i test, che è principalmente batch SQL acquisiti da SQL:BatchStarting event, quindi un numero di eventi utilizzando i vari metodi di hierarchyid , che vengono acquisiti da SP:Starting , SP:StmtStarting e SP:Completed eventi. Uno script di traccia lato server è stato generato dal modello utilizzando la funzionalità di esportazione in SQL Server Profiler e le uniche modifiche apportate allo script sono state l'impostazione di maxfilesize parametro a 500 MB, abilitare il rollover del file di traccia e fornire un nome file in cui è stata scritta la traccia.
Il terzo e il quarto test hanno utilizzato SQL Server Profiler per raccogliere gli stessi eventi della traccia lato server per misurare il sovraccarico delle prestazioni della traccia tramite l'applicazione Profiler. Questi test sono stati eseguiti utilizzando SQL Profiler in locale su SQL Server e in remoto da un client separato per accertare se c'era una differenza di sovraccarico dovuto all'esecuzione di Profiler in locale o in remoto.
I test finali utilizzati Extended Events hanno raccolto gli stessi eventi e le stesse colonne in base a una sessione di eventi creata utilizzando lo script di conversione Trace to Extended Events per SQL Server 2012. I test includevano la valutazione di event_file, ring_buffer e il nuovo provider di streaming in SQL ServerSQL Server 2012 separatamente per determinare l'overhead che ciascuna destinazione potrebbe imporre alle prestazioni del server. Inoltre, la sessione dell'evento è stata configurata con le opzioni predefinite del buffer di memoria, ma è stata modificata per specificare NO_EVENT_LOSS per il EVENT_RETENTION_MODE opzione per i test event_file e ring_buffer per abbinare il comportamento di Trace lato server a un file, che garantisce anche l'assenza di perdite di eventi.
Risultati
Con un'eccezione, i risultati dei test non sono stati sorprendenti. Il test di base è stato in grado di eseguire il carico di lavoro di riproduzione in tredici minuti e trentacinque secondi e ha registrato una media di 2345 richieste batch al secondo durante i test. Con la traccia lato server in esecuzione, l'operazione di riproduzione è stata completata in 16 minuti e 40 secondi, con un degrado delle prestazioni del 18,1%. Profiler Traces ha avuto le prestazioni peggiori in assoluto e ha richiesto 149 minuti quando Profiler veniva eseguito localmente sul server e 123 minuti e 20 secondi quando Profiler veniva eseguito in remoto, ottenendo rispettivamente il 90,8% e l'87,6% di degrado delle prestazioni. I test degli eventi estesi sono stati i migliori risultati, impiegando 15 minuti e 15 secondi per event_file e 15 minuti e 40 secondi per il target ring_buffer, con un conseguente degrado delle prestazioni del 10,4% e dell'11,6%. I risultati medi per tutti i test sono visualizzati nella Tabella 1 e riportati nella Figura 2:
Tabella 1 – Risultati medi di tutti i test
Figura 2 – Grafico dei risultati
Il test di streaming degli eventi estesi non è un risultato del tutto equo nel contesto dei test eseguiti e richiede un po' più di spiegazione per comprendere il risultato. Dai risultati della tabella possiamo vedere che i test di streaming per gli eventi estesi sono stati completati in sedici minuti e trentacinque secondi, pari a un degrado delle prestazioni del 34,1%. Tuttavia, se ingrandiamo il grafico e ne modifichiamo la scala, come mostrato nella Figura 3, vedremo che lo streaming ha avuto un impatto molto maggiore sulle prestazioni inizialmente e poi ha iniziato a funzionare in modo simile agli altri test di eventi estesi :
Figura 3 – Risultati ingranditi
La spiegazione di ciò si trova nella progettazione della nuova destinazione di streaming di eventi estesi in SQL Server 2012. Se i buffer di memoria interna per event_stream si riempiono e non vengono consumati dall'applicazione client abbastanza velocemente, Motore di database forzerà una disconnessione di event_stream per evitare un grave impatto sulle prestazioni del server. Ciò comporta la generazione di un errore in SQL Server 2012 Management Studio simile all'errore nella Figura 4:
Figura 4 – event_stream disconnesso dal server
(Microsoft.SqlServer.XEvent.Linq)
Errore 25726, gravità 17, stato 0 generato, ma non è stato trovato alcun messaggio con quel numero di errore in sys.messages. Se l'errore è maggiore di 50000, assicurati che il messaggio definito dall'utente venga aggiunto utilizzando sp_addmessage.
(Microsoft SQL Server, Error:18054)
Conclusioni
Tutti i metodi di raccolta dei dati di diagnostica da SQL Server sono associati a "overhead dell'osservatore" e possono influire sulle prestazioni di un carico di lavoro in condizioni di carico elevato. Per i sistemi in esecuzione su SQL Server 2012, gli eventi estesi forniscono la quantità minima di sovraccarico e forniscono funzionalità simili per eventi e colonne come SQL Trace (alcuni eventi in SQL Trace vengono raggruppati in altri eventi in Extended Events). Se la traccia SQL è necessaria per acquisire i dati degli eventi, il che potrebbe essere il caso fino a quando gli strumenti di terze parti non vengono ricodificati per sfruttare i dati degli eventi estesi, una traccia lato server su un file produrrà il minor sovraccarico di prestazioni. SQL Server Profiler è uno strumento da evitare sui server di produzione occupati, come dimostrato dall'aumento di dieci volte della durata e dalla significativa riduzione del throughput per la riproduzione.
Sebbene i risultati sembrerebbero favorire l'esecuzione remota di SQL Server Profiler quando è necessario utilizzare Profiler, questa conclusione non può essere tratta in modo definitivo in base ai test specifici eseguiti in questo scenario. È necessario eseguire ulteriori test e raccolta di dati per determinare se i risultati di Profiler remoto sono il risultato di un cambio di contesto inferiore nell'istanza di SQL Server o se la rete tra macchine virtuali ha giocato un fattore nel minor impatto sulle prestazioni della raccolta remota. Il punto in questi test era mostrare l'overhead significativo che comporta Profiler, indipendentemente da dove veniva eseguito Profiler. Infine, anche il flusso di eventi live in Eventi estesi ha un sovraccarico elevato quando è effettivamente connesso alla raccolta dei dati, ma come mostrato nei test, Motore di database disconnetterà un flusso live se rimane indietro rispetto agli eventi per evitare un grave impatto prestazioni del server.
