Come determinare le impostazioni di configurazione appropriate di SQL Server

Riepilogo

In questo articolo vengono descritte le seguenti impostazioni di configurazione e consigli sul loro utilizzo:
  • Maschera di affinità
  • Lightweight Pooling
  • IO asincrono max
  • Thread di lavoro max
  • Memoria
  • Priority Boost
  • Set Working Set Size
SQL Server è possibile ottenere un livello molto elevato di prestazioni con relativamente poco ottimizzazione della configurazione. È possibile ottenere livelli elevati di prestazioni utilizzando Progettazione database e buona applicazione e non da lavoro di configurazione. Vedere la sezione "Riferimenti" di questo articolo per informazioni su come risolvere vari problemi di prestazioni di SQL Server.


Quando si indirizza un problema di prestazioni, il grado di miglioramento che è disponibile dall'ottimizzazione della configurazione è modesto a meno che non si dispone del sistema è configurato correttamente. In SQL Server versione 7.0 e versioni successive, è estremamente raro che le impostazioni di configurazione (specialmente le impostazioni avanzate) necessitano di eventuali modifiche di SQL Server utilizza l'ottimizzazione della configurazione automatica. In genere, non modificare una configurazione di SQL Server non senza una precisa ragione e metodico test accurati per verificare che sia necessaria la modifica di configurazione. È necessario stabilire una linea di base prima che la configurazione di modificare in modo che è possibile misurare il vantaggio dopo la modifica.


Se non si dispone di SQL Server è configurato correttamente, alcune impostazioni potrebbero annullare stabilizzare il server o potrebbero rendere comportamenti imprevisti di SQL Server. Anni di esperienza nel supporto di diversi ambienti indicano che le impostazioni di configurazione non predefinita potrebbero avere risultati compresi tra neutri e negativi.

Se si esegue una configurazione di modifica, è necessario eseguire metodiche delle prestazioni prima e dopo la modifica al fine di valutare il grado di miglioramento.

Basato su scenari di supporto effettivo, SQL Server versione 7.0 e versioni successive possibile ottenere un livello di prestazioni estremamente elevato senza alcuna configurazione manuale di ottimizzazione.

In SQL Server versione 7.0 e versioni successive, non apportare modifiche alla configurazione di connessioni utente, blocchie aprire gli oggetti perché, per impostazione predefinita, SQL Server in modo dinamico Ottimizza saranno molto limitati queste impostazioni.

Maschera di affinità

L'impostazione di maschera di affinità fa riferimento a come saldamente un thread è associato a una particolare CPU. Per impostazione predefinita, Microsoft Windows NT e Microsoft Windows 2000 utilizzare l'affinità "soft", che tenta di ripianificare un thread sulla CPU da cui ultimo eseguito. Tuttavia, in caso contrario, un thread può essere eseguita su una diversa CPU.

In pratica, se si modifica l'impostazione di maschera di affinità rispetto all'impostazione predefinita solo raramente consente prestazioni e spesso comporterà una riduzione delle prestazioni.

Maschera di affinità limita di SQL Server a un sottoinsieme di CPU disponibili e consente di altri concorrenti servizi CPU un accesso migliore. Nella maggior parte dei casi, non è necessaria questa operazione perché SQL Server viene eseguito con priorità normale. L'utilità di pianificazione di thread di Windows NT o Windows 2000 regola dinamicamente le priorità dei thread di tutti i thread concorrenti per assicurarsi che hanno buone possibilità in tutte le CPU disponibili.

Maschera di affinità tranne rare condizioni non regolare. Se si sceglie di modificare l'opzione affinity mask, eseguire rigorosi test metodici prima e dopo la modifica per verificare che sia necessaria e il grado di miglioramento.


Lightweight Pooling

Per impostazione predefinita, SQL Server utilizza un thread per SPID attivo o processo utente. Questi thread di lavoro in una configurazione comune per mantenere gestibile il numero di thread. La configurazione avanzata opzione "lightweight pooling" (che viene talvolta detta "Modalità Fiber") utilizza il supporto di Windows NT "fiber" di gestire essenzialmente in diversi contesti di esecuzione con un singolo thread.


In pratica, non è necessaria utilizzare la modalità Fiber tranne in circostanze molto rare. Lightweight pooling è potenzialmente utile solo se sono soddisfatte tutte le condizioni seguenti. È necessario determinare se è effettivamente utile tramite attente verifiche.
  • Server multiprocessore di grandi dimensioni sono in uso.
  • Tutti i server sono in esecuzione in prossimità della capacità massima.
  • Una grande quantità di variazioni di contesto si verifica (maggiore di 20.000 al secondo).
Per cercare la commutazione di contesto, utilizzare Performance Monitor, selezionare i thread del contatore, l'oggetto commutazioni di contesto/sec ", quindi selezionare per acquisire tutte le istanze di SQL Server.
Se il server viene eseguito in modalità Fiber, SQL Mail in SQL Server 2000 o SQL Server 2005 non è supportato. SQL Mail non è supportato in SQL Server 2000 a 64 bit. Per ulteriori informazioni, vedere l'argomento "Le differenze tra le versioni a 64 bit e a 32 bit" nella documentazione in linea di SQL Server 2000 (64-bit Edition).
Per ulteriori informazioni, fare clic sui numeri seguenti per visualizzare gli articoli della Microsoft Knowledge Base:

308604 PRB: SQLMail non è supportato quando si esegue il server in modalità fiber

303120 FIX: errore ConnectionWrite quando si utilizza il lightweight pooling

IO asincrono max

