Principali problemi di prestazioni sul nostro SQL Server di produzione, come dovrei risolvere questo problema?

Questa domanda è sostanzialmente una domanda successiva a questa domanda:
strano problema di prestazioni con SQL Server 2016

Ora siamo diventati produttivi con questo sistema. Anche se un altro database dell'applicazione è stato aggiunto a questo SQL Server dal mio ultimo post.

queste sono le statistiche di sistema:

• 128 GB RAM (110 GB di memoria massima per SQL Server)
• 4 core a 2,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
• Windows Server 2012 R2
• Versione VMware HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools versione 10.0.9, build 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 ottobre 2016 18:17:30 Copyright (c) Microsoft Corporation Standard Edition (64-bit) su Windows Server 2012 R2 Standard 6.3 (Build 9600:) (hypervisor)

Il nostro sistema presenta ora importanti problemi di prestazioni. Utilizzo della CPU molto elevato e numero di thread:

Attendi le statistiche del monitor attività (so che non è molto affidabile)

Risultati di sp_blitzfirst:

Risultati di sp_configure:

Impostazioni avanzate del server (sfortunatamente solo in tedesco)

L'impostazione di MAXDOP è stata modificata da me.

Sono consapevole che questo probabilmente non è un problema con lo stesso SQL Server . È probabilmente un problema con la virtualizzazione (vmware), la rete (ho già provato questo) o l'applicazione stessa. Voglio solo inchiodarlo ancora di più.

ASYNC_NETWORK_IO elevato comporterebbe un conteggio thread elevato per il processo sqlserver? Immagino che abbia coinvolto molti lavoratori perché i thread non possono essere chiusi. È giusto?

Fornirò tutte le informazioni aggiuntive di cui hai bisogno. Grazie in anticipo per il tuo supporto!

MODIFICARE:

Risultato di sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

Priorità 1: backup :

• Backup sulla stessa unità in cui risiedono i database - 5 backup eseguiti sull'unità E: \ nelle ultime due settimane, dove vivono anche i file di database. Ciò rappresenta un grave rischio in caso di errore dell'array.

Priorità 1: affidabilità :

• Ultimo buono DBCC CHECKDB oltre 2 settimane

  • babtec_prod - Ultimo successo CHECKDB: 2017-08-20 00: 01: 01.513

  • D3PR - Ultimo controllo CHECKDB riuscito: mai.

  • DEMO77 - Ultimo controllo CHECKDB riuscito: 23/02/2016 20: 31: 38.590

  • FINP - Ultimo successo CHECKDB: 2017-04-23 22: 01: 19.133

  • GridVis_EnMs - Ultimo successo CHECKDB: 2017-05-18 22: 10: 48.120

  • master - Ultimo controllo CHECKDB riuscito: mai.

  • modello

  • msdb

  • PROD77 - Ultimo controllo di successo: 23-02-2016 21: 33: 24.343

Priorità 10: prestazioni :

• Archivio query disabilitato: la nuova funzionalità Archivio query di SQL Server 2016 non è stata abilitata su questo database.

  • babtec_prod

  • D3PR

  • DEMO77

  • FINP

  • GridVis_EnMs

Priorità 50: Eventi DBCC :

• DBCC DROPCLEANBUFFERS - L'utente schorsch ha eseguito DBCC DROPCLEANBUFFERS 1 volte tra il 21 settembre 2017 11:57 e il 21 settembre 2017 11:57. Se questa è una scatola di produzione, sappi che stai cancellando tutti i dati dalla memoria quando ciò accade. Che tipo di mostro lo farebbe?

• DBCC SHRINK% - L'utente schorsch ha eseguito il file si restringe 6 volte tra il 21 settembre 2017 23:51 e il 4 ottobre 2017 09:02. Quindi, stanno cercando di riparare la corruzione o causare corruzione?

• Eventi generali - 287 eventi DBCC hanno avuto luogo tra il 19 settembre 2017 13:40 e il 4 ottobre 2017 15:20. Ciò non include CHECKDB e altri eventi DBCC generalmente benigni.

Priorità 50: Prestazioni :

• Crescite di file Lento PROD77 - 2 crescite hanno richiesto più di 15 secondi ciascuna. Considera di impostare la crescita automatica dei file su un incremento minore.

Priorità 50: Affidabilità :

