domande frequenti sul ridimensionamento e sulle prestazioni del sito Configuration Manager

Separare le caselle di posta in arrivo Configuration Manager e SQL Server file in almeno due volumi diversi. Questa separazione consente di ottimizzare le dimensioni di allocazione del cluster per i diversi tipi di operazioni di I/O eseguite.

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

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

Le matrici moderne di unità SSD (Solid State Drive) e Azure Archiviazione Premium possono offrire operazioni di I/O al secondo elevate in un singolo volume, con pochi dischi. In genere si aggiungono altre unità a una matrice per l'archiviazione aggiuntiva, non per una velocità effettiva aggiuntiva. Se si usano dischi fisici basati su spindle, potrebbero essere necessarie più operazioni di I/O al secondo rispetto a quelle generate in un singolo volume. È necessario allocare il 60% del totale consigliato di operazioni di I/O al secondo e lo spazio su disco per il file con estensione mdf , il 20% per il file con estensione ldf e il 20% per i file temporanei di log e dati. I file con estensione ldf e temp possono risiedere tutti in un singolo volume con il 40% (20% + 20%) delle operazioni di I/O al secondo allocate.

SQL Server versioni precedenti a SQL Server 2016 create per impostazione predefinita solo un file di dati temporanei. È consigliabile crearne altri, per evitare blocchi SQL Server e attendere l'accesso a un singolo file. Le opinioni della community variano in base al numero migliore di file di dati temporanei da creare, da quattro a otto. Il test rivela una piccola differenza tra quattro e otto, quindi è possibile creare quattro file di dati temporanei di dimensioni uguali . I file di dati tempdb devono essere fino al 20-25% delle dimensioni del database completo.

Se configurabile, impostare la memoria del controller RAID sull'allocazione del 70% per le operazioni di scrittura e del 30% per le operazioni di lettura. In generale, usare una configurazione di matrice RAID 10 per il database del sito. RAID 1 è accettabile anche per i siti su piccola scala con requisiti di I/O ridotti o se si usano unità SSD veloci. Con matrici di dischi di dimensioni maggiori, configurare i dischi di riserva per sostituire automaticamente i dischi con errori.

Esempio: Computer fisico con dischi fisici

Le linee guida per il ridimensionamento per un server del sito con connessione vincolata e SQL Server con 100.000 client sono 1200 operazioni di I/O al secondo per le caselle di 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 è tratto da Configurazioni del disco di esempio.

Hyper-V offre prestazioni simili a un server fisico, se le risorse hardware (core CPU e archiviazione pass-through) sono dedicate al 100% alla macchina virtuale. L'uso di file con estensione vhd o vhdx a dimensione fissa comporta un impatto minimo sulle prestazioni di I/O dell'1-5%. L'uso di file disco con estensione vhd o vhdx a espansione dinamica comporta un impatto sulle prestazioni di I/O fino al 25% per il carico di lavoro Configuration Manager. Se è necessario espandere dinamicamente i dischi, compensare aggiungendo altre prestazioni di I/O al secondo del 25% alla matrice.

Quando si esegue il server del sito Configuration Manager o SQL Server all'interno di una macchina virtuale, isolare le unità del sistema operativo host Hyper-V dal sistema operativo e dalle unità dati della macchina virtuale.

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

Esempio: server del sito basato su VM Hyper-V

Le linee guida per il ridimensionamento per un server del sito con connessione vincolata e SQL Server con 150.000 client sono 1800 operazioni di I/O al secondo per le caselle di posta in arrivo del server del sito e 7400 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. Con estensione vhdx pass-through a dimensione fissa per l'unità VM dedicata al volume sottostante.
3. Questo valore è tratto da Configurazioni del disco di esempio.

Per iniziare, leggere le domande frequenti sulla Configuration Manager in Azure.

Le macchine virtuali IaaS (Infrastructure as a Service) di Azure 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 dischi o Spazi di archiviazione per offrire spazio e prestazioni aggiuntivi.

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

• Ottimizzare le prestazioni dell'applicazione

• Linee guida per i dischi

Esempio: server del sito basato su Azure

Le linee guida per il ridimensionamento per un server del sito con connessione vincolata e SQL Server con 50.000 client sono otto core, 32 GB e 1200 operazioni di I/O al secondo per le caselle di posta in arrivo del server del sito e 2800 operazioni di I/O al secondo per i file SQL Server.

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

1. Questo valore è tratto da Configurazioni del disco di esempio.
2. Le indicazioni di Azure consentono di inserire TempDB nell'unità D: locale basata su SSD, dato che non supererà lo spazio disponibile e consente 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 di Azure precedente può limitare l'espansione futura o prestazioni aggiuntive. Se si aggiungono dischi aggiuntivi durante la distribuzione iniziale della macchina virtuale di Azure, è possibile ridimensionare la 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 cambiano i requisiti, invece di dover eseguire una migrazione più complessa in un secondo momento.

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

