Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Lo strumento PAL (Analisi delle prestazioni dei log) legge un log dei contatori di Monitoraggio Prestazioni (qualsiasi formato noto) e lo analizza usando soglie complesse ma conosciute (fornite). Lo strumento genera un report basato su HTML che consente di tracciare grafici importanti contatori delle prestazioni e genera avvisi quando vengono superate le soglie. Le soglie sono originariamente basate sulle soglie definite dai team dei prodotti Microsoft, inclusi BizTalk Server e membri del supporto Tecnico Microsoft. Questo strumento non è una sostituzione dell'analisi delle prestazioni tradizionale, ma automatizza l'analisi dei log dei contatori delle prestazioni sufficientemente da risparmiare tempo. Lo strumento PAL
Analizza i log dei contatori delle prestazioni per le soglie
È utile per i log perfmon di grandi dimensioni
Identifica i colli di bottiglia del contatore delle prestazioni di BizTalk Server e del sistema operativo analizzando le soglie
Estendibile per eseguire l'analisi su qualsiasi contatore delle prestazioni
Può essere usato per aiutare a scrivere un contatore personalizzato
Pal è disponibile come download gratuito in GitHub. Richiede Microsoft Log Parser. Log Parser è uno strumento potente e versatile che consente l'accesso universale alle query ai dati basati su testo, ad esempio file di log, file XML e file CSV, nonché origini dati chiave nel sistema operativo Windows, ad esempio il registro eventi, il registro, il file system e il servizio directory di Active Directory®. È possibile usare questo strumento per eseguire query su una quantità significativa di informazioni di registrazione. È possibile scaricare lo strumento Parser log.
Uso di PAL con i log dei contatori delle prestazioni in lingue diverse
Lo strumento PAL analizza i log dei contatori delle prestazioni solo in lingua inglese. Per usare lo strumento PAL con i log dei contatori di prestazioni in altre lingue, prima di tutto, è necessario tradurre i log in inglese. È possibile usare Perfmon Log Translator per convertire i file di log dei contatori delle prestazioni originali in inglese.
Informazioni sul report del PAL Tool per Microsoft BizTalk Server 2010
Lo strumento PAL fornisce l'analisi delle soglie dei log di Perfmon per il sistema operativo Windows, Microsoft SQL Server e BizTalk Server. Questa sezione descrive la maggior parte delle analisi nel report di soglia di BizTalk Server nello strumento PAL.
Annotazioni
Questo argomento è lungo in modo che le informazioni complete sullo strumento PAL possano essere contenute in un'unica posizione per un semplice riferimento.
L'analisi e le soglie seguenti vengono segnalate dallo strumento PAL.
Tipo e nome di analisi | Descrizione dell'analisi |
---|---|
Disco: spazio libero su disco per un dump di kernel | Questa analisi verifica che sia disponibile spazio su disco sufficiente per il sistema operativo per eseguire il dump di tutta la memoria su disco. Se è disponibile spazio su disco insufficiente, il sistema operativo non riuscirà a creare un memory.dmp, file necessario per analizzare la causa radice di un dump del kernel. |
Disco: analisi dell'interfaccia disco logico/fisico | Questa analisi esamina il tempo di inattività di ognuno dei dischi fisici. Maggiore è l'inattività del disco, minore è il numero di utilizzo del disco. Questo contatore viene usato meglio quando viene usato un disco nel disco logico. "% tempo di inattività" indica la percentuale di tempo durante l'intervallo di campionamento in cui il disco era inattivo. Riferimento: Escludere i problemi di Disk-Bound |
Disco: analisi della latenza di lettura/scrittura disco logico/fisico | Il modo più affidabile affinché Windows rilevi un collo di bottiglia nelle prestazioni del disco è misurare i tempi di risposta. Se i tempi di risposta sono maggiori di 025 (25 millisecondi), ovvero una soglia conservativa, possono verificarsi problemi di rallentamento e prestazioni che interessano gli utenti. Per altre informazioni, vedere Analisi della latenza di lettura/scrittura su disco logico/fisico in questo argomento. |
Disco: trasferimenti di dischi logici/sec | "Trasferimenti disco/sec" è la frequenza di operazioni di lettura e scrittura sul disco. Le soglie per questa analisi controllano se uno dei dischi logici mostra tempi di risposta scarsi (maggiori di 25 ms di tempi di risposta per le operazioni di I/O). Se questo è vero, i trasferimenti del disco al secondo devono essere pari o superiori a 80. In caso contrario, è necessario analizzare l'architettura del disco. La causa più comune dei problemi di I/O del disco è l'overload LUN sulla SAN. Per altre informazioni, vedere Trasferimenti di dischi logici/sec in questo argomento. |
Disco: LogicalDisk % spazio disponibile | "% spazio disponibile" è la percentuale di spazio utilizzabile totale disponibile nell'unità disco logica selezionata. Le prestazioni non devono essere influenzate fino a quando lo spazio disponibile sull'unità disco non è inferiore al 30%. Quando si usa il 70% dell'unità disco, lo spazio disponibile rimanente si trova più vicino allo spindle del disco al centro dell'unità disco, che opera a un livello di prestazioni inferiore. La mancanza di spazio libero su disco può causare prestazioni gravi del disco. |
Disco: Analisi delle operazioni dati I/O del processo/sec e delle operazioni di altro tipo del processo I/O/sec | Questi contatori contano tutte le attività di I/O generate dal processo per includere file, rete e I/O del dispositivo. Queste analisi controllano quando i processi eseguono più di 1.000 operazioni di I/O al secondo e lo contrassegnano come avviso. Queste analisi vengono usate in modo ottimale in correlazione con altre analisi, ad esempio l'analisi del disco, per determinare quali processi potrebbero essere coinvolti nell'attività di I/O. |
Memoria: memoria disponibile | Questa analisi controlla se la memoria totale disponibile è bassa: avviso a livello del 10 percento di disponibilità e critico a livello del 5 percento di disponibilità. Viene inoltre visualizzato un avviso quando viene rilevata una tendenza decrescente di 10 MB all'ora, che può indicare una potenziale condizione di memoria futura. La memoria fisica insufficiente può causare un aumento della CPU e dei ritardi di sistema in modalità privilegiata. Per altre informazioni, vedere Available MemoryAnalysis in questo argomento. |
Memoria: voci della tabella della pagina di sistema libera | Le voci della tabella delle pagine di sistema libere (PTE) sono il numero di voci della tabella di pagina non attualmente usate dal sistema. Questa analisi determina se il sistema sta esaurendo i PTE verificando se ci sono meno di 5.000 PTE liberi, viene generato un avviso se ci sono meno di 10.000 PTE liberi. La mancanza di un numero sufficiente di PTE può causare problemi di blocco a livello di sistema. Si noti anche che l'opzione /3GB ridurrà in modo significativo la quantità di PTE disponibili. Per altre informazioni, vedere Free System Page Table Entries Analysis in questo argomento. |
Memoria: rilevamento delle perdite di memoria | Questa analisi determina se uno dei processi utilizza una grande quantità di memoria del sistema e se il processo aumenta nel tempo. Un processo che consuma grandi porzioni di memoria è corretto, purché il processo restituisca la memoria al sistema. Cercare tendenze crescenti nel grafico. Una tendenza crescente in un lungo periodo di tempo potrebbe indicare una perdita di memoria. "Byte privati" è la dimensione corrente, in byte, della memoria allocata da questo processo che non può essere condivisa con altri processi. Questa analisi controlla le tendenze crescenti di 10 MB all'ora e di 5 MB all'ora. Usare questa analisi in correlazione con l'analisi della memoria disponibile in PAL. Per ulteriori informazioni, consultare l'analisi della individuazione di perdite di memoria in questo argomento. |
Memoria: gestire il rilevamento delle perdite | Questa analisi controlla tutti i processi per determinare quanti handle ciascuno ha aperti e verificare se si sospetta una perdita di handle. Un processo con un numero elevato di handle e/o una tendenza aggressiva verso l'alto potrebbe segnalare una perdita di handle, che in genere comporta una perdita di memoria. Il numero totale di handle attualmente aperti da questo processo è uguale alla somma degli handle attualmente aperti da ogni thread in questo processo. Riferimento: Strumento di Debug e Diagnostica |
Memoria: pagine di memoria immesse/sec | "Input pagine/sec" è la frequenza con cui le pagine vengono lette dal disco per risolvere gli errori della pagina disco rigido. Gli errori di pagina rigida si verificano quando un processo fa riferimento a una pagina in memoria virtuale che non si trova nel set di lavoro o altrove nella memoria fisica e deve essere recuperata dal disco. Questa analisi controlla se sono presenti più di 10 letture di file di pagina al secondo. |
Memoria: pagine di memoria/sec | Questa analisi verifica se "Pages/sec" è elevato (superiore a 1.000). Se è elevato, è probabile che il sistema esaurisca la memoria tentando di trasferire la memoria sul disco. "Pagine/sec" è la frequenza con cui le pagine vengono lette o scritte su disco per risolvere gli errori di pagina disco rigido. Questo contatore è un indicatore principale dei tipi di errori che causano ritardi a livello di sistema. Usare questa analisi in correlazione con l'analisi della memoria disponibile e l'analisi rilevamento perdite di memoria in PAL. Se tutte queste analisi generano avvisi contemporaneamente, questo potrebbe indicare che il sistema stia esaurendo la memoria e i processi sospetti coinvolti; seguire i passaggi di analisi menzionati nell'analisi Rilevamento Perdite di Memoria in PAL. Per ulteriori informazioni, consultare "Analisi pagine di memoria/sec" in questo argomento. |
Byte residenti della cache del sistema di memoria | "Byte residenti nella cache di sistema" è la dimensione, espressa in byte, del codice del sistema operativo paginabile nella cache del file system. Questo valore include solo le pagine fisiche correnti e non include le pagine di memoria virtuale che attualmente non sono residenti. Questo valore è un componente di "Memory\\System Code Resident Bytes" che rappresenta tutto il codice del sistema operativo paginabile attualmente in memoria fisica. Questo contatore visualizza solo l'ultimo valore osservato; non è una media. Questa analisi verifica una tendenza crescente di 10 MB all'ora. In fase di caricamento, un server potrebbe usare la cache di sistema per memorizzare nella cache le attività di I/O, come quella su disco. Usare in correlazione con l'analisi delle "Process IO Data Operations/sec" e "Process IO Other Operations/sec" in PAL. Riferimento: Prestazioni e ottimizzazione della cache dei file |
Memoria: Byte non paginati del pool | "Pool Nonpaged Bytes" è la dimensione, in byte, del pool di memoria non paginata, un'area di memoria di sistema per gli oggetti che non possono essere scritti su disco, ma devono rimanere in memoria fisica finché sono allocati. Questa analisi verifica se il sistema sta arrivando vicino alla dimensione massima della memoria non paginata del pool. A tale scopo, si stimano le dimensioni del pool tenendo in considerazione i 3 GB, la dimensione della memoria fisica e il contesto a 32/64 bit, per poi determinare se il valore supera il 60% delle dimensioni stimate del pool. Se il sistema si avvicina alla dimensione massima, potrebbe subire blocchi a livello di sistema. L'opzione /3GB nel file boot.ini riduce significativamente le dimensioni di questo pool di memoria. Per ulteriori informazioni, fare riferimento a "Analisi dei Byte Non Paginati del Pool" in questo argomento. |
Memoria: Pool di byte paginati | Questa analisi verifica se il sistema si sta avvicinando alla dimensione massima del pool di memoria di paging. Ciò avviene stimando le dimensioni del pool prendendo in considerazione /3GB, la dimensione della memoria fisica e 32 bit/64 bit e determinando se il valore è superiore al 60 percento delle dimensioni stimate del pool. Se il sistema si avvicina alla dimensione massima, potrebbero verificarsi blocchi a livello generale. Opzione /3GB nel file boot.ini riduce significativamente le dimensioni di questo pool di memoria. Per altre informazioni, vedere Pool Paged Bytes Analysis in questo argomento. |
Memoria: Conteggio thread del processo | Questa analisi controlla tutti i processi per determinare se un processo ha più di 500 thread e se il numero di thread aumenta di 50 thread all'ora. Un processo con un numero elevato di thread e/o una tendenza aggressiva verso l'alto potrebbe indicare una perdita di thread che in genere comporta una perdita di memoria o un cambio di contesto elevato. Il cambio di contesto elevato porterà la CPU a operare in modalità a privilegi elevati. |
Memoria: Working Set del processo | "Working Set" è la dimensione corrente, espressa in byte, del working set di questo processo. Il working set è l'insieme delle pagine di memoria recentemente utilizzate dai thread del processo. Se la memoria libera nel computer supera una soglia, le pagine vengono lasciate nel working set di un processo anche se non sono in uso. Quando la memoria libera scende al di sotto di una soglia, le pagine vengono ridotte dai set di lavoro. Se sono necessari, verranno reintrodotti nel working set tramite un errore minore prima di essere rimossi dalla memoria principale. Questa analisi verifica una tendenza crescente di 10 MB o più in ognuno dei processi. Usare in correlazione con l'analisi della memoria disponibile in PAL. Riferimento: Ricerca ed eliminazione di colli di bottiglia |
Rete: analisi della lunghezza della coda di uscita di rete | Questa analisi verifica il numero di thread in attesa sulla scheda di rete. Se molti thread sono in attesa sulla scheda di rete, il sistema sta probabilmente saturando l'I/O di rete a causa della latenza di rete o della larghezza di banda di rete. La "lunghezza della coda di output" è la lunghezza della coda di pacchetti di output (espressa in pacchetti). I ritardi sono indicati se questo è più lungo di due e il collo di bottiglia deve essere trovato ed eliminato, se possibile. Le cause tipiche dell'accodamento dell'output di rete includono un numero elevato di richieste di rete di piccole dimensioni e latenza di rete. |
Rete: analisi dell'utilizzo della rete | "Byte totali/sec" è la frequenza con cui i byte vengono inviati e ricevuti su ogni scheda di rete, inclusi i caratteri di frame. "Network Interface\Bytes Received/sec" è una somma di "Network Interface\Bytes Received/sec" e "Network Interface\Bytes Sent/sec". Questo contatore consente di sapere se il traffico nella scheda di rete è saturo e se è necessario aggiungere un'altra scheda di rete. La velocità con cui è possibile identificare un problema dipende dal tipo di rete che si ha, nonché dal fatto che si condivide la larghezza di banda con altre applicazioni. Questa analisi converte "Byte totali/sec" in bit e la confronta con la larghezza di banda corrente della scheda di rete per calcolare l'utilizzo della rete. Successivamente, verifica l'utilizzo superiore al 50%. Riferimento: Misurare le prestazioni con EventCounters in .NET Core |
File di paging: Utilizzo % e picco di utilizzo % | Quantità dell'istanza del file di pagina in uso in percentuale. Vedere anche "Process\\Page File Bytes". Questa analisi controlla se la percentuale di utilizzo è maggiore del 70%. |
Processore: analisi dell'utilizzo del processore e uso eccessivo del processore da parte dei processi | Questo contatore è l'indicatore principale dell'attività del processore e visualizza la percentuale media di tempo occupato osservato durante l'intervallo di campionamento. Viene calcolato monitorando il tempo in cui il servizio è inattivo e sottraendo tale valore dal 100%. Questa analisi controlla l'utilizzo maggiore del 60% su ogni processore. In tal caso, determinare se si tratta di cpu in modalità utente elevata o modalità con privilegi elevati. Se si sospetta che la CPU in modalità con privilegi elevati sia sospetta, vedere l'analisi della CPU in modalità privilegiata in PAL. Se si sospetta un collo di bottiglia del processore in modalità utente, è consigliabile usare un profiler di processo per analizzare le funzioni che causano un utilizzo elevato della CPU. |
Processore: Lunghezza della coda del processore | Questa analisi determina se la lunghezza media della coda del processore supera il numero di processori. In tal caso, questo potrebbe indicare un collo di bottiglia del processore. Usare questa analisi in correlazione con l'analisi della CPU in Modalità Privilegiata e l'analisi dell'Uso Eccessivo del Processore da parte dei Processi in PAL. Per informazioni dettagliate, vedere Analisi della lunghezza della coda del processore in questo argomento. |
Processore: Analisi CPU in modalità privilegiata | Questo contatore indica la percentuale di tempo in cui un thread viene eseguito in modalità con privilegi. Quando l'applicazione chiama funzioni del sistema operativo (ad esempio per eseguire operazioni di I/O di rete o per allocare memoria), queste funzioni del sistema operativo vengono eseguite in modalità con privilegi. Questa analisi verifica se la CPU in modalità privilegiata utilizza più del 30% della CPU totale. In tal caso, è probabile che l'utilizzo della CPU sia causato da un altro collo di bottiglia diverso dal processore, ad esempio rete, memoria o I/O del disco. Usare in correlazione con Processore: % Tempo di Interruzione e Processore: Analisi del Cambio di Contesto Elevato in PAL. Per altre informazioni, vedere Analisi della CPU in modalità privilegiata in questo argomento. |
Processore: Tempo di interruzione | "% tempo di interruzione" è il tempo che il processore trascorre ricevendo e gestendo gli interrupt hardware durante gli intervalli di campionamento. Questo valore è un indicatore indiretto dell'attività dei dispositivi che generano interrupt, ad esempio l'orologio di sistema, il mouse, i driver del disco, le linee di comunicazione dati, le schede di interfaccia di rete e altri dispositivi periferici. Questi dispositivi interrompono normalmente il processore quando hanno completato un'attività o richiedono attenzione. L'esecuzione normale del thread viene sospesa durante gli interrupt. La maggior parte degli orologi di sistema interrompe il processore ogni 10 millisecondi, creando uno sfondo di attività di interruzione. Un aumento significativo di questo contatore indica potenziali problemi hardware. Questa analisi verifica se il "% Interrupt Time" è maggiore del 30%. In questo caso, prendere in considerazione l'aggiornamento dei driver di dispositivi per l'hardware correlato a questo avviso. Riferimento: Misurare le prestazioni con EventCounters in .NET Core |
Processore: commutazione di contesto elevata | Un cambio di contesto si verifica quando un thread con priorità più alta impedisce un thread con priorità più bassa attualmente in esecuzione o quando un thread con priorità alta si blocca. I livelli elevati di cambio di contesto possono verificarsi quando molti thread condividono lo stesso livello di priorità. Questo spesso indica che troppi thread sono in competizione per i processori nel sistema. Come regola generale, i tassi di cambio di contesto inferiori a 5.000 al secondo per processore non vale la pena preoccuparsi. Se i tassi di cambio del contesto superano i 15.000 al secondo per processore, esiste un vincolo. Per altre informazioni, vedere Analisi del cambio di contesto elevato in questo argomento. |
Microsoft BizTalk Server: disidratazione delle orchestrazioni di BizTalk | Quando molti processi aziendali a esecuzione prolungata vengono eseguiti contemporaneamente, sono possibili problemi di memoria e prestazioni. Il motore di orchestrazione affronta questi problemi "deidratando" e "reidratando" le istanze di orchestrazione. La disidratazione è il processo di serializzazione dello stato di un'orchestrazione in un database di SQL Server. La reidratazione è il processo inverso: la deserializzazione dell'ultimo stato di esecuzione di un'orchestrazione dal database. La disidratazione viene utilizzata per ridurre al minimo l'uso delle risorse di sistema, diminuendo il numero di orchestrazioni che devono essere istanziate in memoria contemporaneamente. Di conseguenza, le dehyration consentono di risparmiare il consumo di memoria, ma sono operazioni relativamente costose da eseguire. Questa analisi verifica la presenza di disidratazione al 10% o più. In tal caso, BizTalk Server potrebbe esaurire la memoria (virtuale o fisica), un numero elevato di orchestrazioni è in attesa di messaggi o le impostazioni di disidratazione non sono impostate correttamente. Riferimento: Disidratazione e reidratazione dell'orchestrazione |
Microsoft BizTalk Server: sessioni avanzate di database BizTalk | Questo contatore ha due valori possibili: normale (0) o superato (1). Questa analisi verifica la presenza di un valore pari a 1. In tal caso, BizTalk ha superato la soglia del numero di sessioni di database consentite. Questo valore è controllato dal valore "Connessione di database per CPU" nelle impostazioni di limitazione delle richieste dell'host BizTalk. "Connessione al database per CPU" è il numero massimo di sessioni simultanee del database (per CPU) consentite prima che inizi la regolazione. È possibile monitorare il numero di connessioni di database attive usando il contatore delle prestazioni della sessione del database nella categoria dell'oggetto prestazioni BizTalk:Message Agent. Questo parametro influisce solo sulla limitazione dei messaggi in uscita. Per ulteriori informazioni, consultare l'analisi delle sessioni di database ad alta intensità di BizTalk in questo argomento. |
Microsoft BizTalk Server: dimensioni elevate del database BizTalk | Questo contatore verrà impostato su un valore pari a 1 se si verifica una delle condizioni elencate per il conteggio dei messaggi nella soglia del database. Per impostazione predefinita, il numero di messaggi host nella soglia di limitazione del database è impostato su un valore pari a 50.000, che attiverà una condizione di limitazione nelle circostanze seguenti: - Il numero totale di messaggi pubblicati dall'istanza host nelle code di lavoro, di stato e sospese degli host di sottoscrizione supera 50.000. - Il numero di messaggi nella tabella di spooling o nella tabella di rilevamento supera i 500.000 messaggi. In questo caso, prendere in considerazione una linea d'azione che riduca il numero di messaggi nel database. Ad esempio, verificare che i processi di SQL Server in BizTalk Server siano in esecuzione senza errori e usare la pagina Gruppo Hub nella console di amministrazione di BizTalk Server per determinare se l'accumulo dei messaggi è causato da un numero elevato di messaggi sospesi. Per altre informazioni, vedere Analisi delle dimensioni elevate del database BizTalk in questo argomento. |
Microsoft BizTalk Server: BizTalk High In-Process Conteggio Messaggi | Questa analisi controlla il contatore Numero di messaggi elevato In-Process per determinare se si verifica questo tipo di strozzamento. In tal caso, valutare la possibilità di modificare l'impostazione "In-Process messaggi per CPU". Questo parametro influisce solo sulla limitazione dei messaggi in uscita. Immettere il valore 0 nell'impostazione "In-Process messaggi per CPU" per disabilitare la limitazione in base al numero di messaggi in-process per CPU. Il valore predefinito per l'impostazione "In-Process messaggi per CPU" è 1.000. Si noti che la modifica di questo valore può avere anche un impatto sulla bassa latenza dei messaggi e/o sull'efficienza delle risorse BizTalk. Per ulteriori informazioni, consulta BizTalk High In-Process Message Count Analysis in questo argomento. |
Microsoft BizTalk Server: Frequenza di recapito dei messaggi elevata di BizTalk | Questa analisi verifica la presenza di un valore pari a 1 nel contatore Tasso di recapito dei messaggi elevato. Le frequenze di recapito dei messaggi elevate possono essere causate da un'elevata complessità di elaborazione, da schede in uscita lente o da una carenza momentanea di risorse di sistema. Per ulteriori informazioni, consultare l'analisi di BizTalk sui tassi elevati di consegna dei messaggi in questo argomento. |
Microsoft BizTalk Server: Frequenza di pubblicazione messaggi elevata di BizTalk | La limitazione dell'host in ingresso, nota anche come limitazione della pubblicazione di messaggi in BizTalk Server, viene applicata alle istanze host che contengono adapter di ricezione o orchestrazioni che pubblicano messaggi al database MessageBox. Questa analisi verifica la presenza di un valore pari a 1 nel contatore Frequenza elevata di pubblicazione dei messaggi. In questo caso, il database non può tenere il passo con la frequenza di pubblicazione dei messaggi nel database MessageBox BizTalk. Referenze: - Contatori delle prestazioni di limitazione dell'host - Come BizTalk Server implementa la limitazione dell'host - Modificare le impostazioni di limitazione basata sulla frequenza - Che cos'è la strozzatura dell'host? |
Microsoft BizTalk Server: Memoria del Processo Elevata di BizTalk | L'impostazione soglia di limitazione dell'utilizzo della memoria del processo BizTalk corrisponde alla percentuale di memoria usata rispetto alla somma delle dimensioni del working set e alla memoria virtuale totale disponibile per il processo se viene immesso un valore compreso tra 1 e 100. Quando viene specificato un valore percentuale, la soglia di memoria del processo viene ricalcolata a intervalli regolari. Questa analisi verifica la presenza di un valore pari a 1 nel contatore Memoria Processo Elevato. Per altre informazioni, vedere BizTalk High Process Memory Analysis in questo argomento. |
Microsoft BizTalk Server: Elevato utilizzo della memoria di sistema BizTalk | L'impostazione soglia di limitazione dell'utilizzo della memoria fisica BizTalk è la percentuale di consumo di memoria rispetto alla quantità totale di memoria fisica disponibile se viene immesso un valore compreso tra 1 e 100. Questa impostazione può anche essere la quantità totale di memoria fisica disponibile in megabyte se viene immesso un valore maggiore di 100. Immettere un valore di 0 per disabilitare la limitazione in base all'utilizzo della memoria fisica. Il valore predefinito è 0. Per altre informazioni, vedere BizTalk High System Memory Analysis in questo argomento. |
Microsoft BizTalk Server: Conteggio Elevato di Thread BizTalk | "Thread per CPU" è il numero totale di thread nel processo host, inclusi i thread usati dagli adattatori. Se questa soglia viene superata, BizTalk Server tenterà di ridurre le dimensioni del pool di thread EPM e del pool di thread dell'agente messaggi. La limitazione basata sui thread dovrebbe essere attivata negli scenari in cui un carico elevato può portare alla creazione di un numero elevato di thread. Questo parametro influisce sia sulla regolazione in ingresso che in uscita. La limitazione basata su thread è disabilitata per impostazione predefinita. Per altre informazioni, vedere BizTalk High Thread Count Analysis in questo argomento. |
Microsoft BizTalk Server: Lunghezza della coda host BizTalk | La lunghezza della coda dell'host BizTalk tiene traccia del numero totale di messaggi nella coda dell'host specifico. È possibile usare le dimensioni della lunghezza, ad esempio BizTalk:MessageBox:HostCounters:Host Queue – Length, per offrire una visualizzazione più dettagliata del numero di messaggi accodati internamente mostrando la profondità della coda per un singolo host. Questo contatore può essere utile per determinare se un host specifico è in collo di bottiglia. Supponendo che vengano usati host unici per ciascun trasporto, questo può essere utile per identificare potenziali colli di bottiglia nei trasporti. Questa analisi verifica la lunghezza media della coda maggiore di 1. La lunghezza della coda dell'host è una lunghezza della coda ponderata, ottenuta aggregando il numero di record di tutte le code (Work Q, State Q, Suspended Q) dell'host di destinazione. Riferimento: BizTalk Server 2010: Metodologia di test delle prestazioni di BizTalk Server |
Microsoft BizTalk Server: Lunghezza della coda dei messaggi sospesi dell'host BizTalk | Questo contatore tiene traccia del numero totale di messaggi sospesi per l'host specifico. Un messaggio sospeso è un'istanza di un messaggio o di un'orchestrazione interrotta dall'elaborazione di BizTalk Server a causa di un errore nel sistema o nel messaggio. In genere, le istanze sospese causate da errori di sistema sono ripristinabili alla risoluzione del problema di sistema. Spesso, le istanze sospese a causa di un problema di messaggio non sono ripristinabili e il messaggio stesso deve essere corretto e inviato di nuovo al sistema BizTalk Server. La coda di messaggi sospesa è una coda contenente elementi di lavoro per i quali si è verificato un errore o un errore durante l'elaborazione. Una coda sospesa archivia i messaggi fino a quando non possono essere corretti e rielaborati o eliminati. Questa analisi controlla la presenza di apparizioni di messaggi sospesi. Una tendenza crescente potrebbe indicare errori di elaborazione gravi. Referenze: - Monitoraggio dell'integrità e delle prestazioni di BizTalk Server - Risoluzione dei problemi relativi a Microsoft BizTalk Server |
BizTalk Server: Orchestrazioni inattive di BizTalk | Numero di istanze di orchestrazione inattive attualmente ospitate dall'istanza host. Questo contatore si riferisce a orchestrazioni che non stanno facendo progressi, ma non sono disidratate. Questa situazione può verificarsi quando l'orchestrazione viene bloccata, in attesa di una ricezione, un ascolto o un ritardo in una transazione atomica. Se un numero elevato di orchestrazioni non disidratate si accumula, BizTalk potrebbe esaurire la memoria. La disidratazione è il processo di serializzazione dello stato di un'orchestrazione in un database di SQL Server. La reidratazione è il processo inverso: la deserializzazione dell'ultimo stato di esecuzione di un'orchestrazione dal database. La disidratazione viene utilizzata per ridurre al minimo l'uso delle risorse di sistema, diminuendo il numero di orchestrazioni che devono essere istanziate in memoria contemporaneamente. Il motore disidrata l'istanza salvando lo stato e libera la memoria richiesta dall'istanza. Disidratando istanze di orchestrazione inattiva, il motore consente a un numero elevato di processi aziendali a esecuzione prolungata di eseguire simultaneamente nello stesso computer. Questa analisi verifica una tendenza crescente di un'orchestrazione inattiva ogni ora. Riferimento: deidratazione e reidratazione dell'orchestrazione. |
BizTalk Server: Latenza in ingresso BizTalk | Latenza media in millisecondi da quando il motore di messaggistica riceve un documento dall'adattatore fino a quando non viene pubblicato in MessageBox. La riduzione della latenza è importante per alcuni utenti di BizTalk, pertanto è importante tenere traccia della quantità di tempo trascorsa dai documenti nell'adapter in ingresso. Per ulteriori informazioni, fare riferimento all'Analisi della Latenza in Ingresso di BizTalk all'interno di questo argomento. |
BizTalk Server: Ritardo nella consegna dei messaggi BizTalk | Questo è il ritardo corrente in millisecondi (ms) imposto a ogni batch di recapito dei messaggi (applicabile se il recapito del messaggio è limitato). Per quanto riguarda la limitazione, viene applicato un ritardo nella pubblicazione o nell'elaborazione del messaggio, a seconda che il messaggio sia in ingresso o in uscita. Il periodo di ritardo è proporzionale alla gravità della condizione di strozzamento. Condizioni di limitazione della gravità più elevate avvieranno un periodo di limitazione più lungo rispetto alle condizioni di limitazione della gravità inferiore. Questo periodo di ritardo viene regolato verso l'alto e verso il basso entro determinati intervalli dal meccanismo di limitazione quando cambiano le condizioni. Il periodo di ritardo corrente è esposto tramite i contatori delle prestazioni del ritardo del recapito dei messaggi (ms) e del ritardo di pubblicazione dei messaggi (ms) associati alla categoria dell'oggetto prestazioni BizTalk:Message Agent. Questa analisi verifica la presenza di un ritardo di recapito dei messaggi superiore a 5 secondi. I lunghi ritardi nella consegna dei messaggi possono indicare un forte throttling dovuto a un carico intenso. Riferimento: Come BizTalk Server Implementa la Limitazione dell'Host. |
BizTalk Server: stato di limitazione del recapito dei messaggi BizTalk | Lo stato di limitazione del recapito dei messaggi BizTalk è uno dei principali indicatori di contenimento. Si tratta di un flag che indica se il sistema sta limitando il recapito dei messaggi (che influisce sull'elaborazione dei messaggi XLANG e sui trasporti in uscita). La condizione di limitazione è rappresentata dal valore numerico del contatore. Per ulteriori informazioni, consulta l'analisi dello stato di limitazione della consegna dei messaggi di BizTalk in questo argomento. |
BizTalk Server: Ritardo nella pubblicazione dei messaggi BizTalk | Ritardo inserito in ogni batch di qualificazione per regolare la pubblicazione dei messaggi. Per quanto riguarda la limitazione, viene applicato un ritardo nella pubblicazione o nell'elaborazione del messaggio, a seconda che il messaggio sia in ingresso o in uscita. Il periodo di ritardo è proporzionale alla gravità della condizione di strozzamento. Condizioni di limitazione della gravità più elevate avvieranno un periodo di limitazione più lungo rispetto alle condizioni di limitazione della gravità inferiore. Questo periodo di ritardo viene regolato verso l'alto e verso il basso entro determinati intervalli dal meccanismo di limitazione quando cambiano le condizioni. Il periodo di ritardo corrente è esposto tramite i contatori delle prestazioni del ritardo del recapito dei messaggi (ms) e del ritardo di pubblicazione dei messaggi (ms) associati alla categoria dell'oggetto prestazioni BizTalk:Message Agent. Questa analisi verifica la presenza di un ritardo di pubblicazione dei messaggi superiore a 5 secondi. I lunghi ritardi nella consegna dei messaggi possono indicare un forte throttling dovuto a un carico intenso. Riferimento: Come BizTalk Server Implementa la Limitazione dell'Host. |
BizTalk Server: Errori di connessione al database BizTalk MessageBox | Questo contatore delle prestazioni è il numero di connessioni di database tentate non riuscite dall'avvio dell'istanza host. Se il servizio SQL Server che ospita i database BizTalk non è più disponibile per qualsiasi motivo, il cluster di database trasferisce le risorse dal computer attivo al computer passivo. Durante questo processo di failover, le istanze del servizio BizTalk Server riscontrano errori di connessione al database e riavviano automaticamente per riconnettersi ai database. Il computer di database funzionante (in precedenza il computer passivo) inizia a elaborare le connessioni di database dopo aver assunto le risorse durante il failover. Per altre informazioni, vedere Analisi degli errori di connessione del database MessageBox bizTalk in questo argomento. |
BizTalk Server: Latenza di messaggistica BizTalk: latenza della risposta della richiesta | Latenza media in millisecondi da quando il motore di messaggistica riceve un documento di richiesta dall'adattatore fino al momento in cui un documento di risposta viene restituito all'adattatore. Fare riferimento al grafico che mostra come viene misurata la latenza nell'analisi della latenza in ingresso bizTalk in questo argomento. Supponendo un ambiente a bassa latenza, questa analisi verifica la presenza di una latenza Request-Response maggiore di 5 secondi. Ciò può indicare un ritardo di elaborazione tra l'adattatore in ingresso e l'adattatore in uscita. Referenze: - Messaggistica richiesta/risposta - Ridimensionamento delle soluzioni |
BizTalk Server: stato di limitazione della pubblicazione dei messaggi BizTalk | Lo stato di limitazione della pubblicazione dei messaggi BizTalk è uno degli indicatori principali della limitazione. È un flag che indica se il sistema sta limitando la pubblicazione dei messaggi (che influisce sull'elaborazione dei messaggi XLANG e sui trasporti in ingresso). Per ulteriori informazioni, consultare l'analisi dello stato di limitazione della pubblicazione dei messaggi BizTalk in questo argomento. |
BizTalk Server: BizTalk Orchestration Sospeso al secondo | Un messaggio sospeso è un'istanza di un messaggio o di un'orchestrazione interrotta dall'elaborazione di BizTalk Server a causa di un errore nel sistema o nel messaggio. In genere, le istanze sospese causate da errori di sistema sono ripristinabili alla risoluzione del problema di sistema. Spesso, le istanze sospese a causa di un problema di messaggio non sono ripristinabili e il messaggio stesso deve essere corretto e inviato di nuovo al sistema BizTalk Server. Questa analisi verifica la presenza di messaggi/orchestrazioni sospesi. Referenze: - Monitoraggio dell'integrità e delle prestazioni di BizTalk Server - Risoluzione dei problemi relativi a Microsoft BizTalk Server |
BizTalk Server: Orchestrazioni BizTalk completate per secondo | Questo è il numero di orchestrazioni BizTalk completate per secondo. Si tratta di un buon indicatore della velocità effettiva di elaborazione di BizTalk. Questa analisi fornisce solo statistiche. Riferimento: Ridimensionamento delle soluzioni |
BizTalk Server: Orchestrazioni BizTalk scartate | Numero di istanze di orchestrazione eliminate dalla memoria dall'avvio dell'istanza host. Un'orchestrazione può essere eliminata se il motore non riesce a mantenere lo stato. Questa analisi verifica la presenza di eventuali messaggi rimossi. Riferimento: WebLog del motore BizTalk Core |
BizTalk Server: orchestrazioni BizTalk residenti in memoria | Numero di istanze di orchestrazione attualmente ospitate dall'istanza host. Questa analisi verifica una tendenza crescente nelle orchestrazioni residenti in memoria e se più del 50% delle orchestrazioni residenti in memoria non sono disidratate. Per ulteriori informazioni, fare riferimento a BizTalk Orchestrations Resident in Memory Analysis. |
BizTalk Server: latenza dell'adapter bizTalk in uscita | Si tratta della latenza media in secondi da quando l'adattatore ottiene un documento dal motore di messaggistica fino al momento in cui viene inviato dall'adattatore. Fare riferimento al grafico che mostra come viene misurata la latenza nell'analisi della latenza in ingresso bizTalk in questo argomento. Supponendo un ambiente a bassa latenza, questa analisi verifica la latenza nell'adattatore in uscita superiore a 5 secondi in media. Ciò può indicare un ritardo di elaborazione nel trasporto dei messaggi tramite adattatori in uscita in questa istanza host. Se in questa istanza host esistono più adattatori in uscita, è consigliabile separarli nei propri host per determinare quale scheda in uscita ha una latenza elevata. Riferimenti: - Messaggistica richiesta/risposta. - BizTalk Server 2006: case study sulla scalabilità tramite l'adapter SOAP in BizTalk Server 2006 - Identificazione dei colli di bottiglia nel livello BizTalk - Ottimizzazione dello scenario diLow-Latency per BizTalk Server |
BizTalk Server: Messaggi in sospeso di BizTalk | Numero di messaggi ricevuti che non sono stati riconosciuti come ricevuti nel MessageBox. I messaggi in sospeso sono messaggi che sono stati estratti in memoria e recapitati all'orchestrazione XLANG, ma non sono ancora stati elaborati. Questa circostanza non ha nulla a che fare con la perdita di dati. Il recapito di un messaggio a un'orchestrazione è un processo in più passaggi ed è semplicemente un'istanza del messaggio che risiede nella tabella spool nel database. Questi messaggi in sospeso vengono conteggiati come messaggi in-process; pertanto, avere un numero elevato in memoria potrebbe causare un sovraccarico della memoria nel sistema. La regolazione del parametro Dimensioni coda messaggi interni può essere utile per controllare il numero di messaggi in sospeso. L'impostazione In-Process Messaggi per CPU influisce su quando verrà attivata la limitazione, nel caso di un numero elevato di messaggi in sospeso. Queste impostazioni sono disponibili nelle proprietà host della Console di amministrazione BizTalk. Questa analisi controlla solo le statistiche per questo contatore. Riferimento: Contatori delle Prestazioni del Motore di Orchestrazione. |
BizTalk Server: Punti di persistenza BizTalk al secondo | Numero medio di istanze di orchestrazione persistenti al secondo. Il motore di orchestrazione salva lo stato di un'istanza di orchestrazione in esecuzione in diversi momenti. Se è necessario riattivare l'istanza di orchestrazione, avviare da un arresto controllato o eseguire il ripristino da un arresto imprevisto, eseguirà l'istanza di orchestrazione dall'ultimo punto di persistenza. Per rendere persistente un'istanza di orchestrazione, tutte le istanze dell'oggetto a cui fa riferimento l'orchestrazione devono essere serializzabili direttamente o indirettamente (come tramite altri oggetti). Man mano che la frequenza di persistenza dei messaggi (il numero di volte in cui i dati devono essere salvati in modo permanente) aumenta, le prestazioni complessive diminuiscono. In effetti, ogni punto di persistenza è un round trip al database, quindi, quando possibile ridurre la frequenza dei punti di persistenza evitando o consolidando i punti di persistenza. Per altre informazioni sul momento in cui si verificano i punti di persistenza, vedere i riferimenti seguenti. Questa analisi verifica in media più di 10 punti di persistenza al secondo. Questo è un punto di partenza generale. Riferimenti: - Persistenza nelle orchestrazioni - Persistenza e motore di orchestrazione |
BizTalk Server: Byte riservati BizTalk | Si tratta dei megabyte di memoria privata allocata per l'istanza host e paragonabile al contatore delle prestazioni "\Process(*)\Private Bytes". Questa analisi determina se una delle istanze host sta consumando un'ampia quantità di memoria del sistema e se il consumo di memoria dell'istanza host aumenta nel tempo. Per altre informazioni, vedere BizTalk Private Bytes Analysis in questo argomento. |
BizTalk Server: Dimensioni della tabella Spool di BizTalk | La tabella di spooling della MessageBox contiene un record per ogni messaggio nel sistema (attivo o in attesa di essere eliminato). Il monitoraggio del numero di righe in questa tabella e del numero di messaggi ricevuti al secondo, mentre l'aumento del carico di sistema offre un modo semplice per trovare la velocità effettiva massima sostenibile. È sufficiente aumentare il carico di input fino a quando 1) la tabella di spooling inizia a crescere indefinitamente oppure 2) il numero di messaggi ricevuti al secondo si stabilizza, a seconda di quale condizione si verifichi per prima, ed è quella la velocità effettiva massima sostenibile. In sintesi, indipendentemente dagli altri indicatori, questa misura ti darà un modo rapido e semplice per valutare se il sistema è sovraccarico o meno. Quando le dimensioni delle tabelle di spool di BizTalk sono in crescita, è possibile che si verifichi una limitazione a causa di una frequenza di recapito dei messaggi sbilanciata (la velocità di input supera la velocità di output) oppure per via delle dimensioni del database. Questa analisi verifica una tendenza crescente nelle dimensioni delle tabelle di Spool bizTalk. Riferimenti: - Informazioni sulla velocità effettiva e la capacità di BizTalk Server 2004 SP1 - Test di carico sostenibile - Raccomandazioni durante il test delle prestazioni del motore. |
BizTalk Server: dimensione dei dati di monitoraggio BizTalk | Man mano che BizTalk Server elabora sempre più dati nel sistema, il database di rilevamento BizTalk (BizTalkDTADb) continua a crescere di dimensioni. La crescita deselezionata riduce le prestazioni del sistema e può generare errori nel servizio di distribuzione dei dati di rilevamento (TDDS). Oltre ai dati di rilevamento generali, i messaggi rilevati possono anche accumularsi nel database MessageBox, causando prestazioni del disco scarse. Questa analisi verifica una tendenza crescente di oltre 5 MB all'ora nelle dimensioni dei dati di rilevamento. Riferimento: Archiviazione ed eliminazione del database di rilevamento BizTalk |
BizTalk Server: Ambiti transazionali BizTalk annullati | Questo è il numero di ambiti atomici o a esecuzione prolungata interrotti dall'avvio dell'istanza host. Un'interruzione dell'ambito transazionale è un errore che si verifica in un ambito di transazione all'interno di un'orchestrazione. È importante comprendere che il gestore di compensazione di un ambito viene richiamato solo se l'ambito è stato completato correttamente, ma è necessario annullarlo perché un ambito circostante ha deciso di interrompere (a causa di errori che possono verificarsi più avanti nel processo). Inoltre, non si verifica alcun rollback automatico dello stato in caso di interruzione della transazione. È possibile ottenere questo risultato a livello di codice tramite i gestori di eccezioni e compensazione. Gli interruzioni dell'ambito transazionale non devono normalmente verificarsi in un ambiente di produzione; pertanto, questa analisi verifica l'occorrenza di eventuali ambiti transazionali interrotti. Riferimento: Transazioni |
BizTalk Server: ambiti transazionali BizTalk compensati | La compensazione può essere considerata come un annullamento logico del lavoro che è stato eseguito correttamente in risposta a una condizione di errore. È importante comprendere che il gestore di compensazione di un ambito viene richiamato solo se l'ambito è stato completato correttamente, ma è necessario annullarlo perché un ambito circostante ha deciso di interrompere (a causa di errori che possono verificarsi più avanti nel processo). Inoltre, non si verifica alcun rollback automatico dello stato in caso di interruzione della transazione. È possibile ottenere questo risultato a livello di codice tramite i gestori di eccezioni e compensazione. Le compensazioni dell'ambito transazionale non devono normalmente verificarsi in un ambiente di produzione; pertanto, questa analisi verifica l'occorrenza di eventuali ambiti transazionali interrotti. Riferimento: Transazioni |
BizTalk Server: Byte virtuali di BizTalk | Si tratta dei megabyte riservati per la memoria virtuale per l'istanza host. Questa analisi determina se una qualsiasi delle istanze host utilizza una grande quantità di memoria del sistema e se l'istanza host aumenta nel tempo. Per ulteriori informazioni, fare riferimento all'analisi dei byte virtuali di BizTalk in questo argomento. |
BizTalk Server: Limitazione delle sessioni del database BizTalk Message Agent | Questo è il numero di connessioni di database aperte a MessageBox rispetto alla rispettiva impostazione di limitazione BizTalk. "Connessione al database per CPU" è il numero massimo di sessioni simultanee del database (per CPU) consentite prima che inizi la regolazione. Per ulteriori informazioni, consultare l'analisi della limitazione delle sessioni nel database dell'agente messaggi BizTalk in questo argomento. |
BizTalk Server: Soglia di limitazione della sessione del database di BizTalk Message Agent | Questa è la soglia corrente per il numero di connessioni di database aperte a MessageBox. "Connessione al database per CPU" è il numero massimo di sessioni simultanee del database (per CPU) consentite prima che inizi la regolazione. Per ulteriori informazioni, consultare l'analisi delle soglie di limitazione delle sessioni dell'agente di messaggistica BizTalk in questo argomento. |
BizTalk Server: Limitazione del numero di messaggi in-process dell'agente messaggi BizTalk | Si tratta del numero di messaggi simultanei che la classe del servizio sta elaborando. L'impostazione "Messaggi in processo per CPU" nelle impostazioni di limitazione dell'host è il numero massimo di messaggi inviati a End Point Manager (EPM) o XLANG che non sono stati elaborati. Per altre informazioni, vedere BizTalk Message Agent In-process Message Count Throttling Analysis in questo argomento. |
BizTalk Server: Soglia di limitazione del numero di messaggi in-process dell'agente messaggi BizTalk | Si tratta della soglia corrente per il numero di messaggi simultanei elaborati dalla classe del servizio. L'impostazione "Messaggi in corso per CPU" nelle impostazioni di limitazione dell'host rappresenta il numero massimo di messaggi consegnati al Gestore del Punto Finale (EPM) o XLANG e non ancora elaborati. Per ulteriori informazioni, fare riferimento all'analisi della soglia di limitazione dei messaggi in corso dell'agente BizTalk in questo contesto. |
Limitazione dell'utilizzo della memoria (MB) del processo dell'agente dei messaggi di BizTalk Server | Si tratta dell'utilizzo della memoria del processo corrente (MB). La limitazione della memoria del processo BizTalk può verificarsi se il batch da pubblicare presenta requisiti di memoria elevati o se troppi thread elaborano messaggi. Per ulteriori informazioni, consultare l'analisi della limitazione dell'uso della memoria del processo dell'agente di messaggi BizTalk (MB) in questo argomento. |
BizTalk Server: soglia di limitazione dell'utilizzo della memoria del processo dell'agente dei messaggi di BizTalk (MB) | Questa è la soglia corrente per l'utilizzo della memoria del processo corrente (MB). La soglia può essere modificata dinamicamente a seconda della quantità effettiva di memoria disponibile per questo processo e del relativo modello di utilizzo della memoria. La limitazione del consumo di memoria del processo BizTalk può verificarsi se il batch da pubblicare presenta requisiti di memoria elevati o se troppi thread elaborano messaggi. Per ulteriori informazioni, consulta l'analisi della soglia di limitazione del processo di utilizzo della memoria dell'agente dei messaggi di BizTalk (MB) in questo argomento. |
BizTalk Server: Limitazione del numero di thread dell'agente messaggi BizTalk | Numero totale di thread nel processo BizTalk. "Thread per CPU" è il numero totale di thread nel processo host, inclusi i thread usati dagli adattatori. Se questa soglia viene superata, BizTalk Server tenterà di ridurre le dimensioni del pool di thread EPM e del pool di thread dell'agente messaggi. La limitazione basata sui thread dovrebbe essere attivata negli scenari in cui un carico elevato può portare alla creazione di un numero elevato di thread. Questo parametro influisce sia sulla regolazione in ingresso che in uscita. La limitazione basata su thread è disabilitata per impostazione predefinita. Questa analisi controlla se il conteggio thread di BizTalk è oltre l'80% del valore soglia di limitazione, indicando che una condizione di limitazione è probabile. Riferimenti: - Contatori delle prestazioni di limitazione dell'host - Come BizTalk Server implementa la limitazione dell'host - Come modificare le impostazioni di limitazione dell'host predefinite - Parametri di configurazione che influiscono sulle prestazioni dell'adapter - Thread, sessioni di database e regolazione |
BizTalk Server: soglia di limitazione del numero di thread dell'agente messaggi BizTalk | Si tratta della soglia corrente per il numero totale di thread nel processo. "Thread per CPU" è il numero totale di thread nel processo host, inclusi i thread usati dagli adattatori. Se questa soglia viene superata, BizTalk Server tenterà di ridurre le dimensioni del pool di thread EPM e del pool di thread dell'agente messaggi. La gestione del carico basata su thread deve essere abilitata negli scenari in cui un carico elevato può portare alla creazione di molti thread. Questo parametro influisce sia sulla regolazione in ingresso che in uscita. Questa analisi controlla se questa impostazione di limitazione è impostata su un valore non predefinito. La limitazione basata su thread è disabilitata per impostazione predefinita. Riferimenti: - Contatori delle prestazioni di limitazione dell'host - Come BizTalk Server implementa la limitazione dell'host - Come modificare le impostazioni di limitazione dell'host predefinite - Parametri di configurazione che influiscono sulle prestazioni dell'adapter - Thread, sessioni di database e limitazione |
Analisi della latenza di lettura/scrittura di dischi logici/fisici
Il modo più affidabile affinché Windows rilevi un collo di bottiglia nelle prestazioni del disco è misurare i tempi di risposta. Se i tempi di risposta sono maggiori di 025 (25 millisecondi), ovvero una soglia conservativa, possono verificarsi problemi di rallentamento e prestazioni che interessano gli utenti.
Le cause più comuni della scarsa latenza del disco sono la frammentazione del disco, la cache delle prestazioni, una SAN sovrasaturata e un carico eccessivo sul disco. Usare lo strumento SPA per identificare i file e i processi principali usando il disco. Controllare anche "Operazioni di I/O dati/sec" e "Operazioni di I/O Altri/sec" per verificare quali processi consumano di più le operazioni di I/O su disco. Tenere presente che i contatori di Performance Monitor non sono in grado di specificare quali file sono coinvolti.
Riferimenti
Trasferimenti di dischi logici/sec
"Trasferimenti disco/sec" è la frequenza di operazioni di lettura e scrittura sul disco. Anche se i trasferimenti di dischi non sono una correlazione diretta con le operazioni di I/O del disco, indicano il numero di operazioni su disco in corso. Se si calcola la media delle operazioni di I/O sequenziali e di I/O casuali, si finisce con circa 80 operazioni di I/O al secondo come regola generale. È quindi consigliabile che un'unità SAN esegua più di 80 operazioni di I/O al secondo quando è in carico. Le soglie per questa analisi controllano se uno dei dischi logici mostra tempi di risposta scarsi (maggiori di 25 ms di tempi di risposta per le operazioni di I/O). Se questo è vero, è necessario prevedere che i trasferimenti del disco al secondo siano pari o superiori a 80. In caso contrario, è necessario analizzare l'architettura del disco. La causa più comune della scarsa I/O del disco è il sovraccarico del numero di unità logiche (LUN) sulla SAN, ovvero la condizione in cui più LUN usano la piccola matrice di dischi fisici.
Analisi della memoria disponibile
"Megabyte disponibili" è la quantità di memoria fisica disponibile per i processi in esecuzione sul computer, espressa in megabyte. Virtual Memory Manager regola continuamente lo spazio usato nella memoria fisica e sul disco per mantenere un numero minimo di byte disponibili per il sistema operativo e i processi. Quando i byte disponibili sono abbondanti, Virtual Memory Manager consente di aumentare i working set di processi o di mantenerli stabili rimuovendo una pagina precedente per ogni nuova pagina aggiunta. Quando i byte disponibili sono pochi, Virtual Memory Manager deve tagliare i working set di processi per mantenere il minimo necessario.
Questa analisi verifica se la memoria disponibile totale è bassa – avviso quando è al 10 percento disponibile e critico quando è al 5 percento disponibile. Viene inoltre visualizzato un avviso quando viene rilevata una tendenza decrescente di 10 MB all'ora, che indica una potenziale condizione di memoria futura. La memoria fisica insufficiente può causare un aumento della CPU e dei ritardi di sistema in modalità privilegiata.
Riferimenti
Analisi del rilevamento di perdite di memoria
Questa analisi determina se uno dei processi utilizza una grande quantità di memoria del sistema e se il processo aumenta nel tempo. Un processo che consuma grandi porzioni di memoria è corretto, purché il processo restituisca la memoria al sistema. Cercare tendenze crescenti nel grafico. Una tendenza crescente in un lungo periodo di tempo potrebbe indicare una perdita di memoria. Private Bytes è la dimensione corrente, in byte, della memoria allocata da questo processo che non può essere condivisa con altri processi. Questa analisi controlla le tendenze crescenti di 10 MB all'ora e di 5 MB all'ora. Usare questa analisi in correlazione con l'analisi della memoria disponibile.
Tenere inoltre presente che i processi appena avviati verranno inizialmente visualizzati come perdita di memoria quando è semplicemente normale comportamento di avvio. Una perdita di memoria si verifica quando un processo continua a consumare memoria e non rilascia memoria in un lungo periodo di tempo.
Se si sospetta una condizione di perdita di memoria, installare e usare lo strumento Debug Diag. Per altre informazioni sullo strumento Debug diag, vedere la sezione riferimenti.
Riferimenti
Strumento di diagnostica di debug
Analisi delle pagine di memoria al secondo
Questa analisi verifica se il valore di "Pages/sec" è elevato. Se è elevato, è probabile che il sistema esaurisca la memoria tentando di trasferire la memoria sul disco. "Pagine/sec" è la frequenza con cui le pagine vengono lette o scritte su disco per risolvere gli errori di pagina disco rigido. Questo contatore è un indicatore principale dei tipi di errori che causano ritardi a livello di sistema. È la somma di "Memory\Pages Input/sec" e "Memory\Pages Output/sec". Viene conteggiato in numeri di pagine, quindi può essere confrontato con altri conteggi di pagine, ad esempio "Memory\Page Faults/sec".
Questo contatore deve essere sempre sotto 1.000. Questa analisi verifica la presenza di valori superiori a 1.000. Usare questa analisi in correlazione con l'analisi della memoria disponibile e l'analisi del rilevamento perdite di memoria. Se tutte le analisi generano avvisi contemporaneamente, è possibile che il sistema esaurisca la memoria. Seguire i passaggi di analisi indicati nelle Informazioni aggiuntive riguardanti l'analisi del rilevamento delle perdite di memoria in questo argomento.
Riferimenti
Esclusione dei problemi di Memory-Bound
Analisi dei byte residenti della cache del sistema di memoria
"Byte residenti nella cache di sistema" è la dimensione, espressa in byte, del codice del sistema operativo paginabile nella cache del file system. Questo valore include solo le pagine fisiche correnti e non include le pagine di memoria virtuale che attualmente non sono residenti. Equivale al valore di Cache di sistema visualizzato in Gestione attività. Di conseguenza, questo valore può essere inferiore alla quantità effettiva di memoria virtuale in uso dalla cache del file system. Questo valore è un componente di "Memory\\System Code Resident Bytes", che rappresenta tutto il codice del sistema operativo paginabile attualmente in memoria fisica. Questo contatore visualizza solo l'ultimo valore osservato; non è una media.
Questa analisi verifica una tendenza crescente di 10 MB all'ora. In fase di caricamento, un server potrebbe usare la cache di sistema per memorizzare nella cache le attività di I/O, come quella su disco. Usare in correlazione con le operazioni di elaborazione dei dati di I/O/sec e le analisi di I/O di elaborazione di altre operazioni/sec.
Analisi dell'utilizzo del processore e uso eccessivo del processore da parte dei processi
"% Tempo processore" è la percentuale del tempo di esecuzione che il processore impiega per eseguire un thread attivo. Viene calcolato misurando la durata in cui il thread inattivo è attivo nell'intervallo di campionamento e quindi sottraendo tale tempo dalla durata dell'intervallo. Ogni processore ha un thread inattio che utilizza cicli quando nessun altro thread è pronto per l'esecuzione. Questo contatore è l'indicatore principale dell'attività del processore e visualizza la percentuale media di tempo occupato osservato durante l'intervallo di campionamento. Viene calcolato monitorando il tempo in cui il servizio è inattivo e sottraendo tale valore dal 100%.
Questa analisi controlla l'utilizzo maggiore del 60% su ogni singolo processore. In tal caso, determinare se si tratta di cpu in modalità utente elevata o modalità con privilegi elevati. Se si sospetta che la CPU in modalità con privilegi elevati sia sospetta, vedere "Privileged Mode CPU Analysis". Se si sospetta un collo di bottiglia del processore in modalità utente, è consigliabile usare un profiler di processo per analizzare le funzioni che causano un utilizzo elevato della CPU. Per altre informazioni, vedere l'articolo "Procedura: Identificare le funzioni che causano un collo di bottiglia elevato della CPU in modalità utente per le applicazioni server in un ambiente di produzione" nella sezione riferimenti.
Analisi della lunghezza della coda del processore
"Lunghezza coda processore" è il numero di thread nella coda del processore. A differenza dei contatori dei dischi, questo contatore mostra solo thread pronti, non thread in esecuzione. C'è una singola coda per il tempo del processore anche nei computer con più processori. Pertanto, se un computer dispone di più processori, è necessario dividere questo valore per il numero di processori che servono il carico di lavoro. Una coda di processori sostenuta di meno di 10 thread per processore è normalmente accettabile, dipendente dal carico di lavoro.
Questa analisi determina se la lunghezza media della coda del processore supera il numero di processori. In tal caso, questo potrebbe indicare un collo di bottiglia del processore. Usare questa analisi in correlazione con l'analisi della CPU in modalità privilegiata e l'uso eccessivo del processore in base al processo. La coda del processore è la raccolta di thread pronti ma non in grado di essere eseguiti dal processore perché è in esecuzione un altro thread attivo. Una coda costante o ricorrente di thread che supera il numero di processori è un buon indicatore di un collo di bottiglia del processore.
È possibile usare questo contatore in combinazione con il contatore "Processore\% tempo processore" per determinare se l'applicazione può trarre vantaggio da più CPU. Esiste una singola coda per il tempo del processore, anche nei computer multiprocessore. Pertanto, in un computer multiprocessore, dividere il valore della "Lunghezza coda processore" (PQL) per il numero di processori che gestiscono il carico di lavoro.
Se la CPU è molto occupata (90% e maggiore utilizzo) e la media PQL è costantemente superiore al numero di processori, è possibile che si abbia un collo di bottiglia del processore che potrebbe trarre vantaggio da CPU aggiuntive. Oppure, è possibile ridurre il numero di thread e code a livello di applicazione. Ciò causerà un cambio di contesto inferiore, utile per ridurre il carico della CPU. Il motivo comune per un PQL elevato con un utilizzo ridotto della CPU è che le richieste per il tempo del processore arrivano in modo casuale e i thread richiedono quantità irregolari di tempo dal processore. Ciò significa che il processore non è un collo di bottiglia. Invece, è la logica di threading che deve essere migliorata.
Se si sospetta un collo di bottiglia del processore in modalità utente, è consigliabile usare un profiler di processo per analizzare le funzioni che causano un utilizzo elevato della CPU. Per ulteriori informazioni, vedere l'articolo "Procedura: Identificare le funzioni che causano un collo di bottiglia della CPU in modalità utente ad alto utilizzo per applicazioni server in un ambiente di produzione" nella sezione riferimenti.
Analisi della CPU in modalità privilegiata
Questo contatore indica la percentuale di tempo in cui un thread viene eseguito in modalità con privilegi. Quando l'applicazione chiama funzioni del sistema operativo (ad esempio per eseguire operazioni di I/O di rete o per allocare memoria), queste funzioni del sistema operativo vengono eseguite in modalità con privilegi.
Cpu con privilegi elevati indica che il computer sta spendendo troppo tempo nel lavoro di I/O di sistema rispetto al lavoro reale (modalità utente). "% Tempo in modalità privilegiata" è la percentuale di tempo trascorso dai thread del processo nell'esecuzione del codice in modalità privilegiata. Quando viene chiamato un servizio di sistema Windows, il servizio viene spesso eseguito in modalità privilegiata per ottenere l'accesso ai dati privati del sistema. Tali dati sono protetti dall'accesso da parte dei thread in esecuzione in modalità utente. Le chiamate al sistema possono essere esplicite o implicite, ad esempio errori di pagina o interrupt. A differenza di alcuni sistemi operativi iniziali, Windows usa i limiti dei processi per la protezione del sottosistema oltre alla protezione tradizionale delle modalità utente e con privilegi. Alcune operazioni eseguite da Windows per conto dell'applicazione potrebbero essere visualizzate in altri processi del sottosistema oltre al tempo con privilegi nel processo.
Questa analisi verifica se la CPU in modalità privilegiata utilizza più del 30% della CPU totale. In tal caso, è probabile che l'utilizzo della CPU sia causato da un altro collo di bottiglia diverso dal processore, ad esempio rete, memoria o I/O del disco. Usare in correlazione con il tempo di interruzione % e le analisi del cambio di contesto elevato.
Analisi del frequente cambio di contesto
Un cambio di contesto si verifica quando un thread con priorità più alta impedisce un thread con priorità più bassa attualmente in esecuzione o quando un thread con priorità alta si blocca. I livelli elevati di cambio di contesto possono verificarsi quando molti thread condividono lo stesso livello di priorità. Questo spesso indica che troppi thread sono in competizione per i processori nel sistema. Se non viene visualizzato un utilizzo elevato del processore e si notano livelli molto bassi di cambio del contesto, potrebbe indicare che i thread sono bloccati.
Il cambio di contesto elevato deve essere esaminato solo quando la CPU in modalità privilegiata e la CPU complessiva sono elevate. Come regola generale, i tassi di cambio di contesto inferiori a 5.000 al secondo per processore non vale la pena preoccuparsi. Se i tassi di cambio del contesto superano i 15.000 al secondo per processore, esiste un vincolo.
Questa analisi verifica la presenza di CPU elevata, CPU con privilegi elevati e commutazioni di contesto di sistema elevate (maggiori di 5.000 per processore al secondo) che si verificano contemporaneamente. Se si verifica un cambio di contesto elevato, ridurre il numero di thread e processi in esecuzione nel sistema.
Analisi delle sessioni di database ad alta percentuale di BizTalk
Questo contatore ha due valori possibili, ovvero normale (0) o superato (1). Questa analisi verifica la presenza di un valore pari a 1. In tal caso, BizTalk ha superato la soglia del numero di sessioni di database consentite. Questo valore è controllato dal valore "Connessione di database per CPU" nelle impostazioni di limitazione delle richieste dell'host BizTalk.
"Connessione al database per CPU" è il numero massimo di sessioni simultanee del database (per CPU) consentite prima che inizi la regolazione. Le sessioni di database inattive nel pool di sessioni comuni per host non vengono aggiunte a questo conteggio e questo controllo viene eseguito rigorosamente sul numero di sessioni effettivamente usate dall'istanza host. Questa opzione è disabilitata per impostazione predefinita; in genere, questa impostazione deve essere abilitata solo se il server di database è un collo di bottiglia o per i server di database di fascia bassa nel sistema BizTalk Server. È possibile monitorare il numero di connessioni di database attive usando il contatore delle prestazioni della sessione del database nella categoria dell'oggetto prestazioni BizTalk:Message Agent. Questo parametro influisce solo sulla limitazione dei messaggi in uscita. Immettere il valore 0 per disabilitare la limitazione della velocità basata sul numero di sessioni di database. Il valore predefinito è 0.
Annotazioni
La chiave del Registro di sistema "MaxWorkerThreads" influisce sul numero di thread disponibili per BizTalk e può essere utile se la maggior parte dei thread BizTalk è occupato con le connessioni di database.
Riferimenti
Parametri di configurazione che influiscono sulle prestazioni dell'adapter
Come modificare le impostazioni di limitazione dell'host predefinite
Analisi delle dimensioni elevate del database BizTalk
Questo contatore si riferisce al numero di messaggi nelle code del database che sono stati pubblicati da questo processo. Questo valore viene misurato in base al numero di elementi nelle tabelle della coda per tutti gli host e al numero di elementi nelle tabelle dello spool e di rilevamento. La coda include la coda di lavoro, la coda di stato e la coda sospesa. Se un processo sta pubblicando in più code, questo contatore riflette la media ponderata di tutte le code.
Se l'host viene riavviato, le statistiche mantenute in memoria sono perse. Poiché è coinvolto un sovraccarico, BizTalk Server riprenderà la raccolta di statistiche solo quando ci sono almeno 100 pubblicazioni, con il 5 percento delle pubblicazioni totali all'interno del processo dell'host riavviato.
Questo contatore verrà impostato su un valore pari a 1 se si verifica una delle condizioni elencate per il conteggio dei messaggi nella soglia del database. Questa soglia è documentata nell'argomento How to Modify the Default Host Throttling Settings (Come modificare le impostazioni di limitazione host predefinite a cui si fa riferimento di seguito). Per impostazione predefinita, il numero di messaggi host nella soglia di limitazione del database è impostato su un valore pari a 50.000, che attiverà una condizione di limitazione nelle circostanze seguenti:
Il numero totale di messaggi pubblicati dall'istanza host per le code di lavoro, di stato e sospese degli host sottoscritti supera 50.000.
Il numero di messaggi nella tabella di spooling o nella tabella di rilevamento supera i 500.000 messaggi.
Poiché i messaggi sospesi sono inclusi nel conteggio dei messaggi nel calcolo del database, la limitazione della pubblicazione dei messaggi può verificarsi anche se il server BizTalk riscontra un carico basso o nessun carico.
Questa analisi verifica la presenza di un valore pari a 1. In questo caso, prendere in considerazione una linea d'azione che riduca il numero di messaggi nel database. Ad esempio, verificare che i processi di SQL Server BizTalk siano in esecuzione senza errori e usare l'hub di gruppo nella console di amministrazione bizTalk per determinare se la compilazione dei messaggi è causata da un numero elevato di messaggi sospesi.
Riferimenti
I messaggi sospesi sono inclusi nel conteggio dei messaggi nella soglia di limitazione del database
Come modificare le impostazioni di limitazione dell'host predefinite
Analisi del conteggio dei messaggi di BizTalk High In-Process
L'impostazione "Messaggi in corso per CPU" nelle impostazioni di limitazione dell'host rappresenta il numero massimo di messaggi consegnati al Gestore del Punto Finale (EPM) o XLANG e non ancora elaborati. Questo numero non include i messaggi recuperati dal database che sono ancora in attesa di essere consegnati nella coda in memoria. È possibile monitorare il numero di messaggi in elaborazione usando il contatore delle prestazioni "Conteggio messaggi in elaborazione" nella categoria dell'oggetto di prestazioni BizTalk:Message Agent. Questo parametro fornisce un suggerimento al meccanismo di limitazione quando si considerano le condizioni di limitazione. La soglia effettiva è soggetta all'autoottimizzazione. È possibile verificare la soglia effettiva monitorando il contatore delle prestazioni per il conteggio dei messaggi in-process.
Questo parametro può essere impostato su un valore inferiore per scenari di messaggi di grandi dimensioni, in cui la dimensione media dei messaggi è elevata o l'elaborazione dei messaggi può richiedere un numero elevato di messaggi. Ciò sarebbe evidente se uno scenario sperimenta troppo spesso la limitazione basata sulla memoria e se la soglia di memoria viene adattata automaticamente a un valore sostanzialmente basso. Questo comportamento indica che il trasporto in uscita deve elaborare contemporaneamente un minor numero di messaggi per evitare un utilizzo eccessivo della memoria. Inoltre, per gli scenari in cui l'adattatore è più efficiente durante l'elaborazione di alcuni messaggi alla volta (ad esempio, quando si invia a un server che limita le connessioni simultanee), questo parametro può essere ottimizzato in un valore inferiore rispetto all'impostazione predefinita.
Questa analisi controlla il contatore Numero di messaggi elevato In-Process per determinare se si verifica questo tipo di strozzamento. In tal caso, valutare la possibilità di modificare l'impostazione "In-Process messaggi per CPU". Questo parametro influisce solo sulla limitazione dei messaggi in uscita. Immettere il valore 0 nell'impostazione "In-Process messaggi per CPU" per disabilitare la limitazione in base al numero di messaggi in-process per CPU. Il valore predefinito per l'impostazione "In-Process messaggi per CPU" è 1.000. Si noti che la modifica di questo valore può avere anche un impatto sulla bassa latenza dei messaggi e/o sull'efficienza delle risorse BizTalk.
Riferimenti
Analisi della frequenza di recapito dei messaggi elevata di BizTalk
Per i messaggi in uscita (recapitati), BizTalk Server limita il recapito dei messaggi se la frequenza di recapito in ingresso per l'istanza host supera la velocità in uscita dei messaggi moltiplicata per il fattore di overdrive specificato (in percentuale). Il parametro fattore di accelerazione della velocità (percentuale) è configurabile nella finestra di dialogo Impostazioni di limitazione del trattamento dei messaggi. La limitazione basata sulla frequenza per i messaggi in uscita viene eseguita principalmente inducendo un ritardo prima di rimuovere i messaggi dalla coda in memoria e recapitando i messaggi al motore di orchestrazione (EPM) o end point manager per l'elaborazione. Nessun'altra azione viene eseguita per eseguire la limitazione basata sulla frequenza per i messaggi in uscita.
La limitazione in uscita può causare il recapito ritardato dei messaggi e i messaggi possono essere compilati nella coda in memoria e causare il blocco dei thread de-queue fino a quando la condizione di limitazione non viene attenuata. Quando i thread di coda vengono bloccati, non vengono estratti ulteriori messaggi da MessageBox nella coda in memoria per la consegna in uscita.
Questa analisi verifica la presenza di un valore pari a 1 nel contatore Tasso di recapito dei messaggi elevato. Le frequenze di recapito dei messaggi elevate possono essere causate da un'elevata complessità di elaborazione, da schede in uscita lente o da una carenza momentanea di risorse di sistema.
Riferimenti
Analisi della memoria di processo elevata in BizTalk
L'impostazione soglia di limitazione dell'utilizzo della memoria del processo BizTalk corrisponde alla percentuale di memoria usata rispetto alla somma delle dimensioni del working set e alla memoria virtuale totale disponibile per il processo se viene immesso un valore compreso tra 1 e 100. Per impostazione predefinita, l'impostazione di limitazione dell'uso della memoria del processo BizTalk è impostata a 25. Quando viene specificato un valore percentuale, la soglia di memoria del processo viene ricalcolata a intervalli regolari. Se l'utente specifica un valore percentuale, viene calcolato in base alla memoria disponibile per il commit e all'utilizzo corrente della memoria del processo.
Questa analisi verifica la presenza di un valore pari a 1 nel contatore Memoria Processo Elevato. In questo caso, provare a determinare la causa dell'aumento della memoria usando Debug Diag (vedere riferimenti nell'analisi rilevamento perdite di memoria). Si noti che è normale che i processi consumano una grande parte di memoria durante l'avvio e questo può inizialmente apparire come una perdita di memoria, ma una vera perdita di memoria si verifica quando un processo non riesce a rilasciare memoria che non è più necessaria, riducendo così la quantità di memoria disponibile nel tempo. Per altre informazioni su come analizzare in modo generico le perdite di memoria in BizTalk, vedere il riferimento "How to Capture a Memory Dump of a Process that is Leaking Memory" reference below and/or the "Memory Leak Detection" (Come acquisire un dump di memoria di un processo che sta per perdere memoria) di seguito e/o l'analisi "Rilevamento perdite di memoria" in PAL.
Un'elevata limitazione della memoria di processo può verificarsi se il batch da pubblicare ha elevati requisiti di memoria o se troppi thread stanno elaborando messaggi. Se il sistema sembra mostrare un'eccessiva limitazione, considerare l'aumento del valore associato alla soglia di utilizzo della memoria di processo per l'host e verificare che l'istanza host non generi un errore di memoria insufficiente. Se viene generato un errore di "memoria insufficiente" aumentando la soglia di utilizzo della memoria del processo, è consigliabile considerare di ridurre i valori della dimensione interna della coda dei messaggi e dei messaggi in-process per soglia CPU. Questa strategia è particolarmente rilevante negli scenari di elaborazione di messaggi di grandi dimensioni. Inoltre, questo valore deve essere impostato su un valore basso per gli scenari con requisiti di memoria di grandi dimensioni per ogni messaggio. L'impostazione di un valore basso avvierà presto la limitazione e impedirà un'esplosione di memoria all'interno del processo.
Se il server BizTalk esaurisce regolarmente la memoria virtuale, prendere in considerazione BizTalk Server a 64 bit. Ogni processo nei server a 64 bit può indirizzare fino a 4 TB di memoria virtuale rispetto a 2 GB in 32 bit. In generale, è consigliabile usare BizTalk a 64 bit e SQL Server a 64 bit. Per altre informazioni, vedere le informazioni di riferimento sul supporto a 64 bit di BizTalk Server.
Riferimenti
Come modificare le impostazioni di limitazione dell'host predefinite
Come acquisire un dump di memoria di un processo che sta perdendo memoria
Analisi della memoria di sistema elevata di BizTalk
L'impostazione soglia di limitazione dell'utilizzo della memoria fisica BizTalk è la percentuale di consumo di memoria rispetto alla quantità totale di memoria fisica disponibile se viene immesso un valore compreso tra 1 e 100. Questa impostazione può anche essere la quantità totale di memoria fisica disponibile in megabyte se viene immesso un valore maggiore di 100. Immettere un valore di 0 per disabilitare la limitazione in base all'utilizzo della memoria fisica. Il valore predefinito è 0.
Questa analisi verifica la presenza di un valore pari a 1 nel contatore Memoria di sistema elevata. Poiché questa misura la memoria totale del sistema, è possibile che venga attivata una condizione di limitazione se i processi non BizTalk Server utilizzano una grande quantità di memoria di sistema. Pertanto, se ciò si verifica, l'approccio migliore consiste nell'identificare i processi che utilizzano la memoria fisica e/o aggiungere ulteriore memoria fisica al server. Valutare anche la possibilità di ridurre il carico riducendo le dimensioni predefinite del pool di thread EPM e/o le dimensioni dei batch di adattatori. Per altre informazioni, vedere l'analisi del rilevamento delle perdite di memoria in PAL.
Riferimenti
Analisi del conteggio dei thread di BizTalk High
"Thread per CPU" è il numero totale di thread nel processo host, inclusi i thread usati dagli adattatori. Se questa soglia viene superata, BizTalk Server tenterà di ridurre le dimensioni del pool di thread EPM e del pool di thread dell'agente messaggi. La limitazione basata sui thread dovrebbe essere attivata negli scenari in cui un carico elevato può portare alla creazione di un numero elevato di thread. Questo parametro influisce sia sulla regolazione in ingresso che in uscita. La limitazione basata su thread è disabilitata per impostazione predefinita.
Annotazioni
Il valore specificato dall'utente viene usato come linea guida e l'host può ottimizzare in modo dinamico questo valore soglia in base ai modelli di utilizzo della memoria e ai requisiti del thread del processo.
Questa analisi verifica la presenza di un valore pari a 1 nel contatore Conteggio thread elevato. Valutare la possibilità di modificare le diverse dimensioni del pool di thread per assicurarsi che il sistema non crei un numero elevato di thread. Questa analisi può essere correlata con l'analisi dei commutatori di contesto al secondo per determinare se il sistema operativo è saturo con troppi thread, ma nella maggior parte dei casi conteggi di thread elevati causano più conflitti nel database back-end rispetto al server BizTalk. Per altre informazioni sulla modifica delle dimensioni del pool di thread, vedere Come modificare le impostazioni di limitazione host predefinite nei riferimenti.
Riferimenti
Come modificare le impostazioni di limitazione dell'host predefinite
Parametri di configurazione che influiscono sulle prestazioni dell'adapter
Thread, sessioni di database e limitazione della velocità
Analisi della latenza in ingresso di BizTalk Media latenza in millisecondi dal momento in cui il motore di messaggistica riceve un documento dall'adattatore fino a quando non viene pubblicato nella casella di messaggio. La riduzione della latenza è importante per alcuni utenti di BizTalk, pertanto è importante tenere traccia della quantità di tempo trascorsa dai documenti nell'adapter in ingresso.
Ecco un grafico che mostra come viene misurata la latenza.
1 | 2 | 3 | 4 | 5 | 6 |
---|---|---|---|---|---|
L'adapter riceve il messaggio e lo invia al motore, il lavoro svolto nell'adapter prima che il messaggio venga inviato al motore non è contabilizzato in questi contatori delle prestazioni. | Il motore riceve un messaggio dall'adapter, esegue la pipeline di ricezione, la mappa, la valutazione delle sottoscrizioni e memorizza il messaggio in database. | L'orchestrazione o la porta Solicit-Response viene eseguita e genera un messaggio di risposta. | Il messaggio di risposta viene dequeuato nel motore di messaggistica, eseguire la pipeline di invio, mappare. | Il motore di messaggistica fornisce un messaggio di risposta all'adapter. | L'adattatore comunica che il messaggio del motore è stato completato. |
Io | |||||
RR | RR | RR | |||
o | o | o | |||
OA | OA |
I = Latenza in ingresso
RR = Latenza della risposta della richiesta
O = Latenza in uscita
OA = Latenza dell'adapter in uscita
Supponendo un ambiente a bassa latenza, questa analisi controlla se il documento ha trascorso più di 5 secondi nell'adattatore in ingresso. Ciò può indicare un ritardo di elaborazione nel trasporto dei messaggi tramite adattatori in ingresso in questa istanza host. Se in questa istanza host esistono più adattatori in ingresso, valutare la possibilità di separarli nei propri host per determinare quale scheda in ingresso ha una latenza elevata.
Riferimenti
Analisi dello stato di limitazione del recapito dei messaggi BizTalk
Lo stato di limitazione del recapito dei messaggi BizTalk è uno dei principali indicatori di contenimento. Si tratta di un flag che indica se il sistema sta limitando il recapito dei messaggi (che influisce sull'elaborazione dei messaggi XLANG e sui trasporti in uscita). La condizione di limitazione è rappresentata dal valore numerico del contatore. Di seguito è riportato un elenco dei valori e del rispettivo significato:
Condizione di gestione del flusso | Descrizione |
---|---|
0 | Nessuna limitazione della velocità |
1 | Restrizione dovuta al tasso di consegna dei messaggi sbilanciato (il tasso di input supera quello di output) |
3 | Limitazione dovuta al numero elevato di messaggi in-process |
4 | Limitazione dovuta alla pressione della memoria del processo |
5 | Limitazione derivante dalla pressione della memoria di sistema |
9 | Limitazione dovuta al numero elevato di thread |
10 | Limitazione dovuta alla modifica del comando da parte dell'utente alla consegna |
Questa analisi verifica la presenza di ognuno di questi valori e ha un avviso specifico per ognuno di essi.
Riferimenti
Analisi degli errori di connessione del database MessageBox bizTalk
Questo contatore delle prestazioni è il numero di connessioni di database tentate non riuscite dall'avvio dell'istanza host. Se il servizio SQL Server che ospita i database BizTalk non è più disponibile per qualsiasi motivo, il cluster di database trasferisce le risorse dal computer attivo al computer passivo. Durante questo processo di failover, le istanze del servizio BizTalk Server riscontrano errori di connessione al database e riavviano automaticamente per riconnettersi ai database. Il computer di database funzionante (in precedenza il computer passivo) inizia a elaborare le connessioni di database dopo aver assunto le risorse durante il failover.
Gli errori DBNetLib (Libreria di rete del database) si verificano quando il runtime di BizTalk Server non è in grado di comunicare con i database MessageBox o di gestione. In questo caso, l'istanza di runtime di BizTalk Server che intercetta l'eccezione si arresta e si ripete ogni minuto per verificare se il database è disponibile. Per altre informazioni su questo argomento, vedere la sezione riferimenti.
Quando un client avvia una connessione socket TCP/IP a un server, il client si connette in genere a una porta specifica sul server e richiede che il server risponda al client su una porta temporanea o di breve durata, TCP o UDP. In Windows Server 2003 e Windows XP l'intervallo predefinito di porte temporanee usate dalle applicazioni client è compreso tra 1025 e 5000. In determinate condizioni è possibile che le porte disponibili nell'intervallo predefinito vengano esaurite. Per altre informazioni su questo argomento, vedere la sezione riferimenti.
Questa analisi verifica la presenza di errori di connessione al database. Gli errori di connessione al database sono critici perché BizTalk non può funzionare senza il database. Se la causa dell'errore di connessione al database è sconosciuta, prendere in considerazione i riferimenti elencati di seguito e/o contattare il supporto tecnico Microsoft per determinare la natura dell'errore di connettività.
Riferimenti
Analisi dello stato di limitazione della pubblicazione dei messaggi di BizTalk
Lo stato di limitazione della pubblicazione dei messaggi BizTalk è uno degli indicatori principali della limitazione. È un flag che indica se il sistema sta limitando la pubblicazione dei messaggi (che influisce sull'elaborazione dei messaggi XLANG e sui trasporti in ingresso). La condizione di limitazione è indicata dal valore numerico del contatore. Di seguito è riportato un elenco dei valori e del rispettivo significato:
Condizione di gestione del flusso | Descrizione |
---|---|
0 | Nessuna limitazione della velocità |
2 | Limitazione dovuta al tasso di pubblicazione dei messaggi sbilanciato (il tasso di input supera il tasso di output) |
4 | Limitazione dovuta alla pressione della memoria del processo |
5 | Strozzamento dovuto alla pressione della memoria di sistema |
6 | Limitazione dovuta all'aumento del database |
8 | Limitazione dovuta al numero elevato di sessioni |
9 | Limitazione dovuta ad un conteggio di thread elevato. |
11 | Limitazione dovuta all'override dell'utente durante la pubblicazione |
Questa analisi verifica la presenza di ognuno di questi valori e ha un avviso specifico per ognuno di essi.
Riferimenti
Orchestrazioni BizTalk residenti in memoria
Numero di istanze di orchestrazione attualmente ospitate dall'istanza host. Sebbene i picchi o i momenti di concentrazione delle orchestrazioni presenti in memoria possano essere considerati normali, una tendenza al rialzo potrebbe indicare un "accumulo" di orchestrazioni in memoria. Una tendenza crescente nel tempo si può manifestare quando BizTalk non riesce a disidratare i messaggi o le istanze di orchestrazione. Provate a correlare questo contatore con “XLANG/s Orchestrazioni(?)\Orchestrazioni idratabili disidratate”, dove il punto interrogativo (?) denota la stessa istanza di contatore di questo contatore.
Se un numero elevato di orchestrazioni risiede in memoria e se un numero ridotto di orchestrazioni è disidratato, è probabile che le orchestrazioni siano inattive in memoria e possano causare una condizione di perdita di memoria. Usare questa analisi in correlazione con "\XLANG/s Orchestrations(*)\Idle orchestrations" se presente. Una tendenza crescente nelle orchestrazioni BizTalk inattive è un indicatore migliore delle perdite di memoria a causa dell'incapacità di disidratare le istanze di orchestrazione.
Questa analisi verifica una tendenza crescente nelle orchestrazioni residenti in memoria e se più di 50% delle orchestrazioni residenti in memoria non sono disidratabili.
Riferimenti
Analisi dei Byte Privati BizTalk
Si tratta dei megabyte di memoria privata allocata per l'istanza host e paragonabile al contatore delle prestazioni "\Process(*)\Private Bytes". I byte privati sono le dimensioni correnti, in byte, della memoria allocata da un processo che non può essere condiviso con altri processi. Questa analisi determina se una delle istanze host sta consumando un'ampia quantità di memoria del sistema e se il consumo di memoria dell'istanza host aumenta nel tempo. Un'istanza host che utilizza porzioni di memoria di grandi dimensioni viene eseguita correttamente, purché restituisca la memoria al sistema. Cercare tendenze crescenti nel grafico. Una tendenza crescente in un lungo periodo di tempo potrebbe indicare una perdita di memoria.
Questa analisi verifica una tendenza crescente di 10 MB all'ora. Usare questa analisi in correlazione con l'analisi della memoria disponibile e l'analisi della perdita di memoria. Tenere inoltre presente che le istanze host appena avviate potrebbero inizialmente sembrare una perdita di memoria quando è semplicemente un normale comportamento di avvio. Una perdita di memoria è quando un processo continua a consumare memoria e non rilascia memoria in un lungo periodo di tempo. Se si sospetta una condizione di perdita di memoria, leggere l'articolo "Aumento della memoria nella messaggistica BizTalk" di seguito. In caso contrario, installare e usare lo strumento Debug Diag. Per altre informazioni sullo strumento Debug diag, vedere la sezione riferimenti.
Riferimenti
Analisi dei byte virtuali di BizTalk
Si tratta dei megabyte riservati per la memoria virtuale per l'istanza host. Questa analisi determina se una qualsiasi delle istanze host utilizza una grande quantità di memoria del sistema e se l'istanza host aumenta nel tempo. Un'istanza host che utilizza porzioni di memoria di grandi dimensioni viene eseguita correttamente, purché restituisca la memoria al sistema. Cercare tendenze crescenti nel grafico. Una tendenza crescente in un lungo periodo di tempo potrebbe indicare una perdita di memoria.
Questa analisi verifica una tendenza crescente di 10 MB all'ora in byte virtuali. Usare questa analisi in correlazione con l'analisi della memoria disponibile e l'analisi della perdita di memoria. Tenere inoltre presente che le istanze host appena avviate verranno inizialmente visualizzate come perdita di memoria quando è semplicemente normale comportamento di avvio. Una perdita di memoria è quando un processo continua a consumare memoria e non rilascia memoria in un lungo periodo di tempo. Se si sospetta una condizione di perdita di memoria, leggere l'articolo "Aumento della memoria nella messaggistica BizTalk" di seguito. In caso contrario, installare e usare lo strumento Debug Diag. Per altre informazioni sullo strumento Debug diag, vedere la sezione riferimenti.
Riferimenti
Analisi della regolazione delle sessioni dell'agente dei messaggi BizTalk
Questo è il numero di connessioni di database aperte a MessageBox rispetto alla rispettiva impostazione di limitazione BizTalk. "Connessione al database per CPU" è il numero massimo di sessioni simultanee del database (per CPU) consentite prima che inizi la regolazione. Le sessioni di database inattive nel pool di sessioni comuni per host non vengono aggiunte a questo conteggio e questo controllo viene eseguito rigorosamente sul numero di sessioni effettivamente usate dall'istanza host. Questa opzione è disabilitata per impostazione predefinita; in genere questa impostazione deve essere abilitata solo se il server di database è un collo di bottiglia nel sistema BizTalk Server. È possibile monitorare il numero di connessioni di database attive usando il contatore delle prestazioni della sessione del database nella categoria dell'oggetto prestazioni BizTalk:Message Agent. Questo parametro influisce solo sulla limitazione dei messaggi in uscita. Immettere il valore 0 per disabilitare la limitazione della velocità basata sul numero di sessioni di database. Il valore predefinito è 0.
La chiave del Registro di sistema MaxWorkerThreads influisce sul numero di thread disponibili per BizTalk e può essere utile nel caso in cui la maggior parte dei thread di BizTalk sia occupato con le connessioni di database. Questa analisi controlla se il numero di connessioni di database aperte a MessageBox è maggiore dell'80% dell'impostazione Limitazione sessione database, a indicare che è probabile che sia presente una condizione di limitazione.
Riferimenti
Analisi della soglia di limitazione delle sessioni nel database dell'agente di messaggi BizTalk
Questa è la soglia corrente per il numero di connessioni di database aperte a MessageBox. "Connessione al database per CPU" è il numero massimo di sessioni simultanee del database (per CPU) consentite prima che inizi la regolazione. Le sessioni di database inattive nel pool di sessioni comuni per host non vengono aggiunte a questo conteggio e questo controllo viene eseguito rigorosamente sul numero di sessioni effettivamente usate dall'istanza host. Questa opzione è disabilitata per impostazione predefinita; in genere questa impostazione deve essere abilitata solo se il server di database è un collo di bottiglia nel sistema BizTalk Server. È possibile monitorare il numero di connessioni di database attive usando il contatore delle prestazioni della sessione del database nella categoria dell'oggetto prestazioni BizTalk:Message Agent. Questo parametro influisce solo sulla limitazione dei messaggi in uscita. Immettere il valore 0 per disabilitare la limitazione della velocità basata sul numero di sessioni di database. Il valore predefinito è 0.
La chiave del Registro di sistema MaxWorkerThreads influisce sul numero di thread disponibili per BizTalk e può essere utile nel caso in cui la maggior parte dei thread di BizTalk sia occupato con le connessioni di database. Questa analisi controlla questo valore per verificare se è stato modificato dall'impostazione predefinita. Per impostazione predefinita, questa impostazione è 0, il che significa che il throttling delle sessioni di database è disabilitato.
Riferimenti
Analisi del controllo del numero di messaggi in-process dell'agente dei messaggi BizTalk
Si tratta del numero di messaggi simultanei che la classe del servizio sta elaborando. L'impostazione "Messaggi in corso per CPU" nelle impostazioni di limitazione dell'host rappresenta il numero massimo di messaggi consegnati al Gestore del Punto Finale (EPM) o XLANG e non ancora elaborati. Ciò non include i messaggi recuperati dal database, che sono ancora in attesa di essere consegnati nella coda in memoria. È possibile monitorare il numero di messaggi in-process utilizzando il contatore delle prestazioni "Conteggio messaggi in-process" nella categoria dell'oggetto delle prestazioni BizTalk:Message Agent. Questo parametro fornisce un suggerimento al meccanismo di limitazione per tenere conto delle condizioni di limitazione. La soglia effettiva è soggetta all'autoottimizzazione. È possibile verificare la soglia effettiva monitorando il contatore delle prestazioni del conteggio dei messaggi In-process.
Per scenari di messaggi di grandi dimensioni (in cui la dimensione media dei messaggi è elevata o l'elaborazione dei messaggi può richiedere una grande quantità di messaggi), questo parametro può essere impostato su un valore più piccolo. Uno scenario di messaggi di grandi dimensioni si verifica se la limitazione delle risorse di memoria avviene troppo spesso e se la soglia di memoria viene regolata automaticamente a un valore sostanzialmente basso. Questo comportamento indica che il trasporto in uscita deve elaborare contemporaneamente un minor numero di messaggi per evitare un utilizzo eccessivo della memoria. Inoltre, per gli scenari in cui l'adattatore è più efficiente durante l'elaborazione di alcuni messaggi alla volta (ad esempio, quando si invia a un server che limita le connessioni simultanee), questo parametro può essere ottimizzato in un valore inferiore rispetto all'impostazione predefinita. Questa analisi controlla il contatore High In-Process Message Count per determinare se è maggiore dell'80% dell'impostazione di limitazione con lo stesso nome, il che indica che è probabile una condizione di limitazione.
Riferimenti
Analisi della soglia di limitazione del numero di messaggi in-process dell'agente di messaggi BizTalk:Message Agent
Si tratta della soglia corrente per il numero di messaggi simultanei elaborati dalla classe del servizio. L'impostazione "Messaggi in corso per CPU" nelle impostazioni di limitazione dell'host rappresenta il numero massimo di messaggi consegnati al Gestore del Punto Finale (EPM) o XLANG e non ancora elaborati. Ciò non include i messaggi recuperati dal database, ma che sono ancora in attesa di consegna nella coda in memoria. È possibile monitorare il numero di messaggi in elaborazione utilizzando il contatore delle prestazioni "Conteggio messaggi in-process" nella categoria dell'oggetto prestazioni "BizTalk:Message Agent". Questo parametro fornisce un suggerimento al meccanismo di limitazione per tenere conto delle condizioni di limitazione. La soglia effettiva è soggetta all'autoottimizzazione. È possibile verificare la soglia effettiva monitorando il contatore delle prestazioni "conteggio dei messaggi in elaborazione".
Per scenari di messaggi di grandi dimensioni (in cui la dimensione media dei messaggi è elevata o l'elaborazione dei messaggi può richiedere una grande quantità di messaggi), questo parametro può essere impostato su un valore più piccolo. Uno scenario di messaggi di grandi dimensioni si verifica se la limitazione della memoria avviene troppo frequentemente e se la soglia di memoria viene regolata automaticamente a un valore molto basso. Questo comportamento indica che il trasporto in uscita deve elaborare contemporaneamente un minor numero di messaggi per evitare un utilizzo eccessivo della memoria. Inoltre, per gli scenari in cui l'adattatore è più efficiente durante l'elaborazione di alcuni messaggi alla volta (ad esempio, quando si invia a un server che limita le connessioni simultanee), questo parametro può essere ottimizzato in un valore inferiore rispetto all'impostazione predefinita. Questa analisi verifica la soglia di limitazione del numero elevato di messaggi In-Process per un valore diverso da quello predefinito.
Riferimenti
Analisi della limitazione dell'uso di memoria (MB) del processo dell'agente dei messaggi BizTalk
Si tratta dell'utilizzo della memoria del processo corrente (MB). La limitazione del consumo di memoria del processo BizTalk può verificarsi se il batch da pubblicare presenta requisiti di memoria elevati o se troppi thread elaborano messaggi. Se il sistema sembra mostrare un'eccessiva limitazione, considerare l'aumento del valore associato alla soglia di utilizzo della memoria di processo per l'host e verificare che l'istanza host non generi un errore di memoria insufficiente. Se viene generato un errore di "memoria insufficiente" aumentando la soglia di utilizzo della memoria del processo, è consigliabile ridurre i valori per la dimensione della coda interna dei messaggi e per la soglia dei messaggi in-process per CPU. Questa strategia è particolarmente rilevante negli scenari di elaborazione di messaggi di grandi dimensioni.
Se il server BizTalk esaurisce regolarmente la memoria virtuale, prendere in considerazione BizTalk Server a 64 bit. Ogni processo su server a 64 bit può indirizzare fino a 4 TB di memoria virtuale rispetto a 2 GB in 32 bit. In generale, è consigliabile usare BizTalk a 64 bit e SQL Server a 64 bit. Per altre informazioni, vedere le informazioni di riferimento sul supporto a 64 bit di BizTalk Server. Questa analisi controlla se l'utilizzo della memoria del processo è maggiore dell'80% della soglia di limitazione corrispondente dello stesso nome. Per impostazione predefinita, l'impostazione di limitazione dell'uso della memoria del processo BizTalk è pari al 25% della memoria virtuale disponibile per il processo. L'opzione /3GB non ha alcun effetto su questa impostazione.
Riferimenti
Come modificare le impostazioni di limitazione dell'host predefinite
Come acquisire un dump di memoria di un processo che sta perdendo memoria
Analisi della soglia di regolazione dell'utilizzo della memoria da parte del processo dell'agente di messaggi BizTalk (MB)
Questa è la soglia corrente per l'utilizzo della memoria del processo corrente (MB). La soglia può essere modificata dinamicamente a seconda della quantità effettiva di memoria disponibile per questo processo e del relativo modello di utilizzo della memoria. La limitazione del consumo di memoria del processo BizTalk può verificarsi se il batch da pubblicare presenta requisiti di memoria elevati o se troppi thread elaborano messaggi. Se il sistema sembra mostrare un'eccessiva limitazione, considerare l'aumento del valore associato alla soglia di utilizzo della memoria di processo per l'host e verificare che l'istanza host non generi un errore di memoria insufficiente. Se viene generato un errore di memoria insufficiente dopo aver aumentato la soglia di utilizzo della memoria del processo, è consigliabile ridurre i valori per la dimensione della coda interna dei messaggi e i messaggi in-process per soglia della CPU. Questa strategia è particolarmente rilevante negli scenari di elaborazione di messaggi di grandi dimensioni.
Se il server BizTalk esaurisce regolarmente la memoria virtuale, prendere in considerazione BizTalk Server a 64 bit. Ogni processo su server a 64 bit può indirizzare fino a 4 TB di memoria virtuale rispetto a 2 GB in 32 bit. In generale, è consigliabile usare BizTalk a 64 bit e SQL Server a 64 bit. Per altre informazioni, vedere le informazioni di riferimento sul supporto a 64 bit di BizTalk Server. Questa analisi controlla se la limitazione della memoria del processo è impostata su un valore diverso da quello predefinito.