• Verifica della pagina non ottimale babtec_prod - Il database [babtec_prod] ha TORN_PAGE_DETECTION per la verifica della pagina. SQL Server potrebbe avere difficoltà a riconoscere e ripristinare il danneggiamento dell'archiviazione. Prendi invece in considerazione l'utilizzo di CHECKSUM.

Priorità 100: Prestazioni :

• Molti piani per una query - 3576 piani sono presenti per una singola query nella cache del piano - il che significa che probabilmente abbiamo problemi di parametrizzazione.

Priorità 110: Prestazioni :

• Tabelle attive senza indici cluster

  • babtec_prod - Il database [babtec_prod] ha un sacco - tabelle senza un indice cluster - che vengono interrogate attivamente.

  • D3PR - Il database [D3PR] ha un sacco - tabelle senza un indice cluster - che vengono interrogati attivamente.

  • DEMO77 - Il database [DEMO77] ha un sacco - tabelle senza un indice cluster - che vengono interrogati attivamente.

  • FINP - Il database [FINP] ha un sacco - tabelle senza un indice cluster - che vengono interrogati attivamente.

  • GridVis_EnMs - Il database [GridVis_EnMs] ha un sacco - tabelle senza un indice cluster - che vengono interrogati attivamente.

  • PROD77 - Il database [PROD77] ha heap - tabelle senza un indice cluster - che vengono interrogati attivamente.

Priorità 150: Prestazioni :

• Chiavi esterne non affidabili

  • babtec_prod - Il database [babtec_prod] ha chiavi esterne che sono state probabilmente disabilitate, i dati sono stati modificati e quindi la chiave è stata nuovamente abilitata. Abilitare semplicemente la chiave non è sufficiente affinché l'ottimizzatore possa usare questa chiave: dobbiamo modificare la tabella usando il parametro WITH CHECK CHECK CONSTRAINT.

  • D3PR: nel database [D3PR] sono presenti chiavi esterne che sono state probabilmente disabilitate, i dati sono stati modificati e quindi la chiave è stata nuovamente abilitata. Abilitare semplicemente la chiave non è sufficiente affinché l'ottimizzatore possa usare questa chiave: dobbiamo modificare la tabella usando il parametro WITH CHECK CHECK CONSTRAINT.

• Tabelle inattive senza indici cluster

  • D3PR - Il database [D3PR] ha heap - tabelle senza un indice cluster - che non sono state interrogate dall'ultimo riavvio. Queste possono essere tabelle di backup trascurate con noncuranza.

  • GridVis_EnMs - Il database [GridVis_EnMs] ha un sacco - tabelle senza un indice cluster - che non sono state interrogate dall'ultimo riavvio. Queste possono essere tabelle di backup trascurate con noncuranza.

• Trigger su tabelle babtec_prod - Il database [babtec_prod] ha 26 trigger.

Priorità 170: Configurazione file :

• Database di sistema sull'unità C.

  • master: il database master ha un file sull'unità C. L'inserimento di database di sistema nell'unità C comporta il rischio di arresti anomali del server quando si esaurisce lo spazio.

  • modello: il database del modello ha un file sull'unità C. L'inserimento di database di sistema nell'unità C comporta il rischio di arresti anomali del server quando si esaurisce lo spazio.

  • msdb - Il database msdb ha un file sull'unità C. L'inserimento di database di sistema nell'unità C comporta il rischio di arresti anomali del server quando si esaurisce lo spazio.

Priorità 170: Affidabilità :

• Dimensione massima file impostata

  • D3PR - Il file di database [D3PR] d3_data_01 ha una dimensione massima del file impostata su 61440 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

  • D3PR - Il file di database [D3PR] d3_data_idx_01 ha una dimensione massima del file impostata su 61440 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

  • D3PR - Il file di database [D3PR] d3_firm_01 ha una dimensione massima del file impostata su 61440 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

  • D3PR - Il file di database [D3PR] d3_firm_idx_01 ha una dimensione massima del file impostata su 61440 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

  • D3PR - Il file di database [D3PR] d3_log_01 ha una dimensione massima del file impostata su 61440 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

  • D3PR - Il file di database [D3PR] d3_phys_01 ha una dimensione massima del file impostata su 61440 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

  • D3PR - Il file di database [D3PR] d3_phys_idx_01 ha una dimensione massima del file impostata su 61440 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

  • D3PR - Il file di database [D3PR] d3_sys_01 ha una dimensione massima del file impostata su 20480 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

  • D3PR - Il file di database [D3PR] d3_usr_01 ha una dimensione massima del file impostata su 20480 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

  • D3PR - Il file di database [D3PR] d3_wort_01 ha una dimensione massima del file impostata su 20480 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

  • D3PR - Il file di database [D3PR] d3_wort_idx_01 ha una dimensione massima del file impostata su 20480 MB. Se esaurisce lo spazio, il database smetterà di funzionare anche se potrebbe esserci spazio su disco disponibile.

