Domande frequenti sulle dimensioni e le prestazioni del sito di Gestione configurazione

Separare le cartelle Posta in arrivo di Gestione configurazione e i file di SQL Server in almeno due volumi diversi. Questa separazione consente di ottimizzare le dimensioni di allocazione del cluster per i diversi tipi di I/O che eseguono.

Per il volume che ospita le cartelle in arrivo del server dei siti, usare NTFS con unità di allocazione 4K o 8K. ReFS scrive 64k anche per file di piccole dimensioni. Gestione configurazione ha molti file di piccole dimensioni, quindi ReFS può produrre un sovraccarico del disco non necessario.

Per i dischi contenenti file di database di SQL Server, usare la formattazione NTFS o ReFS, con unità di allocazione 64K.

Le moderne matrici di unità SSD (Solid State Drive) e Azure Archiviazione Premium possono fornire operazioni di I/O al secondo elevate su un singolo volume, con pochi dischi. In genere si aggiungono più unità a un array per aumentare lo spazio di archiviazione, non per aumentare la velocità effettiva. Se si usano dischi fisici basati su assi, potrebbero essere necessarie più operazioni di I/O al secondo di quelle che è possibile generare in un singolo volume. È necessario allocare il 60% delle operazioni di I/O al secondo e dello spazio su disco totali consigliati per il file .mdf , il 20% per il file con estensione ldf e il 20% per i file temporanei di log e dati. I file .ldf e temp possono risiedere tutti in un singolo volume con il 40% (20% + 20%) delle operazioni di I/O al secondo allocate.

Le versioni di SQL Server precedenti a SQL Server 2016 creavano per impostazione predefinita un solo file di dati temporanei. È consigliabile crearne di più per evitare i blocchi di SQL Server e l'attesa dell'accesso a un singolo file. Le opinioni della community variano sul numero massimo di file di dati temporanei da creare, da quattro a otto. I test rivelano poca differenza tra quattro e otto, quindi puoi creare quattro file di dati temporanei di dimensioni uguali . I file di dati tempdb dovrebbero essere fino al 20-25% delle dimensioni del database completo.

Quando configurabile, impostare la memoria del controller RAID sul 70% di allocazione per le operazioni di scrittura e sul 30% per le operazioni di lettura. In generale, utilizzare una configurazione di array RAID 10 per il database del sito. RAID 1 è accettabile anche per siti di piccole dimensioni con bassi requisiti di I/O o se si utilizzano SSD veloci. Con array di dischi più grandi, configurare dischi di riserva per sostituire automaticamente i dischi guasti.

Esempio: macchina fisica con dischi fisici

Le linee guida per il ridimensionamento di un server del sito con percorso condiviso e SQL Server con 100.000 client sono 1200 operazioni di I/O al secondo per le cartelle Posta in arrivo del server del sito e 5000 operazioni di I/O al secondo per i file SQL Server.

La configurazione del disco risultante potrebbe essere simile alla seguente:

1. Non include i dischi di riserva consigliati.
2. Questo valore proviene da configurazioni del disco di esempio.

Hyper-V offre prestazioni simili a quelle di un server fisico se le risorse hardware (core CPU e archiviazione pass-through) sono dedicate al 100% alla macchina virtuale (VM). L'uso di file disco .vhd o .vhdx di dimensioni fisse causa un impatto minimo dell'1-5% sulle prestazioni di I/O. L'uso di file disco con estensione dinamica .vhd o .vhdx causa un impatto sulle prestazioni di I/O fino al 25% per il carico di lavoro di Gestione configurazione. Se è necessario espandere dinamicamente i dischi, compensare aggiungendo un ulteriore 25% di prestazioni di I/O al secondo all'array.

Quando esegui il Gestione configurazione server del sito o SQL Server all'interno di una macchina virtuale, isola le unità del sistema operativo host Hyper-V dal sistema operativo della macchina virtuale e dalle unità dati.

Per altre informazioni sull'ottimizzazione delle macchine virtuali, vedere Ottimizzazione delle prestazioni dei server Hyper-V.

