Quale frequenza di hash / sort si riversa in tempdb?

La nostra applicazione aziendale utilizza SQL Server per l'archiviazione dei dati ed è principalmente un sistema OLTP. Tuttavia, un componente importante della nostra applicazione genera un carico di lavoro OLAP significativo.

La nostra latenza di scrittura su tempdb è di circa 100 ms. Questa tendenza si mantiene nel tempo ed ALLOW_SNAPSHOT_ISOLATIONè disattivata . Stiamo risolvendo questo problema relativo all'unico problema e l'unica cosa interessante che abbiamo scoperto finora è che esiste un numero significativo di hash e ordinamento di versamenti su tempdb. Supponiamo che questo provenga dal nostro carico di lavoro OLAP.

Domanda

Quale frequenza di sversamenti riguarda? Qualunque? Quante fuoriuscite / sec? I nostri dati preliminari indicano che abbiamo circa 2 fuoriuscite di hash al secondo e 25 fuoriuscite di ordinamento al minuto.

È possibile che questa frequenza di sversamenti possa essere il principale colpevole della nostra latenza di scrittura ad alta temperatura?

Altre informazioni

Stiamo usando più file per tempdb come raccomandato per numero di core. I file tempdb si trovano su una SAN RAID 1 + 0 (con SSD ad alte prestazioni) ma è lo stesso dispositivo dei dati DB e dei file di registro principali. I file tempdb hanno dimensioni abbastanza grandi da crescere molto raramente. Non stiamo usando i flag di traccia 1117 o 1118. Un'altra variabile è che questa configurazione è condivisa per un numero di database diversi che presentano tutti un carico medio-alto.

La latenza di scrittura di 100 ms è molto maggiore degli intervalli accettabili per la latenza di scrittura tempdb che abbiamo riscontrato su MSDN, competenze SQL e altri siti. Tuttavia, la latenza di scrittura per gli altri nostri database è buona (inferiore a 10 ms). Sulla base di altre statistiche, sembra che stiamo usando tempdb pesantemente, in particolare per gli oggetti interni. Quindi stiamo scavando per cercare di scoprire perché la nostra applicazione sta usando oggetti interni così pesantemente.

Abbiamo reali problemi di prestazioni sulla nostra piattaforma che si manifestano in vari modi. Abbiamo monitorato i contatori di perf, esaminando le visualizzazioni DM e analizzando il comportamento delle nostre app per cercare di approfondire le caratteristiche di utilizzo delle risorse del nostro sistema. In questo momento siamo concentrati sugli sversamenti poiché abbiamo letto che gli sversamenti hanno un impatto negativo drastico perché vengono eseguiti su disco anziché in memoria. E sembra che abbiamo un numero molto elevato di sversamenti, ma volevo ottenere un contributo su ciò che la gente considera "alta".

È possibile che questa frequenza di sversamenti possa essere il principale colpevole della nostra latenza di scrittura ad alta temperatura?

Sì, è possibile , sebbene in genere sia la dimensione media degli sversamenti e quanto siano profondi (ovvero sversamenti di hash ricorsivi, specie multi-pass) che conta più della frequenza in sé.

SQL Server offre una vasta gamma di metriche e informazioni DMV per aiutarti a risolvere i vari fattori che contribuiscono alla pressione del tempdb, molti dei quali sono discussi nell'articolo tecnico Microsoft "Lavorare con tempdb in SQL Server 2005" (si applica a tutte le versioni dal 2005 in poi ).

Dovresti essere in grado di utilizzare le domande guida e diagnostiche contenute in quel documento per iniziare a identificare le cause primarie di qualsiasi pressione tempdb. Non trascurare ad esempio l'attività dell'archivio versione semplicemente perché ALLOW_SNAPSHOT_ISOLATIONnon è abilitato. Molte funzionalità utilizzano l'archivio versioni (ad esempio trigger, MARS, RCSI) oltre all'isolamento dello snapshot.

Se gli sversamenti di ordinamento e hash risultano significativi a un livello elevato, probabilmente dovrai impostare un monitoraggio specifico per questo. A seconda della versione di SQL Server, questo non è sempre semplice come si potrebbe sperare. Per connettere gli sversamenti di ordinamento e hash con la query specifica che li ha causati, è necessario ricevere notifiche degli eventi o eventi estesi. L'articolo di SolidQ, " Identificazione e risoluzione degli avvisi di ordinamento " contiene dettagli e alcuni buoni consigli generali sulla risoluzione di cause comuni.

Dovresti anche collaborare con il tuo team di archiviazione per determinare quanta latenza elevata è attribuibile al tuo carico di lavoro, quanto proviene da altri usi condivisi e quali opzioni ci sono per la riconfigurazione. L'analisi delle metriche di SQL Server aiuterà a informare questa discussione, così come qualsiasi metrica che le persone della SAN sono in grado di fornire.