Priorità 200: informativo :

• Compressione backup predefinita Off: backup completi non compressi si sono verificati di recente e la compressione backup non è attivata a livello di server. La compressione del backup è inclusa in SQL Server 2008R2 e versioni successive, anche in Standard Edition. Si consiglia di attivare la compressione dei backup per impostazione predefinita in modo che i backup ad hoc vengano compressi.

• Le regole di confronto sono Latin1_General_CS_AS FINP - Le differenze di confronto tra i database utente e tempdb possono causare conflitti, specialmente quando si confrontano i valori di stringa

• Le regole di confronto sono SQL_Latin1_General_CP1_CI_AS - Le differenze nelle regole di confronto tra database utente e tempdb possono causare conflitti, specialmente quando si confrontano i valori di stringa

  • DEMO77

  • PROD77

• Server collegato configurato: BWIN2 \ INFOR è configurato come server collegato. Controlla la sua configurazione di sicurezza mentre si connette con sa, perché qualsiasi utente che lo richiede otterrà autorizzazioni a livello di amministratore.

Priorità 200: monitoraggio :

• Messaggi di posta elettronica dell'agente senza errori

  • Il lavoro syspolicy_purge_history non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro upd_durchpreis_monatl non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro upd_fertmengen_woche non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro upd_liegezeit_monatl non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro upd_vertreter_diff non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro UPDATE_CONNECT_IK non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro Wartung.Cleanup non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro Wartung.DBCC Check DB non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro Wartung.Index neu erstellen non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro Wartung.Statistiken aktualisieren non è stato impostato per avvisare un operatore in caso di errore.

  • Il processo Wartung.Transactionlog Backup non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro Wartung.Vollbackup SystemDB non è stato impostato per avvisare un operatore in caso di errore.

  • Il lavoro Wartung.Vollbackup UserDB non è stato impostato per avvisare un operatore in caso di errore.

• Nessun avviso di corruzione - Gli avvisi di SQL Server Agent non esistono per gli errori 823, 824 e 825. Questi tre errori possono fornire una notifica in merito a guasti hardware anticipati. Abilitarli può prevenire un sacco di crepacuore.

• Nessun avviso per Sev 19-25 - Gli avvisi di SQL Server Agent non esistono per i livelli di gravità da 19 a 25. Questi sono alcuni errori molto gravi di SQL Server. Sapere che ciò sta accadendo può consentire di recuperare più rapidamente dagli errori.

• Non tutti gli avvisi configurati: non tutti gli avvisi di SQL Server Agent sono stati configurati. Questo è un modo semplice e gratuito per ricevere notifiche di corruzione, guasti ai lavori o gravi interruzioni anche prima che i sistemi di monitoraggio lo rilevino.

Priorità 200: Configurazione server non predefinita :

• Agent XPs: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

• Database Mail XPs - Questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

• lingua full-text predefinita: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 1033 ed è stato impostato su 1031.

• lingua predefinita: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

• livello di accesso filestream - Questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

• massimo grado di parallelismo: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 4.

• max server memory (MB) - Questa opzione sp_configure è stata modificata. Il suo valore predefinito è 2147483647 ed è stato impostato su 115000.

• min server memory (MB) - Questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 10000.

• connessioni di amministrazione remota: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

Priorità 200: Prestazioni :

• soglia di costo per il parallelismo: impostato su 5, il suo valore predefinito. La modifica di questa impostazione sp_configure può ridurre le attese di CXPACKET.

• Backup degli snapshot che si sono verificati: nelle ultime due settimane si sono verificati 9 backup dall'aspetto di snapshot, indicando che l'IO potrebbe essere bloccata.