Esempio: server del sito basato su macchine virtuali Hyper-V

Le linee guida per il ridimensionamento di un server del sito con percorso condiviso e SQL Server con 150.000 client sono 1800 operazioni di I/O al secondo per le cartelle Posta in arrivo del server di sito e 7400 operazioni di I/O al secondo per i file di SQL Server.

La configurazione del disco risultante potrebbe essere simile alla seguente:

1. Non include i dischi di riserva consigliati.
2. . vhdx pass-through di dimensioni fisse per l'unità VM dedicata al volume sottostante.
3. Questo valore proviene da configurazioni del disco di esempio.

Per iniziare, leggere le domande frequenti su Gestione configurazione in Azure.

Azure macchine virtuali IaaS (Infrastructure as a Service) che sfruttano i dischi basati su Archiviazione Premium possono avere operazioni di I/O al secondo elevate. In queste macchine virtuali configurare dischi aggiuntivi per le esigenze di spazio su disco previste, anziché per operazioni di I/O al secondo aggiuntive.

Archiviazione di Azure è intrinsecamente ridondante e non richiede più dischi per la disponibilità. È possibile eseguire lo striping dei dischi in Gestione disco o in Spazi di archiviazione per ottenere ulteriore spazio e prestazioni.

Per altre informazioni e suggerimenti su come ottimizzare le prestazioni di Archiviazione Premium ed eseguire SQL Server nelle macchine virtuali IaaS di Azure, vedere:

• Ottimizzare le prestazioni delle applicazioni

• Indicazioni per i dischi

Esempio: server del sito basato su Azure

Le linee guida per il dimensionamento di un server del sito con percorso condiviso e SQL Server con 50.000 client sono 8 core, 32 GB e 1200 operazioni di I/O al secondo per le cartelle Posta in arrivo del server del sito e 2800 operazioni di I/O al secondo per i file SQL Server.

Il computer di Azure risultante potrebbe essere un DS13v2 (8 core, 56 GB) con la configurazione del disco seguente:

1. Questo valore proviene da configurazioni del disco di esempio.
2. Le indicazioni di Azure consentono di posizionare TempDB nell'unità D: locale basata su SSD, a condizione che non superi lo spazio disponibile e consenta una distribuzione aggiuntiva di I/O su disco.

Esempio: server del sito basato su Azure (per un aumento immediato delle prestazioni)

La velocità effettiva del disco di Azure è limitata dalle dimensioni della macchina virtuale. La configurazione nell'esempio precedente di Azure può limitare l'espansione futura o le prestazioni aggiuntive. Se si aggiungono altri dischi durante la distribuzione iniziale della macchina virtuale di Azure, è possibile aumentare le dimensioni della macchina virtuale di Azure per aumentare la potenza di elaborazione in futuro, con un investimento iniziale minimo. È molto più semplice pianificare in anticipo per aumentare le prestazioni del sito man mano che i requisiti cambiano, invece di dover eseguire una migrazione più complicata in seguito.

Modificare i dischi nell'esempio di Azure precedente per vedere come cambiano le operazioni di I/O al secondo.

DS13v2

1. Ai dischi viene eseguito lo striping tramite Spazi di archiviazione.
2. Questo valore proviene da configurazioni del disco di esempio. Le dimensioni della macchina virtuale limitano le prestazioni.
3. Le indicazioni di Azure consentono di posizionare TempDB nell'unità D: locale basata su SSD, a condizione che non superi lo spazio disponibile e consenta una distribuzione aggiuntiva di I/O su disco.

Se in futuro sono necessarie prestazioni maggiori, è possibile eseguire l'upsize della macchina virtuale a DS14v2, che raddoppia la CPU e la memoria. La larghezza di banda del disco aggiuntiva consentita da tale dimensione della macchina virtuale aumenta istantaneamente le operazioni di I/O al secondo disponibili sui dischi configurati in precedenza.

DS14v2

