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:
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:
Mostra più secondi del tempo di attesa per ASYNC_NETWORK_IO rispetto ai secondi sp_blitzfirst eseguiti.