Priorità 210: Configurazione database non predefinita :

• Lettura isolamento snapshot abilitato abilitato: questa impostazione del database non è l'impostazione predefinita.

  • D3PR

  • FINP

• Trigger ricorsivi abilitati: questa impostazione del database non è quella predefinita.

  • DEMO77

  • PROD77

• FINP abilitazione isolamento istantanea: questa impostazione del database non è quella predefinita.

Priorità 240: attendere le statistiche :

• 1 - ASYNC_NETWORK_IO - 225,9 ore di attesa, 143,5 minuti tempo medio di attesa all'ora, 0,2% di attesa del segnale, 2146022 attività di attesa, 378,9 ms tempo medio di attesa.

• 2 - CXPACKET - 43,1 ore di attesa, 27,4 minuti tempo medio di attesa all'ora, 1,5% di attesa del segnale, 32608391 attività di attesa, 4,8 ms tempo medio di attesa.

Priorità 250: informativo :

• SQL Server è in esecuzione con un account del servizio NT

  • Sono in esecuzione come NT Service \ MSSQL $ INFOR. Vorrei invece avere un account di servizio di Active Directory.

  • Sono in esecuzione come NT Service \ SQLAgent $ INFOR. Vorrei invece avere un account di servizio di Active Directory.

Priorità 250: Informazioni sul server :

• Contenuto della traccia predefinita: la traccia predefinita contiene 760 ore di dati tra il 3 settembre 2017 20:34 e il 5 ottobre 2017 12:50. I file di traccia predefiniti si trovano in: C: \ Programmi \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

• Spazio C Drive: 21308,00 MB gratuiti sull'unità C.

• Spazio D unità: 280008,00 MB di spazio libero sull'unità D.
• Drive E Space - 281618.00MB gratuiti su E drive

• Drive F Space - 60193.00MB gratuiti su F drive

• Hardware - Processori logici: 4. Memoria fisica: 128 GB.

• Hardware - Configurazione NUMA - Nodo: 0 Stato: ONLINE Pianificatori online: 4 Pianificatori offline: 0 Gruppo processore: 0 Nodo memoria: 0 Memoria VAS riservato GB: 281

• Ultimo riavvio del server - 1 ottobre 2017 14:21

• Nome server - BWINPDB \ INFOR

• Servizi

  • Servizio: SQL Server (INFOR) viene eseguito con l'account di servizio NT Service \ MSSQL $ INFOR. Ultimo orario di avvio: 1 ottobre 2017 14:22. Tipo di avvio: automatico, attualmente in esecuzione.

  • Servizio: SQL Server-Agent (INFOR) viene eseguito con l'account di servizio NT Service \ SQLAgent $ INFOR. Ultimo tempo di avvio: non mostrato. Tipo di avvio: automatico, attualmente in esecuzione.

• Ultimo riavvio di SQL Server - 1 ottobre 2017 14:22

• Servizio SQL Server - Versione: 13.0.4001.0. Livello di patch: SP1. Edizione: Edizione standard (64 bit). AlwaysOn Enabled: 0. AlwaysOn Mgr Status: 2

• Server virtuale - Tipo: (HYPERVISOR)

• Versione di Windows: stai utilizzando una versione piuttosto moderna di Windows: Server 2012R2 era, versione 6.3

Priorità 254: Rundate :

• Diario del capitano: stardare qualcosa e qualcosa ...

MODIFICARE:

Ho già studiato la guida alle migliori pratiche relativa alla configurazione del server sql con vmware e ne abbiamo impostato la maggior parte in base a questo documento. Tuttavia, l'hyperthreading non è attivato e NUMA non è attivo sull'host vmware. Tuttavia, SQL Server è impostato su NUMA.

MODIFICARE:

Ho emesso RECONFIGURE dopo aver impostato la soglia di parallelismo su 50, anche la mia impostazione MAXDOP non era configurata.

Ho anche controllato con il nostro amministratore di VMware, mi sembra di essere stato male informato. Le nostre CPU sono impostate su 2,6 GHz e non su 4,6 GHz. Ho corretto quelle informazioni sopra.

MODIFICARE:

Abbiamo cercato di impostare alcune reti relative a questo vmwarekb e guida . Abbiamo anche aggiunto altri 4 core alla VM. L'utilizzo della CPU è rimasto lo stesso.