1. Ai dischi viene eseguito lo striping tramite Spazi di archiviazione.
2. Questo valore proviene da configurazioni del disco di esempio. Le dimensioni della macchina virtuale limitano le prestazioni.
3. Le indicazioni di Azure consentono di posizionare TempDB nell'unità D: locale basata su SSD, a condizione che non superi lo spazio disponibile e consenta una distribuzione aggiuntiva di I/O su disco.

Entrambi possono funzionare adeguatamente, supponendo che il singolo server sia dimensionato in modo appropriato o che la connettività di rete sia sufficiente tra i due server.

SQL Server remoto richiede il costo operativo e iniziale di un server aggiuntivo, ma è tipico della maggior parte dei clienti su larga scala. I vantaggi di questa configurazione includono:

• Aumento delle opzioni di disponibilità del sito, ad esempio SQL Server Always On
• Possibilità di eseguire report pesanti con meno interventi di elaborazione del sito
• Ripristino di emergenza più semplice in alcune situazioni
• Gestione della sicurezza semplificata
• Separazione dei ruoli per la gestione di SQL Server, ad esempio con un team DBA separato

SQL Server con percorso condiviso richiede un singolo server ed è tipico per la maggior parte dei clienti di piccole dimensioni. I vantaggi di questa configurazione includono:

• Costi inferiori per macchine, licenze e manutenzione
• Meno punti di errore nel sito
• Migliore controllo per la pianificazione dei tempi di inattività

Per impostazione predefinita, SQL Server usa tutta la memoria disponibile nel server, potenzialmente affamando il sistema operativo e altri processi nel computer. Per evitare potenziali problemi di prestazioni, è importante allocare la memoria a SQL Server in modo esplicito. Nei server di sito che si trovano nella stessa area di SQL Server assicurarsi che il sistema operativo disponga di RAM sufficiente per la memorizzazione nella cache dei file e altre operazioni. Verifica che la RAM rimanente sia sufficiente per SMSExec e altri processi di Gestione configurazione. Quando si esegue SQL Server in un server remoto, è possibile allocare la maggior parte della memoria a SQL, ma non tutta. Per indicazioni iniziali, vedi le linee guida per il dimensionamento .

L'allocazione di memoria di SQL Server deve essere arrotondata all'intero GB. Inoltre, con l'aumento della RAM a grandi quantità, è possibile consentire a SQL Server di avere una percentuale più alta. Se ad esempio sono disponibili 256 GB o più di RAM, è possibile configurare SQL Server fino al 95%, in quanto in questo modo viene conservata una quantità sufficiente di memoria per il sistema operativo. Il monitoraggio del file di paging è un buon modo per verificare che vi sia memoria sufficiente per il sistema operativo e per qualsiasi processo di Gestione configurazione.

È possibile che si verifichino problemi di contesa della memoria se sono presenti più di 16 core fisici e RAM insufficiente in SQL Server. Il carico di lavoro di Gestione configurazione funziona meglio quando sono disponibili almeno 3-4 GB di RAM per core per SQL. Quando aggiungi core a SQL Server, assicurati di aumentare la RAM in quantità proporzionali.

In generale, i gruppi di disponibilità hanno un effetto trascurabile sulle prestazioni del sistema quando è disponibile una rete sufficiente tra i server di replica. È possibile avere una crescita rapida dei file .ldf di registro del database in un ambiente di gruppo di disponibilità occupato. Tuttavia, lo spazio per i file di log viene rilasciato automaticamente dopo un backup del database riuscito. Aggiungere un processo SQL Server per il database Gestione configurazione per eseguire un backup, ad esempio ogni 24 ore, e un backup con estensione ldf ogni sei ore. Per altre informazioni sui gruppi di disponibilità e sui Gestione configurazione, incluse altre informazioni sulle strategie di backup SQL Server, vedere Preparazione dell'utilizzo di un gruppo di disponibilità SQL Server Always On.