SQL Server 7.0: l'impostazione di configurazione max async IO è disponibile in SQL Server 7.0. Potrebbe essere opportuno modificare questa impostazione se si dispone di un sistema RAID veloce e un modo per misurare il vantaggio. Non modificare questa impostazione se non si dispone di una previsione con la quale valutare il risultato. Monitorare l'attività del disco per individuare eventuali problemi di accodamento del disco. Per ulteriori informazioni, vedere i seguenti argomenti della documentazione in linea di SQL Server:
  • "max async IO opzione"
  • "Monitoraggio delle attività del disco"
  • "Identificazione dei colli"
SQL Server 2000 e versioni successive: In SQL Server 2000 e versioni successive, è possibile modificare l'impostazione di configurazione max async IO . Questa impostazione vengono gestite automaticamente da SQL Server 2000 e versioni successive.

Thread di lavoro max

Per impostazione predefinita, il thread di lavoro massimo è 255 in SQL Server 2000. Pertanto, fino a 255 lavoro è possono creare thread. Nella maggior parte dei casi, utilizzare l'impostazione predefinita di 255. Ciò non significa che è possibile stabilire solo 255 connessioni utente. Un sistema può supportare migliaia di connessioni utente (che sono essenzialmente multiplex fino a 255 thread di lavoro) e in generale, che non considerano generalmente eventuali ritardi. In tal caso, solo 255 query possono essere eseguiti contemporaneamente, ma questo è multiplex al numero di CPU disponibili, in modo che la natura concorrente venga solo percepita, indipendentemente dal numero di thread di lavoro configurato.

Nota: Per impostazione predefinita, il thread di lavoro max è 0 in SQL Server 2005 e SQL Server 2008.

Se si configura un numero di thread di lavoro su un valore maggiore di quello predefinito, è quasi sempre controproducente e rallenta le prestazioni a causa di un sovraccarico di pianificazione e delle risorse. Solo aumentare questa impostazione in rare circostanze e quando rigorosi metodico dimostrato che è utile per eseguire questa operazione.


Memoria


Vedere la documentazione in linea di SQL Server "Ottimizzazione delle prestazioni con memoria opzioni di configurazione Server" per informazioni sulla configurazione di memoria.

Per ulteriori informazioni sulla configurazione di memoria per i cluster di SQL Server, vedere "Considerazioni sull'utilizzo di" nell'argomento della documentazione in linea di SQL Server, "Creazione di un Cluster di Failover".

Per ulteriori informazioni, fare clic sui numeri seguenti per visualizzare gli articoli della Microsoft Knowledge Base:

274750 per la configurazione della memoria per più di 2 GB in SQL Server

224818 la regolazione della memoria semplice è necessaria se sono installati sia SQL Server 7.0 che Exchange 5.5 Service Pack 2 su BackOffice Small Business Server 4.5

316749 PRB: non vi sia sufficiente memoria virtuale con un numero elevato di database

Priority Boost

Per impostazione predefinita, l'impostazione di aumento della priorità è 0, che fa sì che SQL Server eseguire una priorità normale, se si esegue SQL Server in un computer o in computer multiprocessore simmetrico (SMP). Se l'aumento della priorità è impostata su 1, il processo di SQL Server viene eseguito una priorità alta. Questa impostazione non eseguire il processo di SQL Server la priorità del sistema operativo più alto.

In base alle esperienze di supporto effettivo, non occorre utilizzare aumento della priorità per avere buone prestazioni. Se si utilizza l'aumento della priorità, è consigliabile non utilizzarlo solo in rare circostanze può interferire con server buon funzionamento di determinate condizioni. Ad esempio, il servizio supporto tecnico clienti Microsoft potrebbero utilizzare aumento della priorità quando si analizza un problema di prestazioni.

Importante Non utilizzare l'aumento della priorità per i server cluster che eseguono SQL Server 7.0 e versioni successive.

Set Working Set Size

Non modificare impostare dimensioni del working set rispetto all'impostazione predefinita. Il valore predefinito è 0, Windows NT o Windows 2000 virtual memory manager di determinare la dimensione del working set di SQL Server. Quando si installa SQL Server, automaticamente indica il programma di installazione di Windows NT o Windows 2000 per ottimizzare le prestazioni per le applicazioni di rete. Virtual memory manager di Windows NT o Windows 2000 verrà pertanto eseguire poche working set di rifilatura, che solo minima interferisce con il working set di istanze di SQL Server.

Modificando tale impostazione non fornisce alcun vantaggio delle prestazioni. In base alle effettive per il supporto, la modifica di questa impostazione in genere provoca più danni del bene.

Se si modifica l'impostazione delle dimensioni del working set, può essere anche una causa dei messaggi di errore di SQL Server 844 o 845. Vedere la sezione "Riferimenti" in questo articolo per ulteriori informazioni sulle cause comuni dei messaggi di errore 844 e 845.

Riferimenti

Per ulteriori informazioni, fare clic sui numeri seguenti per visualizzare gli articoli della Microsoft Knowledge Base:

310834 PRB: cause comuni del messaggio di errore 844 o 845 (errori di timeout latch di buffer)

298475 come risolvere i problemi di prestazioni delle applicazioni

243589 come risolvere le query con esecuzione lenta su SQL Server 7.0 o versione successiva

243588 come risolvere i problemi di prestazioni delle query ad hoc

Come risolvere i problemi di prestazioni delle applicazioni con SQL Server 224587

Impostazioni di configurazione corretto SQL Server 6.5 166967

254321 cluster SQL Server sconsigliate e gli avvisi di base

Considerazioni sulle prestazioni di 297864 per un aggiornamento da SQL Server 6.5

Proprietà

ID articolo: 319942 - Ultima revisione: 30 gen 2017 - Revisione: 1

Feedback