DS13v2

1. I dischi vengono sottoposti a striping usando Spazi di archiviazione.
2. Questo valore è tratto da Configurazioni del disco di esempio. Le dimensioni della macchina virtuale limitano le prestazioni.
3. Le indicazioni di Azure consentono di inserire TempDB nell'unità D: locale basata su SSD, dato che non supererà lo spazio disponibile e consente una distribuzione aggiuntiva di I/O su disco.

Se in futuro saranno necessarie altre prestazioni, è possibile eseguire l'upsize della macchina virtuale a un DS14v2, che raddoppia la CPU e la memoria. La larghezza di banda aggiuntiva del disco consentita dalle dimensioni della macchina virtuale aumenterà immediatamente anche le operazioni di I/O al secondo disponibili sui dischi configurati in precedenza.

DS14v2

1. I dischi vengono sottoposti a striping usando Spazi di archiviazione.
2. Questo valore è tratto da Configurazioni del disco di esempio. Le dimensioni della macchina virtuale limitano le prestazioni.
3. Le indicazioni di Azure consentono di inserire TempDB nell'unità D: locale basata su SSD, dato che non supererà lo spazio disponibile e consente una distribuzione aggiuntiva di I/O su disco.

Entrambe le prestazioni possono essere eseguite in modo adeguato, presupponendo che le dimensioni del server singolo siano appropriate o che la connettività di rete sia sufficiente tra i due server.

La SQL Server remota richiede il costo iniziale e operativo di un server aggiuntivo, ma è tipica tra la 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 sovraccarico per l'elaborazione del sito
• Ripristino di emergenza più semplice in alcune situazioni
• Gestione più semplice della sicurezza
• Separazione dei ruoli per la gestione SQL Server, ad esempio con un team DBA separato

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

• Costi inferiori per computer, licenze e manutenzione
• Meno punti di errore nel sito
• Controllo migliore per la pianificazione dei tempi di inattività

Per impostazione predefinita, SQL Server usa tutta la memoria disponibile nel server, potenzialmente morendo di fame il sistema operativo e altri processi nel computer. Per evitare potenziali problemi di prestazioni, è importante allocare memoria a SQL Server in modo esplicito. Nei server del sito collegati con SQL Server, assicurarsi che il sistema operativo disponga di RAM sufficiente per la memorizzazione nella cache dei file e altre operazioni. Assicurarsi che la RAM rimanente sia sufficiente per SMSExec e altri processi di Configuration Manager. Quando si esegue SQL Server in un server remoto, è possibile allocare la maggior parte della memoria a SQL, ma non a tutti. Per indicazioni iniziali, vedere le linee guida per il ridimensionamento .

SQL Server l'allocazione della memoria deve essere arrotondata a gb interi. Inoltre, man mano che la RAM aumenta a grandi quantità, è possibile consentire a SQL Server di avere una percentuale più alta. Ad esempio, quando sono disponibili 256 GB o più di RAM, è possibile configurare SQL Server fino al 95%, in quanto conserva ancora molta memoria per il sistema operativo. Il monitoraggio del file di pagina è un buon modo per assicurarsi che la memoria sia sufficiente per il sistema operativo e per qualsiasi processo Configuration Manager.

È possibile che si verifichino problemi di contesa di memoria se sono presenti più di 16 core fisici e una RAM insufficiente nella SQL Server. Il carico di lavoro Configuration Manager offre prestazioni migliori quando sono disponibili almeno 3-4 GB di RAM per core per SQL. Quando si aggiungono core al SQL Server, assicurarsi 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 con estensione ldf nel log del database in un ambiente di gruppo di disponibilità occupato. Tuttavia, lo spazio del file di log viene rilasciato automaticamente dopo un backup riuscito del database. Aggiungere un processo SQL Server per il database Configuration Manager 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 Configuration Manager, incluse altre informazioni sulle strategie di backup SQL Server, vedere Preparare l'uso di un gruppo di disponibilità SQL Server Always On.

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

Tutti i segreti nel database Configuration Manager sono già archiviati in modo sicuro, ma l'aggiunta di SQL Server crittografia può aggiungere un altro livello di sicurezza. L'abilitazione della crittografia nel database non ha problemi funzionali, ma può verificarsi una riduzione delle prestazioni fino al 25%. Pertanto, crittografare con cautela, soprattutto in ambienti su larga scala. Ricordarsi anche di aggiornare i piani di backup e ripristino per assicurarsi di poter ripristinare correttamente i dati crittografati.

