Strano problema di prestazioni con SQL Server 2016


14

Abbiamo una singola istanza di SQL Server 2016 SP1 in esecuzione in una macchina virtuale VMware. Contiene 4 database, ciascuno per un'applicazione diversa. Quelle applicazioni sono tutte su server virtuali separati. Nessuno di loro è ancora in produzione. Tuttavia, le persone che testano le applicazioni segnalano problemi di prestazioni.

Queste sono le statistiche del server:

  • 128 GB RAM (110 GB di memoria massima per SQL Server)
  • 4 core a 4.6 GHz
  • Connessione di rete da 10 GBit
  • Tutta la memoria è basata su SSD
  • File di programma, file di registro, file di database e tempdb si trovano su partizioni separate del server
  • asd

Gli utenti eseguono l'accesso a schermo singolo tramite un'applicazione ERP basata su C ++.

Quando eseguo lo stress test di SQL Server con Microsoft ostressutilizzando molte piccole query o una query grande, ottengo le massime prestazioni. L'unica cosa che limita è il client, perché non può rispondere abbastanza velocemente.

Ma quando non ci sono quasi utenti, SQL Server non fa quasi nulla. Eppure le persone devono aspettare per sempre solo per salvare qualsiasi cosa nell'applicazione.

Secondo la query " Dimmi dove fa male " di Paul Randal , il 50% di tutti gli eventi di attesa sono ASYNC_NETWORK_IO.

Ciò potrebbe significare un problema di rete o un problema di prestazioni con il server delle applicazioni o il client. Nessuno di questi utilizza in remoto le proprie risorse alla massima capacità. La maggior parte delle volte la CPU è di circa il 26% su tutte le macchine (client, appserver, server db).

La latenza della connessione di rete è di circa 1-3 ms. L'IO del server db ha una velocità di scrittura massima di 20 MB / s durante l'utilizzo normale con l'applicazione (avg è 7-9 MB / s). Quando eseguo lo stress test, ottengo circa 5 GB / s.

La dimensione della cache del buffer è di 60 GB per il DB del nostro sistema ERP, 20 GB per il nostro software di finanziamento, 1 GB per il software di garanzia della qualità, 3 GB per il sistema di archiviazione dei documenti.

Ho dato all'account SQL Server il diritto di utilizzare l' inizializzazione dei file istantanei . Ciò non ha aumentato le prestazioni al minimo.

L'aspettativa di vita della pagina è di circa 15k + durante l'uso normale. Scende a circa 0,05 k durante la fine delle prove di stress intenso, che è prevedibile. Batch / sec è di circa 2-8k, a seconda del carico di lavoro.

Direi che l'app ERP è scritta male, ma non posso perché tutte le applicazioni sono interessate. Anche con un carico di lavoro minimo.

Eppure non riesco a individuare ciò che sta causando questo. Ci sono suggerimenti, suggerimenti tutorial, applicazioni, documenti sulle migliori / peggiori pratiche o qualcos'altro che avete in mente riguardo a questo problema?

Questi sono i risultati di sp_BlitzFirst:

inserisci qui la descrizione dell'immagine

inserisci qui la descrizione dell'immagine

L'ho eseguito 600 secondi. L'ho avviato durante un carico di lavoro elevato dell'app. 1/3 del tempo è ASYNC_NETWORK_IO. Ho anche provato la connessione di rete con NTttcp, PsPing, ipferf3, e pathping. Niente di insolito. I tempi di risposta sono al massimo di 3 ms, in media 0,3 ms. La velocità effettiva è di circa 1000 MB / s.

La mia indagine risulta sempre ASYNC_NETWORK_IOessere il numero uno in attesa.