La compressione di SQL Server non è consigliata per il database di Gestione configurazione. Anche se non esistono problemi funzionali con l'abilitazione della compressione in un database di Gestione configurazione, i risultati dei test non mostrano un notevole risparmio di dimensioni rispetto al potenziale impatto considerevole sulle prestazioni del sistema.

Tutti i segreti nel database di Gestione configurazione sono già archiviati in modo sicuro, ma l'aggiunta della crittografia di SQL Server può aggiungere un ulteriore livello di sicurezza. L'abilitazione della crittografia nel database non presenta problemi di funzionalità, ma è possibile che si verifichi una riduzione delle prestazioni fino al 25%. Pertanto, crittografa con cautela, soprattutto in ambienti di grandi dimensioni. Ricorda inoltre di aggiornare i tuoi piani di backup e ripristino per assicurarti di poter recuperare correttamente i dati crittografati.

Per le versioni supportate di SQL, vedere Supporto per le versioni di SQL Server. Dal punto di vista delle prestazioni, tutte le versioni supportate di SQL Server soddisfano i criteri di prestazioni richiesti. L'aggiornamento di SQL Server sul posto non aggiorna i livelli di compatibilità.

Se si notano timeout o rallentamenti insoliti in determinate query SQL in SQL Server 2016 o versioni successive, ad esempio quando si usa Controllo dell'accesso basato sui ruoli (RBAC) nella console di amministrazione, provare a modificare il livello di compatibilità di SQL Server nel database di Gestione configurazione su 110. L'esecuzione al livello di compatibilità di SQL Server 110 in SQL Server 2014 e versioni successive di SQL Server è completamente supportata. Per altre informazioni, vedere Timeout delle query SQL o rallentamento della console per determinate query di database di Gestione configurazione.

A partire da gennaio 2018, è consigliabile evitare le versioni di SQL Server seguenti a causa di vari problemi noti correlati alle prestazioni o altri problemi potenziali:

• SQL Server 2012 SP3 da CU1 a CU5
• Da SQL Server 2014 SP1 CU6 a SP2 CU2
• SQL Server 2016 da RTM a CU3, SP1 da CU3 a CU5

L'attività di manutenzione predefinita "Ricompila indici" ricompila solo gli indici altamente frammentati. Query Optimizer aggiorna quindi le statistiche sugli oggetti correlati, come descritto nella sezione Operazioni di manutenzione nella documentazione SQL. Di conseguenza, se ci si basa esclusivamente su questa attività predefinita, le statistiche potrebbero non essere aggiornate in alcune tabelle e viste, con conseguenti piani di query non ottimali e prestazioni scarse.

È consigliabile eseguire la manutenzione dell'indice almeno una volta alla settimana e aggiornare le statistiche di tabelle e visualizzazioni una volta al giorno per mantenere le prestazioni di SQL Server.

Non esiste un approccio universale alla manutenzione dei database. La strategia ottimale dipende da fattori quali le dimensioni del database, le caratteristiche del carico di lavoro e i requisiti operativi. Il coinvolgimento di un esperto di SQL Server interno o di un Microsoft Cloud Solution Architect (CSA) può aiutarti a progettare la strategia di manutenzione su misura per il tuo ambiente.

Sono disponibili indicazioni aggiuntive dalle community di Gestione configurazione e SQL Server, inclusi gli script di manutenzione non Microsoft. Il whitepaper Raccomandazioni SQL per MECM riassume l'esperienza sul campo dei CSA Microsoft in materia di manutenzione e ottimizzazione di SQL.

Nei siti di grandi dimensioni, alcune tabelle di database, ad esempio CI_CurrentComplianceStatusDetails, HinvChangeLog, potrebbero essere di grandi dimensioni, a seconda dei modelli di utilizzo. Potrebbe essere necessario ridurre o modificare il tuo approccio per mantenerli uno per uno.

SQL Server Express non ha implicazioni significative sulle prestazioni dei siti secondari ed è adeguato per la maggior parte dei clienti. È anche facile da distribuire e gestire ed è la configurazione consigliata per quasi tutti i clienti di qualsiasi dimensione.