Per le versioni supportate di SQL, vedere Supporto per le versioni SQL Server. Dal punto di vista delle prestazioni, tutte le versioni supportate di SQL Server soddisfano i criteri di prestazioni richiesti. Tuttavia, SQL Server 2016 o versioni successive tende a sovraperformare SQL Server 2014 in alcuni aspetti del carico di lavoro Configuration Manager. Inoltre, l'esecuzione di SQL Server 2014 a SQL Server livello di compatibilità 2012 (110) migliora le prestazioni in generale. Al momento dell'installazione, Configuration Manager database in esecuzione in SQL Server 2014 sono impostati sul livello di compatibilità 110. SQL Server 2016 o versioni successive è impostato sul livello di compatibilità predefinito della versione SQL Server, ad esempio 130 per SQL Server 2016. L'aggiornamento SQL Server non aggiorna i livelli di compatibilità fino a quando non si installa la successiva versione principale Configuration Manager current branch.

Se si verificano timeout o rallentamenti insoliti in determinate query SQL in SQL Server 2016 o versioni successive, ad esempio quando si usa il controllo degli accessi in base al ruolo nella console di Amministrazione, provare a modificare il livello di compatibilità SQL Server nel database Configuration Manager su 110. L'esecuzione a SQL Server livello di compatibilità 110 in SQL Server 2014 e versioni più recenti di SQL Server è completamente supportata. Per altre informazioni, vedere Timeout delle query SQL o rallentamento della console in determinate query di database Configuration Manager.

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

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

Sì, aggiornare gli indici una volta alla settimana e le statistiche una volta al giorno per migliorare le prestazioni SQL Server. Gli script di terze parti e le informazioni aggiuntive disponibili dalle community Configuration Manager e SQL Server consentono di ottimizzare queste attività.

Nei siti di grandi dimensioni, alcune tabelle SQL Server, ad esempio CI_CurrentComplianceStatusDetails, HinvChangeLog, potrebbero essere di grandi dimensioni, a seconda dei modelli di utilizzo. Potrebbe essere necessario ridurre o modificare l'approccio di manutenzione uno alla volta.

SQL Server Express non ha implicazioni significative sulle prestazioni nei 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 SQL Server. Se si dispone di un numero elevato di punti di distribuzione e pacchetti o origini nell'ambiente, è possibile superare il limite di dimensioni di 10 GB di SQL Server Express. Se il numero di pacchetti per il numero di punti di distribuzione è superiore a 4.000.000, ad esempio 2.000 DPs con 2.000 parti di contenuto, provare a usare l'intero SQL Server nei siti secondari.

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

Molti amministratori Configuration Manager seguono le indicazioni riportate in Raccomandazioni e linee guida per l'opzione di configurazione "max degree of parallelism" in SQL Server. Nella maggior parte dei moderni hardware di grandi dimensioni, queste linee guida portano a un'impostazione massima suggerita di otto. Tuttavia, se si eseguono molte query più piccole rispetto al numero di processori, può essere utile impostarla su un numero più alto. Limitare se stessi a otto non è necessariamente l'impostazione migliore nei siti più grandi quando sono disponibili più core.

In SQL Server 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 a 0, iniziare con un nuovo valore almeno maggiore o uguale al numero minimo consigliato di core per il ridimensionamento SQL Server del sito. Un valore inferiore a questo valore ha quasi sempre implicazioni negative sulle prestazioni. Ad esempio, un SQL Server remoto per un sito client di 100.000 richiede almeno 12 core. Se il 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 con volumi elevati e sicuri, è consigliabile disabilitare il monitoraggio attivo per ottenere prestazioni ottimali.

Per altre informazioni sulle esclusioni antivirus consigliate, vedere Esclusioni antivirus consigliate per Configuration Manager 2012 e Current Branch Site Server, Site Systems e Client.

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

Assicurarsi inoltre di avere installato gli aggiornamenti più recenti per il sistema operativo che esegue WSUS:

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

Vedere la guida completa per Microsoft wsus e Configuration Manager la manutenzione del SUP.

Il monitoraggio tradizionale delle prestazioni del server funziona in modo efficace per i Configuration Manager generali. È anche possibile sfruttare i diversi Management Pack di System Center Operations Manager per Configuration Manager, SQL Server e Windows Server per monitorare l'integrità di base dei server. Puoi anche monitorare direttamente i contatori di Windows Monitor prestazioni (PerfMon) Configuration Manager fornisce. Monitorare i backlog nelle varie caselle di posta in arrivo per individuare eventuali segnali di avviso di potenziali problemi di prestazioni del sito o backlog.

Vedere anche

• Linee guida per le prestazioni e il ridimensionamento del sito
• Configuration Manager domande frequenti su Azure