Abbiamo esaminato il risultato della disabilitazione della Large-Receive-Offloadfunzione in VMware. Stiamo ancora testando, ma i risultati sembrano incoerenti. Il nostro primo "benchmark" ha prodotto una durata di 19 minuti (il risultato migliore è di 13 minuti, che viene raggiunto solo quando l'app è in esecuzione sulla VM con lo stesso SQL Server). Il secondo risultato è di 28 minuti, il che è davvero negativo.

Il primo risultato del nostro "benchmark" è stato di 19 minuti. Che è buono. Perché il risultato migliore è stato di 13 minuti (che è raggiungibile solo quando l'applicazione esegue il benchmark sulla VM con lo stesso SQL Server). Ciò suggerisce fortemente alcuni problemi relativi alla rete. O un problema con la configurazione di VMware.

Al momento mi sono perso su quali metodi utilizzare, per inchiodarlo fino al collo di bottiglia.

Le massime prestazioni con l'app sono ottenibili solo quando l'app è in esecuzione sulla VM con lo stesso SQL Server. Se l'app viene eseguita su qualsiasi altra macchina virtuale o desktop virtuale, la durata del nostro benchmark viene triplicata (da 13 minuti a 40 minuti o più). Tutti gli endpoint (VM di SQL Server, VM di app server e Virtual Desktop) utilizzano lo stesso hardware fisico. Abbiamo spostato tutti gli altri endpoint su altro hardware.

EDIT: sembra che il problema sia tornato. Dopo aver impostato la modalità di risparmio energetico da bilanciato a prestazioni elevate, abbiamo effettivamente migliorato notevolmente i tempi di risposta. Ma oggi ho eseguito di nuovo sp_BlitzFirst, con un campione di 300 secondi. Questo è il risultato:

Questo è il risultato

Mostra più secondi del tempo di attesa per ASYNC_NETWORK_IO rispetto ai secondi sp_blitzfirst eseguiti.

Risposte:


18

Se l'attesa principale è ASYNC_NETWORK_IO, il problema non riguarda SQL Server. È quasi sempre dovuto a un collo di bottiglia dell'applicazione. Non intendo un collo di bottiglia sul server delle applicazioni, ma piuttosto un collo di bottiglia nell'applicazione.

Il collo di bottiglia dell'applicazione è generalmente dovuto all'elaborazione riga per riga mentre SQL Server sta inviando i dati:

  • L'applicazione richiede dati da SQL Server
  • SQL Server sta inviando i dati velocemente
  • L'applicazione dice a SQL Server di attendere mentre elabora ogni riga
  • SQL Server registra il tempo di attesa ASYNC_NETWORK_IOmentre l'applicazione gli sta dicendo di attendere

Invece, l'applicazione deve consumare tutti i dati da SQL Server e POI eseguire l'elaborazione riga per riga. A quel punto, SQL Server è fuori dai giochi.

sp_BlitzFirst produzione

L' LCK_M_Sattesa non è alta. Ci sono solo 2 secondi del campione di 30 secondi e la sua media è solo di 400 ms. Questo è il problema molto, molto improbabile. ASYNC_NETWORK_IOè la tua attesa principale in quel campione. Ancora un problema con l'applicazione. Se desideri aiuto con le LCKcose, dovremmo vedere le domande coinvolte.

Anche ASYNC_NETWORK_IOnon è poi così male in quel campione. I miei occhi diventano grandi quando il tempo di attesa è uguale o maggiore della dimensione del campione. Questo è quando scavo.

L'intero problema è ASYNC_NETWORK_IO. Questo non è un problema di SQL Server. È un problema con l'applicazione (che esegue l'elaborazione riga per riga mentre SQL Server sta inviando i dati), il server delle applicazioni (hai già detto che va bene) o la rete (hai detto che la rete va bene). Quindi il problema è con l'applicazione. L'app C ++ deve essere corretta.


6

Per rispondere alla mia domanda: il motivo principale per cui ASYNC_NETWORK_IO è apparso sul nostro SQL Server come tipo di attesa principale, è stato che l' energy savingimpostazione del server Windows era impostata su 'balanced'anziché 'high performance'. In seguito abbiamo parlato con alcuni amministratori di VM Ware e tutti hanno detto che questa impostazione uccide le prestazioni .

Le soluzioni per questo sono:

  • Non installare il controllo energetico durante l'installazione di Windows Server
  • Impostare la modalità di risparmio energetico su prestazioni elevate per tutti i server tramite criteri di gruppo

Tutti gli altri problemi / statistiche riguardanti ASYNC_NETWORK_IO sono correlati alla nostra app ERP scritta male. Grazie a tutti coloro che mi hanno aiutato a risolvere questo problema, i tuoi commenti, suggerimenti e consigli sono stati molto graditi e utili!


Molti BIOS ora hanno un controllo più granulare del risparmio energetico, ad esempio la gestione dell'energia della NIC. Mi chiedo se sia possibile avere ancora il ridimensionamento di frequenza attivo ed evitare le attese di IO sulla scheda di rete disabilitando semplicemente le sue modalità di risparmio energetico.
ajeh
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.