Esiste una situazione in cui potrebbe essere necessaria un'installazione completa di SQL Server. Se nell'ambiente è presente un numero elevato di punti di distribuzione e pacchetti o origini, è possibile superare il limite delle dimensioni di 10 GB di SQL Server Express. Se il numero di pacchetti moltiplicato per il numero di punti di distribuzione è superiore a 4.000.000, ad esempio 2.000 DP con 2.000 parti di contenuto, è consigliabile usare la versione completa di SQL Server nei siti secondari.

Lasciare l'impostazione su 0 (usare tutti i processori disponibili) è ottimale per le prestazioni di elaborazione complessive nella maggior parte dei casi.

Molti amministratori di Gestione configurazione seguono le indicazioni riportate in Consigli e linee guida per l'opzione di configurazione "massimo grado di parallelismo" in SQL Server. Nella maggior parte dell'hardware di grandi dimensioni moderno, queste indicazioni portano a un'impostazione massima consigliata di otto. Tuttavia, se si eseguono molte query di dimensioni inferiori rispetto al numero di processori in uso, può essere utile impostarla su un numero superiore. Limitarsi a otto non è necessariamente l'impostazione migliore sui siti più grandi quando sono disponibili più core.

Nei server SQL con più di otto core, iniziare con un'impostazione pari a 0 e apportare modifiche solo se si verificano problemi di prestazioni o blocchi eccessivi. Se è necessario modificare MaxDOP perché si verificano problemi di prestazioni in 0, iniziare con un nuovo valore almeno maggiore o uguale al numero minimo consigliato di core per il ridimensionamento di SQL Server del sito. Scendere al di sotto di questo valore comporta quasi sempre implicazioni negative sulle prestazioni. Ad esempio, un SQL Server remoto per un sito client da 100.000 richiede almeno 12 core. Se SQL Server ha 16 core, iniziare a testare l'impostazione MaxDOP con un valore pari a 12.

Prestare attenzione quando si disabilita la protezione antivirus in qualsiasi sistema. In ambienti sicuri e con volumi elevati, è consigliabile disabilitare il monitoraggio attivo per prestazioni ottimali.

Per altre informazioni sulle esclusioni antivirus consigliate, vedere Esclusioni antivirus consigliate per server del sito, sistemi del sito e client di Gestione configurazione.

La modifica di alcune impostazioni chiave di IIS, ad esempio la lunghezza della coda WsusPool e il limite di memoria privata WsusPool, può migliorare le prestazioni di WSUS, anche nelle installazioni più piccole. Per altre informazioni, vedi la nota WSUS in Hardware consigliato.

Verificare inoltre di disporre degli ultimi aggiornamenti installati per il sistema operativo che esegue WSUS:

• Windows Server 2012: qualsiasi aggiornamento cumulativo non "Solo sicurezza" rilasciato ad ottobre 2017 o versione successiva. (KB4041690)
• Windows Server 2012 R2: qualsiasi aggiornamento cumulativo non "Solo sicurezza" rilasciato ad agosto 2017 o versione successiva. (KB4039871)
• Windows Server 2016: qualsiasi aggiornamento cumulativo non "Solo sicurezza" rilasciato ad agosto 2017 o versione successiva. (KB4039396)

Vedi la guida completa alla manutenzione di Microsoft WSUS e Gestione configurazione SUP.

Il monitoraggio delle prestazioni del server tradizionale funziona in modo efficace per Gestione configurazione generale. È anche possibile usare soluzioni di monitoraggio come Monitoraggio di Azure per monitorare l'integrità di base dei server: vedere il post di blog ConfigMgr Performance Baseline the Easy Way. È anche possibile monitorare direttamente i contatori di Windows Monitor prestazioni (PerfMon) forniti da Gestione configurazione. Monitorare i backlog nelle varie cartelle Posta in arrivo per individuare eventuali segnali di allarme di potenziali problemi di prestazioni del sito o backlog.

Vedere anche

• Linee guida per il dimensionamento e le prestazioni del sito
• Domande frequenti su Gestione configurazione in Azure