Le migliori pratiche di parallelismo

Quali sono le migliori pratiche per stabilire il parallelismo in generale? So che per impostazione predefinita SQL Server è impostato su0 utilizza tutti i processori disponibili, ma in quale caso vorresti cambiare questo comportamento predefinito?

Ricordo di aver letto da qualche parte (dovrò cercare questo articolo) che per i carichi di lavoro OLTP è necessario disattivare il parallelismo (impostare maxdop su 1). Non credo di aver capito completamente il perché dovresti farlo.

Quando manterresti maxdop fino a SQL Server (0)? Quando disattiveresti il ​​parallelismo (1)? Quando dichiareresti esplicitamente il maxdop a un determinato numero di processori?

Quali sono le cause del parallelismo?

Di solito non si desidera disabilitare il parallelismo poiché ciò lo disabiliterà anche per le attività di amministrazione. La soluzione migliore è correggere le query che causano il parallelismo mediante l'aggiunta o la correzione di indici o apportando modifiche complete allo schema.

In base alle tue domande aggiornate ...

Alcune persone cambieranno MAXDOP su 1 per le applicazioni create dal fornitore perché non possono controllare il database o lo schema e non vogliono che una singola query prenda il controllo dell'intero sistema.

Personalmente tengo sempre MAXDOP a 0 tranne alcuni rari casi.

Il parallelismo è causato da una singola operazione all'interno di un piano di esecuzione con un costo di esecuzione che supera un'impostazione predefinita (la soglia di costo per l'impostazione del parallelismo). Quando ciò accade, SQL Server avvia il parallelismo in modo da poter eseguire il multi-thread della richiesta nel tentativo di accelerare il processo. Il valore predefinito per la soglia di costo per il parallelismo è 5. In molte piattaforme OLTP vorrai aumentarlo fino a 30 o 40 in modo che il parallelismo entri in gioco solo per le query davvero costose.

Non ho mai visto la necessità di disattivare o modificare le impostazioni di parallelismo in tutti i miei tempi con SQL Server (ultimo millennio, SQL Sever 6.5)

A seguito della risposta di @StanleyJohns ...
Un sistema OLTP con query brevi e precise non dovrebbe mai raggiungere la soglia di costo ( "soglia di costo per il parallelismo" ), quindi non dovrebbe importare. Se hai delle domande che vanno in parallelo, allora perché dovresti limitarlo in base a qualcosa di non dimostrato

Devo ancora vedere anche un puro sistema OLTP. All'estremo, forse ci sono, ma anche il sistema medio ha rapporti su di esso; sia intra-day che notturno. È più probabile che queste query diventino parallele e ne traggano beneficio.

Con così tanti core di CPU disponibili oggi c'è probabilmente un caso per impostare il "massimo grado di parallelismo" globale se si può misurare e notare una differenza.

Come ho detto, il mio suggerimento è di non fare nulla . Simile a @mrdenny, ma includerei "non esiste un sistema OLTP puro"

Detto questo, potrebbe esserci un chilometraggio che disabilita i core hyperthread a livello di BIOS, ma questa è una domanda diversa ...

Inoltre, per favore vedi

• la mia dozzina di risposte SO: https://stackoverflow.com/search?tab=votes&q=user%3a27535%20parallelism
• Elaborazione di query parallele su MSDN

Quali sono le cause del parallelismo ?: C'è un'impostazione chiamata cost threshold for parallelism. Una volta superata questa soglia, viene utilizzato il parallelismo (se sono soddisfatti i prerequisiti).

La natura di un sistema OLTP è di avere un gran numero di transazioni rapide e brevi. L'uso del parallelismo a volte aumenta il tempo di elaborazione della query, poiché la query verrà suddivisa per essere elaborata in parallelo e quindi ricucita prima di essere restituita. Quindi vedrai suggerimenti per impostare maxdop su 1.

Un vantaggio dell'impostazione di maxdop su 1 è che il parallelismo è disattivato per impostazione predefinita, ma è possibile abilitarlo a livello di query utilizzando query hints.

Per i sistemi di data warehouse o OLAP in cui vengono restituiti set di risultati di grandi dimensioni, potrebbe essere utile suddividere la query utilizzando il parallelismo. Ciò consente alla query di sfruttare i core disponibili per ridurre i tempi di elaborazione della query.

Ho visto una query complessa divisa in più processi che richiedono ore per essere eseguiti - di solito puoi vederlo in sp_who2 come voci multiple con lo stesso spid.

Modificandolo in maxdop 1 e la query eseguita in meno di un minuto.

La lezione qui è che il motore non sempre funziona bene quando si tratta di parallelismo.

Abbiamo molti server con 4 core e alcuni con 8 core. Raccomando con così pochi core che il parallelismo (MAXDOP) sia impostato su 1 in modo da evitare attese sulla CPU (e anche problemi di timeout) per gli utenti dei sistemi OLTP. Per i server OLAP o di reporting, con tali pochi core, consiglio di impostare MAXDOP su 2 e di impostare Soglia di costo su 30 (questo può essere più alto o un po 'più basso per lo scenario) in modo che solo le query più pesanti utilizzino il parallelismo.