Stimare i requisiti di prestazioni e capacità per Access Services in SharePoint Server 2010
Si applica a: SharePoint Server 2010 Enterprise
Ultima modifica dell'argomento: 2016-11-30
In questo articolo vengono fornite informazioni aggiuntive sugli effetti dell'utilizzo di Access Services in Microsoft SharePoint Server 2010 su topologie in cui viene eseguito Microsoft SharePoint Server 2010.
Contenuto dell'articolo:
Caratteristiche della farm di testing
Risultati dei test
Suggerimenti
Risoluzione dei problemi
Caratteristiche della farm di testing
In questa sezione vengono descritti il set di dati utilizzato durante il testing, i carichi di lavoro applicati al prodotto durante la raccolta dei dati relativi alle prestazioni, l'hardware utilizzato nel corso del testing e la topologia di distribuzione di tale hardware.
Set di dati
La capacità e le prestazioni di Access Services dipendono in modo significativo dalla struttura delle applicazioni ospitate nel servizio. Su tali fattori spesso incidono soprattutto la dimensione delle tabelle e la complessità delle query. Per il testing sono state utilizzate dimensioni e complessità rappresentative, ma ogni applicazione e ogni set di dati è diverso. La capacità e le prestazioni varieranno in base alle applicazioni in uso, al relativo grado di complessità specifico e alla dimensione dei dati.
Per valutare il profilo di capacità, le applicazioni di Access Services sono state simulate in una farm dedicata a Access Services, in cui non erano in corso altri test di SharePoint. Nella farm erano inclusi i siti rappresentativi seguenti:
1.500 applicazioni di Access Services con un profilo di "piccole" dimensioni; un massimo di 100 elementi per elenco
1.500 applicazioni di Access Services con un profilo di "medie" dimensioni; un massimo di 2.000 elementi per elenco
1.500 applicazioni di Access Services con un profilo di "grandi" dimensioni; un massimo di 10.000 elementi per elenco
Ogni applicazione è costituita da più elenchi e gli altri elenchi sono dimensionati in modo appropriato in base a tale elenco più grande. Access Services è in grado di gestire una quantità di dati superiore a 10.000 elementi. Questo numero è stato scelto per il profilo di "grandi" dimensioni perché si prevedeva che applicazioni ancora più grandi non fossero molto comuni.
Le applicazioni erano equamente distribuite tra i tipi seguenti:
Contatti Una semplice applicazione per la gestione dei contatti, con un solo elenco.
Progetti Una semplice applicazione di controllo dell'avanzamento di attività e progetti, con due elenchi (progetti e attività associati a ogni progetto).
Ordini Un semplice sistema di gestione degli ordini, simile all'esempio Northwind Traders di Microsoft Access ma con scalabilità ridotta, contenente molti elenchi correlati tra loro (ordini, dettagli degli ordini, fatture, dettagli delle fatture, ordini di acquisto, dettagli degli ordini di acquisto e così via).
Carico di lavoro
Per simulare l'utilizzo delle applicazioni, sono stati creati carichi di lavoro per l'esecuzione di una o più operazioni seguenti:
Apertura dei moduli
Spostamento all'interno dei moduli
Applicazione di filtri e ordinamento dei fogli dati
Aggiornamento, eliminazione e inserimento di record
Pubblicazione dell'applicazione
Rendering dei report
In ogni carico di lavoro è incluso il "tempo interazione utente", ovvero un intervallo dai 5 ai 20 secondi tra un'azione dell'utente e l'altra. Questo aspetto differisce da quanto definito in altri documenti sulla pianificazione della capacità di SharePoint. Access Services è una piattaforma con stato e i cursori di memoria e i set di record sono stati gestiti tra le interazioni utente. Era importante simulare un'intera sessione utente e non solo le singole richieste. Per un singolo carico di lavoro utente, la media è di due richieste al secondo.
Nella tabella seguente sono riportate le percentuali utilizzate per determinare quale applicazione e quale dimensione di applicazione utilizzare.
| Piccole dimensioni | Medie dimensioni | Grandi dimensioni | |
|---|---|---|---|
Contatti |
16% |
10% |
9% |
Progetti |
18% |
12% |
10% |
Ordini |
11% |
8% |
6% |
Definizione di area verde e di area rossa
Per ogni configurazione, sono stati eseguiti due test per determinare un'"area verde" e un'"area rossa". La prima corrisponde alla velocità effettiva consigliata che può essere sostenuta. La seconda corrisponde alla velocità effettiva massima che può essere tollerata per un breve periodo di tempo, ma che è opportuno evitare.
L'area verde è stata definita come punto in cui il test in esecuzione utilizza al massimo metà della risorsa che causa il collo di bottiglia. In questo caso, tale risorsa era la percentuale di CPU in uno qualsiasi dei tre livelli, ovvero server Web front-end, server applicazioni (Access Data Services) o server di database (SQL Server). Il collo di bottiglia innanzitutto è stato identificato per una particolare configurazione. Quando si è trattato della CPU di Access Data Services, si è fatto in modo che la CPU utilizzata dal test relativo all'area verde nei computer Access Data Services fosse compresa tra il 40% e il 50%.
Nel caso dell'area rossa, è stato selezionato un punto in cui è stata raggiunta la velocità effettiva massima, ovvero un utilizzo della CPU compreso tra l'80% e il 90%. Durante la ricerca del collo di bottiglia, sono stati esaminati la percentuale di CPU, l'utilizzo della memoria (byte privati), la lunghezza della coda dischi, l'I/O su rete e altre risorse che potevano dare luogo a un collo di bottiglia.
Il test dell'area verde e quello dell'area rossa sono stati entrambi eseguiti per un'ora con un carico utente fisso.
I propri risultati possono variare
I valori specifici della capacità e delle prestazioni presentati in questo articolo sono diversi da quelli degli ambienti reali. Questa simulazione è basata esclusivamente su una stima delle operazioni che gli utenti effettivi possono eseguire. I valori indicati hanno il solo scopo di fornire un punto di partenza per la progettazione di un ambiente con scalabilità appropriata. Dopo avere completato la progettazione iniziale del sistema, è consigliabile testare la configurazione per determinare se il sistema supporterà i fattori specifici del proprio ambiente.
Impostazione e topologia hardware
Hardware lab
Per offrire informazioni generali sui dettagli dei risultati dei test, sono state utilizzate diverse configurazioni di farm per i test, ovvero da uno a quattro server Web front-end, da uno a quattro server applicazioni (se è presente Access Services o Access Data Services) e un solo computer server di database che esegue Microsoft SQL Server 2008. I test inoltre sono stati eseguiti utilizzando quattro computer client. Tutti i computer server erano a 64 bit, mentre tutti i computer client erano a 32 bit.
Nella tabella seguente sono riportati i componenti hardware specifici utilizzati per i test.
| Ruolo del computer | CPU | Memoria | Rete | Disco |
|---|---|---|---|---|
Server Web front-end |
2 processori, 4 core a 2,33 GHz |
8 GB |
1 gig |
RAID 5 a 2 assi |
Server applicazioni (Access Data Services) |
2 processori, 4 core a 2,33 GHz |
8 GB |
1 gig |
RAID 5 a 2 assi |
Server di database (SQL Server) |
4 processori, 4 core a 2,6 GHz |
32 GB |
1 gig |
RAID 0 con collegamento DAS (Direct Attached Storage) per ogni numero di unità logica (LUN) |
Topologia
Sulla base dell'esperienza acquisita, la CPU al livello del server applicazioni, in cui è in esecuzione Access Data Services, è un importante fattore di limitazione della velocità effettiva. La topologia è stata modificata aggiungendo altri computer Access Data Services fino a eliminare il collo di bottiglia e quindi aggiungendo un server Web front-end per ottenere una velocità effettiva ancora maggiore.
1x1: un computer server Web front-end e un computer Access Data Services
1x2: un computer server Web front-end e due computer Access Data Services
1x3: un computer server Web front-end e tre computer Access Data Services
1x4: un computer server Web front-end e quattro computer Access Data Services
2x1: due computer server Web front-end e un computer Access Data Services
2x2: due computer server Web front-end e due computer Access Data Services
2x4: due computer server Web front-end e quattro computer Access Data Services
Il computer che esegue SQL Server è relativamente potente e in nessun caso è diventato un collo di bottiglia (anche se stava iniziando a raggiungere la saturazione della CPU nel test 2x4), pertanto è rimasto invariato nelle topologie utilizzate. A seconda delle query che fanno parte di una combinazione reale di applicazioni, si prevede che il livello del server di database (SQL Server) possa diventare il collo di bottiglia.
Reporting Services era in esecuzione in modalità connessa per tutti i test al livello del server applicazioni (Access Data Services).
Risultati dei test
Nelle tabelle riportate di seguito vengono mostrati i risultati dei test di Access Services. Per ogni gruppo di test, sono state modificate solo alcune variabili specifiche per illustrare l'impatto progressivo sulle prestazioni della farm.
Tutti i test trattati in questo articolo sono stati eseguiti con un tempo interazione utente o tempo di attesa. Questo aspetto differisce dai risultati sulla pianificazione della capacità per altre parti di SharePoint.
Per informazioni sui colli di bottiglia di Access Services, vedere Comuni colli di bottiglia e relative cause (le informazioni potrebbero essere in lingua inglese) più avanti in questo articolo.
Scala generale
Nella tabella e nel grafico seguenti viene riepilogato l'impatto dell'aggiunta di server Web front-end e di computer Acces Data Services dedicati alla farm. Questi valori relativi alla velocità effettiva sono specifici per i computer Access Data Services e non mostrano l'effetto sull'intera farm.
| Topologia | Numero massimo richieste al secondo della soluzione di base | Numero consigliato richieste al secondo di base |
|---|---|---|
1x1 |
25 |
15 |
1x2 |
54 |
29 |
1x3 |
82 |
45 |
1x4 |
88 |
48 |
2x1 |
25 |
15 |
2x2 |
55 |
29 |
2x4 |
116 |
58 |
.gif "Valore RPS massimo e consigliato")
Risultati consigliati
Nel grafico seguente vengono mostrati i risultati per la velocità effettiva sostenibile consigliata.
.gif "Velocità effettiva e ADS")
Come spiegato in precedenza in questo articolo, con l'aggiunta del quarto computer Access Data Services il collo di bottiglia diventa il server Web front-end e con l'aggiunta di un secondo server Web front-end viene risolto il vincolo di risorsa al livello di server Web front-end. Ciò implica che 1x1, 1x2 e 1x3 siano configurazioni ragionevoli. Quando tuttavia viene aggiunto il quarto computer Access Data Services, è consigliabile aggiungere anche un server Web front-end. Poiché l'implementazione della scalabilità avviene in modo lineare (linea retta da 1x1 a 1x4), è possibile presumere che l'aggiunta di un settimo computer Access Data Services implichi anche l'aggiunta di un terzo server Web front-end e così via al fine di soddisfare le necessità della farm.
Ricordare che questi risultati si basano solo su un carico di lavoro simulato e che è consigliabile monitorare l'effettiva distribuzione per trovare il punto in cui sono necessari ulteriori server Web front-end per supportare computer Access Data Services aggiuntivi. I server Web front-end inoltre sono dedicati ad Access Services, mentre nella realtà tali server sono probabilmente condivisi con altri carichi di lavoro di SharePoint. I risultati vengono mostrati nel grafico seguente.
.gif "Tempi di risposta e ADS")
Nel grafico seguente viene mostrato il tempo di risposta a questo livello di velocità effettiva. Il tempo di risposta è molto breve, in media meno di ¼ di secondo per ogni richiesta.
.gif "SQL %CPU e ADS")
Questi risultati indicano che il computer SQL Server non era un collo di bottiglia perché l'aggiunta di un secondo server Web front-end ha risolto l'insufficienza di risorse e la CPU di SQL Server è sempre rimasta al di sotto del 50%. Tenere tuttavia presente che l'istanza di SQL Server è condivisa con altri servizi di SharePoint e SharePoint stesso, pertanto come effetto cumulativo la CPU o la lunghezza dischi I/O può diventare un collo di bottiglia.
Velocità effettiva massima
Nel grafico seguente vengono mostrati i risultati relativi a una velocità effettiva portata oltre il livello sostenibile.
In questo grafico è possibile vedere ancora come sia stato necessario un secondo server Web front-end per ottimizzare l'utilità del quarto computer Access Data Services. Anche in questo caso i propri risultati potrebbero essere diversi perché dipendono in modo significativo dalle applicazioni e dai relativi modelli di utilizzo.
.gif "Velocità effettiva e ADS")
In questo caso, il tempo di risposta è aumentato, in quanto l'intero sistema è sotto pressione. Questi livelli tuttavia sono ancora prossimi a un secondo e quindi risultano accettabili per la maggior parte degli utenti.
Può sembrare strano che, con quattro computer Access Data Services, due server Web front-end abbiano un tempo di risposta superiore rispetto a un solo server Web front-end. Questa situazione è dovuta al fatto che la velocità effettiva globale del sistema è aumentata con due server Web front-end.
Anche in questo caso SQL Server non è un fattore limitante perché l'aggiunta del secondo server Web front-end riporta a un'implementazione lineare della scalabilità. Si sta comunque raggiungendo il 90% di utilizzo della CPU nell'istanza di SQL Server. La capacità aggiuntiva rimasta è perciò molto ridotta. Se fosse necessario aggiungere un quinto computer Access Data Services, probabilmente il computer SQL Server diventerebbe il collo di bottiglia.
.gif "SQL %CPU e ADS")
Risultati dettagliati
Nelle tabelle seguenti sono riportati i risultati dettagliati per le configurazioni consigliate.
| Globale | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
Richieste al secondo |
14,96 |
28,76 |
45,22 |
48,01 |
14,85 |
28,77 |
58,02 |
Test al secondo |
2,00 |
3,81 |
6,11 |
6,42 |
1,99 |
3,81 |
7,80 |
Latenza media |
235,80 |
241,21 |
247,21 |
244,87 |
240,70 |
242,26 |
250,94 |
| Media del livello server Web front-end | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
13,82 |
24,40 |
41,02 |
43,62 |
6,31 |
12,48 |
26,18 |
Numero massimo byte privati w3wp |
9,46E+08 |
2,31E+08 |
1,49E+09 |
1,55E+09 |
8,43E+08 |
9,84E+08 |
1,19E+09 |
| Media del livello server applicazioni (Access Data Services) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
46,30 |
42,83 |
43,74 |
34,51 |
46,56 |
43,45 |
42,13 |
% CPU w3wp |
33,61 |
31,15 |
30,71 |
24,29 |
33,48 |
31,64 |
29,72 |
% CPU RS |
8,62 |
7,94 |
9,17 |
6,84 |
9,03 |
8,02 |
8,71 |
Numero massimo byte privati totali |
4,80E+09 |
4,89E+09 |
4,91E+09 |
4,62E+09 |
5,32E+09 |
4,82E+09 |
5,07E+09 |
Numero massimo byte privati w3wp |
2,10E+09 |
1,97E+09 |
2,04E+09 |
1,86E+09 |
2,00E+09 |
2,00E+09 |
2,07E+09 |
Numero massimo byte privati RS |
1,78E+09 |
2,00E+09 |
1,97E+09 |
1,86E+09 |
2,30E+09 |
1,89E+09 |
2,02E+09 |
| Livello server di database (SQL Server) (computer singolo) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
12,07 |
18,64 |
32,53 |
36,05 |
9,89 |
21,42 |
47,46 |
Media byte privati |
2,96E+10 |
3,22E+10 |
3,25E+10 |
3,25E+10 |
2,89E+10 |
3,22E+10 |
3,25E+10 |
Numero massimo byte privati |
3,26E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
Lunghezza media coda dischi totale |
0,74 |
1,18 |
1,64 |
1,77 |
0,67 |
1,24 |
2,18 |
Nelle tabelle seguenti sono riportati i risultati dettagliati per le configurazioni massime.
| Globale | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
Richieste al secondo |
14,96 |
28,76 |
45,22 |
48,01 |
14,85 |
28,77 |
58,02 |
Test al secondo |
2,00 |
3,81 |
6,11 |
6,42 |
1,99 |
3,81 |
7,80 |
Latenza media |
235,80 |
241,21 |
247,21 |
244,87 |
240,70 |
242,26 |
250,94 |
| Media del livello server Web front-end | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
13,82 |
24,40 |
41,02 |
43,62 |
6,31 |
12,48 |
26,18 |
Numero massimo byte privati w3wp |
9,46E+08 |
2,31E+08 |
1,49E+09 |
1,55E+09 |
8,43E+08 |
9,84E+08 |
1,19E+09 |
| Media del livello server applicazioni (Access Data Services) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
46,30 |
42,83 |
43,74 |
34,51 |
46,56 |
43,45 |
42,13 |
% CPU w3wp |
33,61 |
31,15 |
30,71 |
24,29 |
33,48 |
31,64 |
29,72 |
% CPU RS |
8,62 |
7,94 |
9,17 |
6,84 |
9,03 |
8,02 |
8,71 |
Numero massimo byte privati totali |
4,80E+09 |
4,89E+09 |
4,91E+09 |
4,62E+09 |
5,32E+09 |
4,82E+09 |
5,07E+09 |
Numero massimo byte privati w3wp |
2,10E+09 |
1,97E+09 |
2,04E+09 |
1,86E+09 |
2,00E+09 |
2,00E+09 |
2,07E+09 |
Numero massimo byte privati RS |
1,78E+09 |
2,00E+09 |
1,97E+09 |
1,86E+09 |
2,30E+09 |
1,89E+09 |
2,02E+09 |
| Livello server di database (SQL Server) (computer singolo) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
12,07 |
18,64 |
32,53 |
36,05 |
9,89 |
21,42 |
47,46 |
Media byte privati |
2,96E+10 |
3,22E+10 |
3,25E+10 |
3,25E+10 |
2,89E+10 |
3,22E+10 |
3,25E+10 |
Numero massimo byte privati |
3,26E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
Lunghezza media coda dischi totale |
0,74 |
1,18 |
1,64 |
1,77 |
0,67 |
1,24 |
2,18 |
Suggerimenti
In questa sezione vengono forniti suggerimenti di carattere generale sulle prestazioni e sulla capacità.
La capacità e le prestazioni di Access Services dipendono in modo significativo dalla struttura delle applicazioni ospitate nel servizio. A incidere sono soprattutto la dimensione delle tabelle e la complessità delle query. Per il testing sono state utilizzate dimensioni e complessità rappresentative, ma ogni applicazione e ogni set di dati è diverso. La capacità e le prestazioni pertanto varieranno in base alle applicazioni in uso, al relativo grado di complessità specifico e alla dimensione dei dati.
Suggerimenti sui componenti hardware
Access Services si avvale di hardware standard sia per i server Web front-end che per i server applicazioni. Non sono pertanto necessari componenti speciali. Per i computer al livello di server applicazioni (Access Data Services) si applicano le linee guida generali di SharePoint Server 2010 relativamente al numero di CPU, alla velocità e alla memoria.
Topologie con scalabilità verticale e orizzontale
Per aumentare la capacità e le prestazioni di una delle topologie di partenza, è possibile procedere in due modi. È possibile implementare la scalabilità verticale aumentando la capacità dei server esistenti oppure implementare la scalabilità orizzontale aggiungendo ulteriori server alla topologia. In questa sezione vengono descritte le caratteristiche di prestazioni generali di diverse topologie con scalabilità orizzontale.
Le topologie di esempio rappresentano le modalità comuni seguenti di implementazione della scalabilità orizzontale per uno scenario di Access Services:
Per fornire maggiore carico utente, verificare la CPU per i server applicazioni Access Services esistenti. Aggiungere ulteriori CPU o core oppure entrambi a tali server, se possibile. Aggiungere ulteriori computer server Access Services in base alle necessità. Procedere in questo modo finché il server Web front-end non diventa il collo di bottiglia, quindi aggiungere i server Web front-end necessari.
Nei test eseguiti la memoria al livello di server Web front-end e di server applicazioni (Access Data Services) non era un collo di bottiglia. A seconda delle dimensioni dei set di risultati, la memoria può diventare un problema, anche se questa in genere non è la norma. Tenere traccia dei byte privati per il processo w3wp di Access Data Services, come descritto qui.
Nei test eseguiti SQL Server non era un collo di bottiglia. Tali test tuttavia sono stati eseguiti in isolamento rispetto ad altri servizi di SharePoint Server 2010. È opportuno monitorare la CPU e l'I/O su disco per SQL Server e aggiungere ulteriori server o assi in base alle necessità.
Impostazioni di Access Services relative alle prestazioni
Un modo per controllare le caratteristiche di prestazioni di Access Services è quello di limitare la dimensione e la complessità delle query che possono essere eseguite. Access Services offre una serie di colli di bottiglia configurabili per controllare le query. Ognuna delle query seguenti può essere impostata mediante Amministrazione centrale SharePoint. A tale scopo, nella sezione Gestione applicazioni fare clic su Gestisci applicazioni di servizio e quindi su Access Services.
La quantità di dati da recuperare da SharePoint per eseguire una query in genere ha un impatto significativo sulle prestazioni. Per controllarla, è possibile procedere in diversi modi. È innanzitutto possibile limitare gli input per una query:
Numero massimo origini per query
Numero massimo record per tabella
In secondo luogo è possibile limitare la dimensione risultante di una query:
Numero massimo colonne per query
Numero massimo righe per query
Consenti outer join
Oltre alla dimensione della query (dimensione dei dati in ingresso e in uscita), è possibile controllare la complessità di elaborazione dei dati allo scopo di ridurre il carico sulla CPU al livello di server applicazioni (Access Data Services):
Numero massimo colonne calcolate per query
Numero massimo clausole ORDER BY per query
Le impostazioni precedenti ovviamente influiranno sulle applicazioni che possono essere eseguite nel server. Ad esempio, se un'applicazione viene scritta con 40 colonne di output di una query e le impostazioni sono inferiori a tale livello, l'applicazione genererà un errore di runtime. È necessario trovare il giusto compromesso tra le necessità degli utenti e un livello accettabile di prestazioni e questo dipende soprattutto dal tipo di applicazioni Access che si prevede di eseguire nella farm.
È anche possibile adottare un'ulteriore misura più estrema. SharePoint Server 2010 supporta una serie di operazioni di query in modo nativo, che Access Services estende in modo da coprire una gamma più vasta di scenari applicativi. Affinché Access Services migliori le query di SharePoint, è possibile che una grande quantità di dati debba essere recuperata dal database del contenuto di SharePoint. È invece possibile impostare Access Services in modo da vincolarlo alle sole operazioni di query, che possono essere supportate in modo nativo da SharePoint, evitando il recupero dei dati necessario per operazioni più complesse:
- Consenti query non utilizzabili in remoto
Ottimizzazioni
Comuni colli di bottiglia e relative cause
Durante i test delle prestazioni si sono manifestati diversi colli di bottiglia comuni. Un collo di bottiglia è una condizione in cui viene raggiunto il limite di capacità di un singolo componente di una farm. Questa situazione dà origine a un ristagno o a una diminuzione della velocità effettiva della farm.
Nella tabella riportata in Risoluzione dei problemi più avanti in questo articolo vengono elencati alcuni colli di bottiglia comuni e vengono descritte le relative cause con le possibili soluzioni.
Monitoraggio delle prestazioni
Per determinare quando è necessario implementare la scalabilità verticale o orizzontale per il sistema, utilizzare i contatori delle prestazioni per monitorare l'integrità del sistema. Utilizzare le informazioni riportate nelle tabelle seguenti per stabilire quali contatori delle prestazioni monitorare e a quale processo applicarli.
Server Web front-end
Nella tabella riportata di seguito sono indicati i contatori delle prestazioni e i processi da monitorare per i server Web della farm.
| Contatore delle prestazioni | Oggetto a cui si applica | Note |
|---|---|---|
% tempo processore |
Processor(_Total) |
Indica la percentuale del tempo trascorso in cui il thread corrente ha utilizzato il processore per eseguire istruzioni. |
Byte privati |
Process(w3wp) |
Questo valore non deve avvicinarsi al numero massimo di byte privati impostato per i processi w3wp. In caso affermativo, è necessario eseguire ulteriori indagini sul componente che utilizza la memoria. |
Access Data Services
Nella tabella riportata di seguito sono indicati i contatori delle prestazioni e i processi da monitorare per i server applicazioni, o Access Data Services (Access Data Services) in questo caso, all'interno della farm.
| Contatore delle prestazioni | Oggetto a cui si applica | Note |
|---|---|---|
% tempo processore |
Processor(_Total) |
Indica la percentuale del tempo trascorso in cui il thread corrente ha utilizzato il processore per eseguire istruzioni. |
% tempo processore |
Process(w3wp) |
Access Data Services viene eseguito all'interno del relativo processo w2wp ed è ovvio di quale processo w2wp si tratti perché otterrà la maggior parte del tempo di CPU. |
Lunghezza media coda dischi |
PhysicalDisk(_Total) |
Controllare eventuali situazioni in cui le operazioni di scrittura su disco sono eccessive a causa della registrazione. |
% tempo processore |
Process(ReportingServicesService) |
I report vengono gestiti da SQL Server Reporting Services. Se vengono eseguiti troppi report o se i report sono molto complessi, i valori relativi alla CPU e ai byte privati per questo processo saranno elevati. |
Byte privati |
Process(w3wp) |
Access Services memorizza nella cache i risultati delle query finché la sessione dell'utente non scade (in base al timeout configurabile). Se si elabora una grande quantità di dati mediante Access Data Services, aumenterà l'utilizzo della memoria per il processo w3wp di Access Data Services. |
Byte privati |
Process(ReportingSrevicesService) |
I report vengono gestiti da SQL Server Reporting Services. Se vengono eseguiti troppi report o se i report sono molto complessi, i valori relativi alla CPU e ai byte privati per questo processo saranno elevati. |
Server di database
Nella tabella riportata di seguito sono indicati i contatori delle prestazioni e i processi da monitorare per i server di database della farm.
| Contatore delle prestazioni | Oggetto a cui si applica | Note |
|---|---|---|
% tempo processore |
Processor(_Total) |
Indica la percentuale del tempo trascorso in cui il thread corrente ha utilizzato il processore per eseguire istruzioni. |
% tempo processore |
Process(sqlservr) |
Valori medi superiori all'80% indicano che la capacità del processore nel server di database non è sufficiente. |
Byte privati |
Process(sqlservr) |
Indica la quantità media di memoria utilizzata da SQL Server. |
Lunghezza media coda dischi |
PhysicalDisk(_Total) |
Indica la lunghezza media della coda dischi, ovvero le richieste di database in attesa del commit su disco. Questo è spesso un buon indicatore di un prossimo sovraccarico dell'istanza di SQL Server e della necessità di ulteriori assi del disco per distribuire il carico. |
Risoluzione dei problemi
Nella tabella riportata di seguito vengono elencati alcuni colli di bottiglia comuni con le relative cause e le possibili soluzioni.
| Collo di bottiglia | Causa | Soluzione |
|---|---|---|
CPU di Access Data Services |
Access Services dipende da un elevato volume di elaborazione al livello di server applicazioni. Se viene utilizzata una configurazione 1x1, 1x2 o 1x3, il primo collo di bottiglia rilevato sarà probabilmente la CPU nei server CPU. |
Aumentare il numero delle CPU o dei core oppure di entrambi nei computer Access Data Services esistenti. Aggiungere ulteriori computer Access Data Services, se possibile. |
Utilizzo della CPU dei server Web |
Quando un server Web è sovraccarico di richieste utente, l'utilizzo medio della CPU si avvicina al 100%. Questa condizione impedisce al server Web di rispondere rapidamente alle richieste e può causare timeout e messaggi di errore nei computer client. |
Per risolvere questo problema, è possibile procedere in due modi. È possibile aggiungere altri server Web alla farm per distribuire il carico utente oppure implementare la scalabilità verticale per uno o più server Web aggiungendo processori più veloci. |
I/O su disco del server di database |
Quando il numero di richieste di I/O per un disco rigido supera la capacità di I/O del disco, le richieste vengono accodate. Ne deriva un aumento del tempo necessario per completare ogni richiesta. |
La distribuzione dei file di dati su più unità fisiche consente l'I/O parallelo. Nel blog Allocazione e I/O del disco di SharePoint (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x410) (le informazioni potrebbero essere in lingua inglese) sono disponibili informazioni utili sulla risoluzione di problemi relativi all'I/O del disco. |
Utilizzo della CPU di Reporting Services |
Il processo Reporting Services utilizza una vasta parte delle risorse di CPU. |
Dedicare un computer a Reporting Services, spostando il carico dal livello dei server applicazioni (Access Data Services) (modalità connessa) o dei server Web front-end (modalità locale). |