Come discusso l'ultima volta che hai posto questa domanda , la tua attesa principale è ASYNC_NETWORK_IO. SQL Server è in attesa che la macchina all'altro capo della pipe digerisca la riga successiva dei risultati della query.

Ho ricevuto queste informazioni dai risultati delle statistiche di attesa di sp_Blitz (grazie per averlo incollato):

1 - ASYNC_NETWORK_IO - 225,9 ore di attesa, 143,5 minuti tempo medio di attesa all'ora, 0,2% di attesa del segnale, 2146022 attività di attesa, 378,9 ms tempo medio di attesa.

Non interrompere la risoluzione dei problemi relativi ai thread della CPU - questo non è correlato. Concentrati sul tipo di attesa principale e sulle cose che potrebbero causare quel tipo di attesa.

Per risolvere ulteriormente questo problema, esegui sp_WhoIsActive o sp_BlitzFirst (dichiarazione di non responsabilità: ne sono uno degli autori) - entrambi i quali elencheranno le query attualmente in esecuzione. Guarda la colonna delle informazioni di attesa, trova le query in attesa di ASYNC_NETWORK_IO e guarda le app e i server da cui sono in esecuzione.

Da lì, puoi provare:

• Verifica se questi server delle app sono sottodimensionati (come se fossero al massimo sulla CPU o paging su disco) e ottimizzali
• Lavorando con gli sviluppatori di app per vedere se stanno eseguendo un'elaborazione riga per riga sui risultati (come per ogni riga che ritorna da SQL Server, l'app si spegne ed esegue alcune elaborazioni prima di richiedere la riga successiva di risultati)
• Collaborare con gli sviluppatori di app per selezionare meno dati (come meno righe o meno colonne se non hanno bisogno di tutti i dati - a volte lo vedi quando le persone fanno accidentalmente un SELECT * e riportano più dati di quelli di cui hanno bisogno, o chiedono tutte le righe quando hanno davvero bisogno solo delle prime 1000)

Aggiorna con sp_WhoIsActive : nello screenshot di sp_WhoIsActive che hai pubblicato, hai un paio di query in attesa su ASYNC_NETWORK_IO. Per quelli, consultare le istruzioni sopra.

Nel resto delle query, osserva la colonna "status" di sp_WhoIsActive: la maggior parte di loro è "inattiva". Ciò significa che non funzionano affatto: stanno aspettando che le app sull'altra estremità della pipe inviino il loro prossimo comando. Hanno transazioni aperte (vedi la colonna "open_tran_count") ma non c'è nulla che SQL Server possa fare per accelerare una transazione in sospeso. Queste query sono state aperte per oltre quaranta minuti (la prima colonna in sp_WhoIsActive. Non stanno più facendo nulla. Devi convincere quelle persone a impegnare le loro transazioni e chiudere le loro connessioni. Questo non è un problema di ottimizzazione delle prestazioni.

Tutto ciò che vediamo qui indica uno scenario in cui stiamo aspettando sull'app.

Per rispondere alla mia domanda. ASYNC_NETWORK_IO in realtà non era il vero problema. Abbiamo risolto il nostro problema di prestazioni seguendo questa guida per i carichi di lavoro sensibili alla latenza:

Best practice per l'ottimizzazione delle prestazioni dei carichi di lavoro sensibili alla latenza nelle VM vSphere

Ho segnato le impostazioni che abbiamo applicato al nostro sistema con il colore giallo qui:

Penso che le impostazioni di maggior impatto siano state la configurazione numa e l'impostazione della sensibilità della latenza su alta . Ciò ha richiesto entrambi esplicitamente di allocare / riservare core di CPU fisica e RAM per la VM.

Abbiamo anche aggiunto più core alla VM e ora è necessario aggiornare la nostra licenza SQL Server da Standard a Enterprise.

Sembra che Windows stia segnalando la velocità di clock dei core della tua CPU a 4.6Ghz come 2.6Ghz ... Avrei eseguito uno strumento come CPU-Z per verificare a che velocità stanno effettivamente funzionando, e quindi guardare a cambiare le impostazioni di potenza in sia Windows che il BIOS / sistema operativo di gestione per disabilitare eventuali impostazioni di risparmio energetico che potrebbero rallentare i core a una velocità inferiore.