Come risolvere una perdita di memoria o un'eccezione di memoria insufficiente nel processo di BizTalk Server

Questo articolo descrive come risolvere una perdita di memoria o un'eccezione di memoria insufficiente nel processo di BizTalk Server di Microsoft BizTalk Server.

Versione originale del prodotto: BizTalk Server 2010, 2009
Numero KB originale: 918643

Riepilogo

Le perdite di memoria sono un problema comune. Potrebbe essere necessario provare diversi passaggi per trovare la causa specifica di una perdita di memoria o di un'eccezione OOM (Out-Of-Memory) in Microsoft BizTalk Server. Questo articolo illustra gli aspetti importanti da considerare quando si valutano l'utilizzo della memoria e i possibili problemi correlati alla memoria. Queste considerazioni includono i seguenti aspetti:

  • RAM fisica
  • Elaborazione di messaggi di grandi dimensioni
  • Uso dell'opzione /3GB
  • Uso di componenti personalizzati
  • Quale versione di Microsoft .NET Framework è in esecuzione nel sistema
  • Il numero dei processori

Il processo di BizTalk Server potrebbe riscontrare una perdita di memoria quando l'utilizzo della memoria in Gestione attività di Microsoft Windows usa più del 50% della RAM fisica. Una perdita di memoria può causare un'eccezione di memoria insufficiente quando l'utilizzo della memoria aumenta fino a quando il processo non esaurisce la memoria di sistema o finché il processo non smette di funzionare. Per questo problema, considerare quanto segue:

Utilizzo della RAM fisica e della memoria

Poiché potrebbe essere previsto un comportamento per un processo che usi circa la metà della RAM fisica, usare l'utilizzo della memoria come linea guida. Ad esempio, se il BizTalk Server ha 4 gigabyte (GB) di RAM e il processo di BizTalk Server usa circa 500 megabyte (MB) di RAM, potrebbe non verificarsi alcuna perdita. Se il processo BizTalk Server usa circa 1 GB di RAM, potrebbe verificarsi una perdita di memoria o una situazione di memoria elevata. L'utilizzo della memoria può essere causato da una stored procedure o da un'orchestrazione a esecuzione prolungata. Assicurarsi di conoscere la quantità di memoria usata in genere dall'host BizTalk per determinare se si verifica una perdita di memoria o una condizione di memoria elevata.

Messaggi di grandi dimensioni

Quando BizTalk Server elabora messaggi di grandi dimensioni, il sistema sembra avere una perdita di memoria. Tuttavia, i messaggi potrebbero usare una grande quantità di memoria.

Si consideri anche che può essere previsto un utilizzo elevato della memoria se BizTalk Server elabora messaggi di grandi dimensioni. È possibile aggiornare l'hardware per soddisfare i requisiti di prestazioni di BizTalk Server nell'ambiente.

Quanto tempo è necessario per riprodurre la perdita di memoria

Le perdite di memoria possono verificarsi immediatamente o accumularsi nel tempo. Entrambi gli scenari sono comuni.

Uso dell'opzione /3GB nei computer a 32 bit

In genere, un processo può accedere a 2 GB di spazio indirizzi virtuali. L'opzione /3GB è un'opzione per i sistemi che richiedono una memoria più indirizzabile. Questa opzione può migliorare l'utilizzo della memoria per l'elaborazione dei messaggi. Tuttavia, l'opzione /3 GB consente solo 1 GB di memoria indirizzabile per le operazioni in modalità kernel. Inoltre, questa opzione può aumentare il rischio di esaurimento della memoria del pool.

Quando l'opzione /3GB è abilitata in una versione a 32 bit di Windows, il processo può accedere a 3 GB di spazio indirizzi virtuali se il processo è in grado di riconoscere indirizzi di grandi dimensioni. Un processo è in grado di riconoscere indirizzi di grandi dimensioni quando il file eseguibile ha il flag IMAGE_FILE_LARGE_ADDRESS_AWARE impostato nell'intestazione dell'immagine. Poiché il processo BizTalk è compatibile con indirizzi di grandi dimensioni, BizTalk trarrà vantaggio dall'opzione /3GB.

Se un'istanza host BizTalk a 32 bit è in esecuzione in una versione a 64 bit di Windows (AMD64), il processo BizTalk trae vantaggio dallo spazio indirizzi di memoria di 4 GB perché BizTalk è in grado di riconoscere indirizzi di grandi dimensioni. Pertanto, lo spostamento delle applicazioni con memoria elevata in un server a 64 bit potrebbe essere la soluzione migliore.

Un processo BizTalk a 64 bit in una versione a 64 bit di Windows (AMD64) ha 8 TB di memoria indirizzabile.

È anche consigliabile considerare i byte virtuali e i byte privati usati dal processo. Un'istanza host BizTalk (che è un'applicazione .NET Framework) può ricevere un errore di memoria insufficiente prima che il valore byte virtuali raggiunga i 2 GB. Questa situazione può verificarsi anche se la memoria massima indirizzabile da un processo in una versione a 32 bit di Windows (senza l'opzione /3 GB) è di 2 GB. Per una spiegazione del motivo per cui questa situazione può verificarsi, visitare il sito Web Microsoft Developer Network (MSDN) seguente:
ASP.NET monitoraggio delle prestazioni e Quando avvisare gli amministratori

L'opzione /3GB aumenta anche il numero massimo di byte privati del processo BizTalk da 800 MB a 1800 MB. Per altre informazioni sulle prestazioni dell'applicazione .NET Framework con l'opzione /3GB abilitata, vedere Capitolo 17 - Ottimizzazione delle prestazioni delle applicazioni .NET.

La tabella seguente riepiloga queste informazioni e include i limiti pratici per byte virtuali e byte privati.

Procedura Windows Memoria indirizzabile (con un processo in grado di riconoscere indirizzi di grandi dimensioni) Limite pratico per i byte virtuali Limite pratico per i byte privati
32 bit 32 bit 2 GB 1400 MB 800 MB
32 bit A 32 bit con /3 GB 3 GB 2400 MB 1800 MB
32 bit 64 bit 4 GB 3400 MB 2800 MB
64 bit 64 bit 8 TB Non applicabile Non applicabile

Per altre informazioni sulla memoria indirizzabile per Windows a 32 bit e a 64 bit, vedere Limiti di memoria per le versioni di Windows e Windows Server.

Nella tabella seguente sono elencati i supporti PAE e 3 GB per le diverse versioni di BizTalk Server.

Prodotto PAE 3 GB
BizTalk Server 2004 No
BizTalk Server 2006
BizTalk Server 2006 R2
BizTalk Server 2009

Se è necessario abilitare l'opzione /3GB per soddisfare i requisiti di prestazioni di un computer che esegue BizTalk Server, è consigliabile aggiungere server al gruppo BizTalk. In questo modo è possibile aumentare le istanze dell'host a elevato utilizzo di memoria.

I componenti BizTalk eseguiti all'interno di un processo di Internet Information Services (IIS) possono trarre vantaggio anche quando l'opzione /3GB è abilitata.

L'opzione /3GB non è supportata nei computer che eseguono Windows SharePoint Services 2.0 o versioni successive o SharePoint Portal Server 2003 SP2 o versioni successive. L'opzione Windows Server 2003 /3GB non è supportata in Windows SharePoint Services 2.0 o versioni successive o in SharePoint Portal Server 2003 Service Pack 2 o versioni successive.

Uso di componenti personalizzati

Se si usano componenti personalizzati, ad esempio pipeline o componenti del servizio, è necessario sapere cosa fanno questi componenti. È anche necessario conoscere il potenziale effetto di questi componenti sull'utilizzo della memoria. Un problema di memoria comune si verifica quando un componente sta trasformando un documento. L'operazione di trasformazione è un'operazione a elevato utilizzo di memoria. Quando un documento viene trasformato, BizTalk Server passa il flusso di messaggi alla classe Microsoft .NET Framework XslTransform all'interno del processo BizTalk.

Un altro problema comune si verifica quando si verifica un'intensa manipolazione di stringhe. La manipolazione intensiva delle stringhe può consumare molti ricordi. Per altre informazioni sui modi per migliorare le prestazioni, vedere Miglioramento delle prestazioni del codice gestito.

Versione di .NET Framework

Microsoft .NET Framework 2.0 e .NET Framework 1.1 hanno un comportamento di memoria diverso. È quindi possibile che vengano visualizzati risultati diversi tra loro. Se si usa .NET Framework, verificare che sia installata la versione più recente di .NET Framework Service Pack 1. Questo Service Pack risolve diversi problemi di memoria noti.

Numero di processori

Common Language Runtime (CLR) include i garbage collector (GC) seguenti:

  • Workstation (Mscorwks.dll)
  • Server (Mscorsvr.dll)

Se il computer che esegue BizTalk Server è un sistema multiprocessore, .NET Framework usa la versione server del motore di esecuzione. Questo è il comportamento predefinito. Il Garbage Collector server è progettato per la velocità effettiva massima. Inoltre, il Garbage Collector server viene ridimensionato per offrire prestazioni elevate. Questo Garbage Collector alloca memoria e successivamente libera memoria per offrire prestazioni elevate nel sistema. Pertanto, un computer che esegue BizTalk Server insieme ad alcuni componenti di .NET Framework sembra avere una perdita di memoria. Tuttavia, in questo scenario, l'utilizzo elevato della memoria è il comportamento previsto. Se il computer esaurisce la memoria di sistema o se il processo smette di funzionare a causa di memoria indirizzabile insufficiente, potrebbe esistere una condizione di perdita di memoria.

Se il computer che esegue BizTalk Server è un sistema a processore singolo, .NET Framework usa la versione workstation del motore di esecuzione. Si tratta del comportamento predefinito. L'algoritmo di allocazione del Garbage Collector per workstation non è progettato per il ridimensionamento o la velocità effettiva massima. Questo Garbage Collector usa metodi di Garbage Collector simultanei. Questi metodi sono progettati per le applicazioni con interfacce utente complesse. Tali applicazioni possono richiedere una Garbage Collection più aggressiva.

Importante

In questa sezione, metodo o attività viene illustrata la procedura per modificare il Registro di sistema. È tuttavia possibile che si verifichino problemi gravi se si modifica il Registro di sistema in modo non corretto. Assicurarsi quindi di seguire attentamente questi passaggi. Per una maggiore protezione, eseguire il backup del Registro di sistema prima di modificarlo. In questo modo sarà possibile ripristinare il Registro di sistema se si verifica un problema. Per ulteriori informazioni su come eseguire backup e ripristino del Registro di sistema, vedere Backup e ripristino del Registro di sistema in Windows.

In alcuni casi, può essere appropriato eseguire la versione workstation del motore di esecuzione in un sistema multiprocessore. È possibile usare la chiave del Registro di sistema seguente per passare alla versione workstation del motore di esecuzione.

BizTalk 2006 e versioni successive

Creare la chiave del Registro di sistema String seguente CRL Hosting con i valori corrispondenti:

  • Chiave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
  • Nome valore: Flavor
  • Dati valore: wks

BizTalk 2004

Creare la chiave del Registro di sistema String seguente CRL Host con i valori corrispondenti:

  • Chiave: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
  • Nome valore: Flavor
  • Dati valore: wks

Per altre informazioni, vedere Considerazioni sulle prestazioni per Run-Time Technologies in .NET Framework.

Di seguito sono riportate le cause e le risoluzioni comuni:

Soglie di limitazione dell'utilizzo della memoria fisica e dei processi

Le soglie di limitazione dell'utilizzo della memoria dei processi e dell'utilizzo della memoria fisica possono essere modificate in BizTalk Server 2006 e nelle versioni successive.

  • Per impostazione predefinita, la soglia di limitazione dell'utilizzo della memoria di elaborazione è impostata su 25. Se questo valore viene superato e l'utilizzo della memoria del processo BizTalk è superiore a 300 MB, potrebbe verificarsi una condizione di limitazione. In un server a 32 bit è possibile aumentare il valore di utilizzo della memoria del processo a 50. In un server a 64 bit è possibile aumentare questo valore a 100. Ciò consente un maggiore consumo di memoria da parte del processo BizTalk prima che si verifichi la limitazione.

  • Il valore predefinito della soglia di limitazione dell'utilizzo della memoria fisica è 0. Questa soglia misura la memoria totale del sistema. Pertanto, se viene configurato un valore diverso da 0, può verificarsi una condizione di limitazione se un processo non BizTalk usa memoria elevata.

Soglie di limitazione della disidratazione

Le soglie di disidratazione della memoria predefinite possono causare troppa disidratazione quando le orchestrazioni vengono eseguite in un host a 64 bit. Per altre informazioni su questo problema, vedere Proprietà predefinite di disidratazione.

Nota

Gli host a 64 bit sono supportati in BizTalk Server 2006 e versioni successive.

Nell'hardware equivalente in un'istanza host a 32 bit, la disidratazione osservata è nominale quando vengono eseguite le stesse orchestrazioni usando le soglie di limitazione della disidratazione della memoria predefinite.

Poiché l'architettura a 64 bit offre uno spazio indirizzi di memoria espanso (16 TB anziché 4 GB), alle istanze host a 64 bit viene allocata più memoria rispetto alle istanze host a 32 bit. Ciò può causare il superamento delle soglie di limitazione della memoria predefinite.

Per risolvere questo comportamento, modificare i valori VirtualMemoryThrottlingCriteria e PrivateMemoryThrottlingCriteria nel file BTSNTSvc64.exe.config. Usare i contatori \Process\Virtual Bytes e \Process\Private Bytes Monitor prestazioni per determinare la quantità massima di memoria allocata da un'istanza di orchestrazione.

  • Impostare il valore OptimalUsage per entrambe le proprietà in base a quanto segue:

    • VirtualMemoryThrottlingCriteria: \Process\Virtual Bytes value + 10%
    • PrivateMemoryThrottlingCriteria: \Process\Private Bytes value + 10%
  • Impostare MaximalUsage per entrambe le proprietà sul valore OptimalUsage + 30%

Ad esempio, se il valore del contatore \Process\Virtual Byte Monitor prestazioni per un'istanza di orchestrazione è 5.784.787.695 byte (5.517 MB), impostare il valore OptimalUsage per VirtualMemoryThrottlingCr da 6.069 MB (5.784.787.695 * 1,10 = 6.363.266.464,5 byte).

Impostare il valore MaximalUsage per VirtualMemoryThrottlingCriteria su 7.889 MB (6.363.266.464,5 * 1,30 = 8.272.246.403,85 byte).

Se il valore del contatore \Process\Private Bytes Monitor prestazioni è 435689400 byte (415 MB), impostare il valore OptimalUsage per PrivateMemoryThrottlingCriteria su 457 MB (435689400 * 1,10 = 479258340 byte).

Impostare il valore MaximalUsage per PrivateMemoryThrottlingCriteria su 594 MB (479258340 * 1,30 = 623035842).

Per questo esempio, i valori seguenti verranno specificati nel file BTSNTSvc64.exe.config per ridurre la limitazione.

contatore Monitor prestazioni Memoria allocata OptimalUsage MaximalUsage
\Process\Virtual Bytes 5.784.787.695 byte (5517 MB) 6069 7889
\Process\Private Bytes 435.689.400 byte (415 MB) 457 594

Questi valori verranno quindi rappresentati nel file BTSNTSvc64.exe.config come indicato di seguito:

<xlangs>
    <Configuration>
       <Dehydration>
         <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
         <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
       </Dehydration>
    </Configuration>
</xlangs>

Per determinare quale istanza host esegue l'orchestrazione, è possibile trovare la corrispondenza con il processo ID dei contatori \BizTalk: Messaging\ID Process e \Process\ID Process Monitor prestazioni. Controllare quindi il valore medio visualizzato per i contatori \Process\Virtual Bytes e \Process\Private Bytes Monitor prestazioni corrispondenti.

Nota

Informazioni che l'utente deve notare anche in caso di scrematuraLa disidratazione elevata può causare una riduzione significativa delle prestazioni quando il BizTalkMsgBoxDb database è in esecuzione in SQL Server 2008.

BizTalk Server Service Pack e aggiornamenti cumulativi

BizTalk Server Service Pack e gli aggiornamenti cumulativi includono le correzioni più recenti. Questi includono quelli che interessano i problemi noti System.OutOfMemoryException .

HeapDeCommitFreeBlockThreshold

Per impostazione predefinita, il valore della chiave del HeapDeCommitFreeBlockThreshold Registro di sistema è 0. Un valore pari a 0 indica che il gestore heap esegue il de-commit di ogni pagina di 4 kilobyte (KB) che diventa disponibile. Le operazioni di de-commit possono causare la frammentazione della memoria virtuale. Le dimensioni dell'impostazione HeapDeCommitFreeBlockThreshold nel gestore heap dipenderanno dal tipo di lavoro che il sistema sta eseguendo. Una dimensione di 0x00040000 è un valore iniziale consigliato.

Prima di modificare il valore della chiave del Registro di HeapDeCommitFreeBlockThreshold sistema, considerare le informazioni seguenti:

  • Questa modifica si applica solo ai problemi di frammentazione della memoria.
  • Questa modifica è a livello di sistema. Pertanto, la maggior parte dei processi userà più memoria all'avvio.
  • Considerare questa modifica solo per i sistemi che hanno BizTalk Server come missione primaria.

Per ridurre la frammentazione della memoria virtuale, è possibile aumentare le dimensioni dell'impostazione HeapDeCommitFreeBlockThreshold nella gestione heap modificando il valore della chiave del Registro di sistema seguente in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager:

  • Nome valore: HeapDeCommitFreeBlockThreshold
  • Tipo di valore: REG_DWORD
  • Dati valore: 0x00040000 (è il valore iniziale consigliato).
  • Valore predefinito: non presente

Operazioni di trasformazione

Quando BizTalk Server esegue operazioni di trasformazione XML su messaggi di dimensioni piuttosto grandi in una porta di ricezione, in una porta di trasmissione o in XLANG, le trasformazioni XSL caricano l'intero messaggio in memoria.

Per risolvere il problema, utilizzare uno dei seguenti metodi:

  • Ridurre il numero di messaggi che BizTalk Server elabora contemporaneamente.
  • Ridurre le dimensioni del messaggio XML che viene trasformato.

L'oggetto System.Policy.Security.Evidence viene spesso usato nelle trasformazioni e può consumare molta memoria. Quando una mappa contiene uno scripting functoid che usa C# inline (o qualsiasi altro linguaggio inline), l'assembly viene creato in memoria. L'oggetto System.Policy.Security.Evidence usa l'oggetto dell'assembly chiamante effettivo. Questa situazione crea un oggetto rooted che non viene eliminato fino al riavvio del servizio BizTalk.

La maggior parte dei BizTalk functoids predefiniti viene implementata come script inline. Questi elementi possono causare System.Byte[] la raccolta di oggetti in memoria. Per ridurre al minimo il consumo di memoria, è consigliabile inserire qualsiasi mappa che le functoids usa in un piccolo assembly. Fare quindi riferimento a tale assembly. Usare il grafico seguente per determinare l'uso functoids dello script inline e che functoids non usano script inline.

Nella seconda colonna , Sì significa che questo functoid viene implementato come script inline e che causerà System.Byte[] la raccolta di oggetti in memoria. No significa che questo functoid non viene implementato come script inline e che non causerà System.Byte[] la raccolta di oggetti in memoria.

Functoid Script inline?
Tutti i functoid stringa
Tutti i functoid matematici
Tutti i functoid logici tranne IsNil
Functoid IsNil logico No
Tutti i functoid data/ora
Tutti i functoid di conversione
Tutti i functoid scientifici
Tutti i functoid cumulativi
Tutti i functoid del database No
Functoid avanzati Script inline?
Functoid a ciclo continuo No
functoid Value-Mapping flattening No
Asserzione functoid No
Functoid estrattore tabella No
Functoid ciclo tabella No
Functoid di script con C inline#
Functoid di script con JScript.NET inline
Functoid di script con Visual Basic .NET inline
Functoid di script con XSLT inline No
Functoid di script con modello di chiamata XSLT inline No
Functoid di script che chiama assembly esterno No
Nil Value Functoid No
Functoid mapping di valori No
Functoid copia di massa No
Functoid iterazione No
Functoid indice No
Functoid Conteggio record No

BizTalk Server 2006 e versioni successive migliorano significativamente la gestione della memoria per documenti di grandi dimensioni. A tale scopo, BizTalk Server implementa una soglia configurabile per le dimensioni dei messaggi per il caricamento di documenti in memoria durante le operazioni di trasformazione. La soglia predefinita per le dimensioni dei messaggi è 1 MB. Per altre informazioni sull'impostazione TransformThreshold, vedere Come BizTalk Server elabora messaggi di grandi dimensioni.

Valori di attributo di grandi dimensioni e valori di elementi di grandi dimensioni

Quando BizTalk Server esegue una pipeline di ricezione o una pipeline di trasmissione in un documento XML, il payload viene elaborato in memoria se il documento contiene una o più delle entità seguenti:

  • Valori di attributo di grandi dimensioni
  • Valori di elementi di grandi dimensioni
  • Tag di attributi o elementi di grandi dimensioni

Per risolvere questo problema, limitare le dimensioni di queste entità. Se questo metodo non è possibile, assicurarsi che l'istanza host BizTalk non eserciti contemporaneamente più documenti come questi.

Componenti della pipeline personalizzati

Si usa un componente della pipeline personalizzato che carica l'intero flusso in memoria. Tutti i componenti inclusi in BizTalk Server, ad eccezione delle trasformazioni, supportano lo streaming. Questi componenti non usano la quantità di memoria necessaria durante lo streaming. Tuttavia, i componenti della pipeline personalizzati potrebbero non supportare lo streaming.

Streaming in stato di stress elevato

L'invio di host esaurisce la memoria quando operano in situazioni di stress elevato. BizTalk Server invia pipeline e le schede di trasmissione supportano lo streaming. In streaming, ogni componente carica un piccolo frammento del flusso in memoria. Poiché ogni messaggio include altre strutture di dati, insieme a un contesto di messaggio che può essere significativo o piccolo, questo comportamento influisce sul comportamento di BizTalk Server in caso di stress elevato.

Il comportamento di BizTalk Server è influenzato dal fatto che il motore carica un numero pre-configurato di messaggi. Il numero di messaggi caricati dal motore è basato sui valori visualizzati nel campo LowWaterMark e nel campo HighWaterMark della Adm_serviceClass tabella. La Adm_serviceClass tabella si trova nel database di gestione BizTalk. Questi valori controllano il numero di messaggi che BizTalk Server elaborano o inviano contemporaneamente.

Il valore HighWaterMark è il numero totale di messaggi elaborati contemporaneamente dal motore. Il valore predefinito è 200 messaggi per CPU. Pertanto, in un server con 8 processori, l'host di invio tenterà di elaborare 1.600 messaggi (200 * 8) contemporaneamente.

Se si presuppone che ogni messaggio sia 50 KB, i messaggi sono uguali a 80 MB (1.600 * 50=80.000 KB).

Per risolvere questo problema, è possibile modificare il valore HighWaterMark e il valore LowWaterMark nel database. I valori usati dipendono dalle dimensioni dei messaggi. Per BizTalk Server 2006 e versioni successive, è possibile modificare le impostazioni di limitazione host predefinite.

Provare a semplificare il problema

Se è stata identificata una perdita di memoria, provare a determinare la causa rimuovendo i componenti personalizzati o semplificando una mappa. Provare anche a riprodurre il problema usando una semplice orchestrazione o una soluzione semplice. In genere, è necessario creare host di ricezione separati per le schede di ricezione. È anche consigliabile creare host di invio separati per le schede di trasmissione. Quando si usa questo metodo, ogni adattatore può essere eseguito in un processo separato. Pertanto, se il processo di BizTalk Server presenta una condizione di memoria insufficiente, si saprà quali componenti sono coinvolti.

Procedura di risoluzione dei problemi

Per risolvere i problemi di una condizione di memoria insufficiente, usare lo strumento Diagnostica di debug per monitorare le allocazioni di memoria nel tempo. Lo strumento Diagnostica di debug può creare e analizzare un file di dump della perdita di memoria (.dmp). Quando si risolve il problema delle perdite di memoria, l'obiettivo è collegare Leaktrack.dll prima che la condizione di memoria elevata venga riprodotta per acquisire la crescita della memoria nel tempo. Leaktrack.dll è incluso nello strumento Diagnostica di debug.

  1. Installare lo strumento di diagnostica di debug.

    Il file seguente è disponibile per il download dall'Area download Microsoft:
    Scaricare ora il pacchetto dello strumento di diagnostica di debug

    Per altre informazioni su come scaricare i file di supporto Microsoft, vedere Come ottenere i file di supporto Microsoft da Servizi online.

    Microsoft ha analizzato questo file alla ricerca di virus. Microsoft ha usato il software di rilevamento dei virus più recente disponibile alla data di pubblicazione del file. Il file viene archiviato in server con sicurezza avanzata che consentono di evitare modifiche non autorizzate al file.

  2. Usare Monitor prestazioni per raccogliere dati sulle prestazioni del sistema. Questi dati possono fornire indicatori importanti sull'efficienza dell'ambiente BizTalk Server. L'obiettivo è acquisire le prestazioni del processo nel tempo. Abilitare pertanto Monitor prestazioni registrazione prima che si verifichi la perdita di memoria.

Come usare la registrazione Monitor prestazioni

Le sezioni seguenti descrivono come usare la registrazione di Performance Monitor.

Selezionare i dati da registrare

Per selezionare i dati da registrare, usare il metodo appropriato per il sistema operativo:

  • Per Windows Server 2008 e Windows Server 2008 R2
    1. In Strumenti di amministrazione aprire Affidabilità e Monitor prestazioni.

    2. Fare clic con il pulsante destro del mouse su Monitor prestazioni, scegliere Nuovo e quindi fare clic su Set di agenti di raccolta dati.

    3. Nella casella Nome digitare un nome descrittivo e quindi fare clic su Avanti.

    4. Prendere nota della directory radice e quindi fare clic su Avanti.

    5. Fare clic su Avvia il set di agenti di raccolta dati ora e quindi su Fine.

    6. Espandere Set di agenti di raccolta dati, espandere Definito dall'utente e quindi selezionare il file.

    7. Fare clic con il pulsante destro del mouse su Log di Monitoraggio di sistema e quindi scegliere Proprietà.

    8. Fare clic su Aggiungi nella scheda Contatori delle prestazioni . Selezionare gli oggetti seguenti e quindi fare clic su Aggiungi dopo aver selezionato ogni oggetto:

      • Eccezioni CLR .Net
      • Memoria CLR .Net
      • BizTalk: Messaggistica
      • BizTalk: TDDS
      • Memoria
      • Procedura
      • Processore
      • Orchestrazioni XLANG/s

      Se SQL Server è locale, aggiungere anche gli oggetti seguenti:

      • SQLServer: database
      • SQLServer: statistiche generali
      • SQLServer: Gestione memoria
    9. Fare clic su OK.

    10. Modificare la casella Valore intervallo di campionamento su 5 secondi.

      Nota

      Il valore intervallo di campionamento e l'ora di inizio del monitoraggio sono soggettivi. Questi valori dipendono da quando viene riprodotta la perdita di memoria. Poiché il file di log può essere grande, specificare un intervallo in cui è possibile ottenere le informazioni necessarie senza sovraccaricare il server.

    11. Fare clic su OK.

Per interrompere la raccolta dei dati, fare clic su Arresta dal menu Azione .

  • Per Windows Server 2003 o per Windows XP

    1. Espandere Log e avvisi delle prestazioni.

    2. Fare clic con il pulsante destro del mouse su Log contatori e quindi scegliere Nuove impostazioni di log. Verrà visualizzata la finestra di dialogo Nuove impostazioni log .

    3. Nella casella Nome digitare un nome descrittivo e quindi fare clic su OK.

    4. Si noti il percorso del file di log. È anche possibile fare clic sulla scheda File di log e quindi su Configura per modificare il percorso del file di log.

    5. Fare clic su Aggiungi contatori.

    6. Selezionare Tutti i contatori e Tutte le istanze.

    7. Nell'elenco Oggetto prestazioni selezionare gli oggetti seguenti. Fare clic su Aggiungi dopo aver selezionato ogni oggetto.

      • Eccezioni CLR .Net
      • Memoria CLR .Net
      • BizTalk: Messaggistica
      • BizTalk: TDDS
      • Memoria
      • Procedura
      • Processore
      • Orchestrazioni XLANG/s

      Se SQL Server è locale, aggiungere anche gli oggetti seguenti:

      • SQLServer: database
      • SQLServer: statistiche generali
      • SQLServer: Gestione memoria
    8. Scegliere Chiudi.

    9. Modificare il valore in Intervallo di campionamento dati in 5 secondi.

      Nota

      Il valore intervallo di campionamento dati e l'ora di inizio del monitoraggio sono soggettivi. Questi valori dipendono da quando viene riprodotta la perdita di memoria. Poiché il file di log può essere grande, specificare un intervallo in cui è possibile ottenere le informazioni necessarie senza sovraccaricare il server.

    10. Fare clic su OK. Per interrompere la raccolta dei dati, fare clic con il pulsante destro del mouse sul nome del log dei contatori e quindi scegliere Arresta.

Ottenere il file di dump

Per ottenere il file di dump, usare uno dei metodi seguenti:

Metodo 1: Automatico

La creazione di una regola di perdita di memoria e gestione con DebugDiag è l'approccio consigliato per acquisire un dump di memoria. La regola Memory and Handle Leak si collega automaticamente Leaktrack.dll. Viene usato per tenere traccia delle allocazioni di memoria. Per creare la regola memoria e gestire la perdita, seguire questa procedura:

  1. Avviare Lo strumento di diagnostica di debug 1.1.

  2. Selezionare Memoria e Gestisci perdita e quindi fare clic su Avanti.

  3. Selezionare il processo Btsntsvc.exe e quindi fare clic su Avanti.

  4. Nella pagina Configura regola perdita seguire questa procedura:

    1. Fare clic per selezionare la casella di controllo Avvia immediatamente il rilevamento della memoria quando viene attivata la regola . In caso contrario, è possibile specificare un tempo di riscaldamento prima cheLeakTrack.dll venga inserito nel processo di BTSNTSvc.exe.

    2. Fare clic su Configura e quindi eseguire le operazioni seguenti:

      • Verificare che sia selezionata l'opzione Crea automaticamente una regola di arresto anomalo . Selezionando questa opzione, verrà creato automaticamente un dump di memoria se il processo di BTSNTSvc.exe si arresta.

      • Fare clic per selezionare la casella di controllo Genera un utentedump quando i byte virtuali raggiungono e mantenere il valore predefinito 1024.

      • Fare clic per selezionare la casella di controllo e ogni casella di controllo aggiuntiva e mantenere il valore predefinito 200. Selezionando l'opzione copertura dei byte virtuali, verrà creato automaticamente un dump di memoria quando i byte virtuali usano 1024 MB. Se i byte virtuali aumentano di 200 MB, verrà creato automaticamente un altro dump di memoria.

    3. Fare clic su Salva & Chiudi.

    4. Scegliere Avanti.

    5. Nella pagina Seleziona percorso dump e nome regola fare clic su Avanti.

      Nota

      È anche possibile modificare il percorso del file di dump nella casella Percorso userdump in questa pagina.

    6. Fare clic su Fine per rendere attiva la regola ora.

      Nota

      Lo stato della regola è ora Rilevamento. Ogni volta che viene creato un dump di memoria, il valore aumenta nella colonna Userdump Count della scheda Regole . Il percorso predefinito del dump della memoria è C:\Program Files\DebugDiag\Logs.

Metodo 2: Manuale

È anche possibile collegare manualmente Leaktrack.dll e ottenere manualmente il file di dump della memoria. In questo modo è possibile controllare quando viene creato il dump di memoria. A tal fine, attenersi alla seguente procedura:

  1. Avviare Lo strumento di diagnostica di debug 1.1.
  2. Fare clic sulla scheda Processi .
  3. Fare clic con il pulsante destro del mouse sul processo di Btsntsvc.exe e quindi scegliere Monitor for Leaks (Monitor per perdite).
  4. Nella finestra di dialogo Strumento di diagnostica di debug fare clic su e quindi su OK.

Creare una regola di arresto anomalo per monitorare lo stesso processo Btsntsvc.exe nel caso in cui il processo si arresti prima di poter creare il dump della memoria:

  1. Avviare Lo strumento di diagnostica di debug 1.1.
  2. Selezionare Arresto anomalo e quindi fare clic su Avanti.
  3. Selezionare un processo specifico e quindi fare clic su Avanti.
  4. Selezionare lo stesso processo Btsntsvc.exe e quindi fare clic su Avanti.
  5. Nella pagina Configurazione avanzata (facoltativo) fare clic su Avanti.
  6. Nella finestra di dialogo Seleziona percorso dump e nome regola (facoltativo) fare clic su Avanti.
  7. Selezionare Attiva la regola ora e quindi fare clic su Fine.

Quando il processo raggiunge il 60-80% della RAM, fare clic con il pulsante destro del mouse sul processo di Btsntsvc.exe e quindi scegliere Crea userdump completo. Se il processo BizTalk si interrompe prima di poter creare il dump utente, la regola di arresto anomalo dovrebbe essere effettiva e creare il dump della memoria.

Arrestare la registrazione Monitor prestazioni

Se si acquisisce un dump di memoria e si Monitor prestazioni dati, arrestare Monitor prestazioni registrazione circa due minuti dopo la creazione del dump di memoria.

Analizzare il file di dump

Per determinare la causa di una perdita di memoria, è possibile usare lo strumento Diagnostica di debug per analizzare il file di dump. A tal fine, attenersi alla seguente procedura:

  1. Fare clic sulla scheda Analisi avanzata .
  2. Fare clic su Aggiungi file di dati e quindi individuare il file di .dmp.
  3. Selezionare lo script di analisi della pressione della memoria e quindi fare clic su Avvia analisi.

Per impostazione predefinita, nella cartella verrà creato C:\Program Files\DebugDiag\Reports un file del report di analisi (file con estensione mht) al termine dell'analisi. Il file di report verrà visualizzato anche nel browser. Il file di report contiene i risultati dell'analisi. Inoltre, il file di report può contenere raccomandazioni su come risolvere la perdita di memoria.

Se si usano DLL personalizzate, è possibile aggiungere il percorso dei simboli dei file con estensione pdb personalizzati per l'analisi. A tal fine, attenersi alla seguente procedura:

  1. Aprire lo strumento Diagnostica di debug.
  2. Scegliere Opzioni e impostazioni dal menu Strumenti.
  3. Nella casella Percorso ricerca simboli per il debug digitare il percorso del simbolo.

Per assistenza nell'analisi del file di dump, contattare il Servizio Supporto Tecnico Clienti Microsoft. Per un elenco completo dei numeri di telefono e delle informazioni sui costi di supporto, visitare il supporto tecnico.

Prima di contattare il Servizio Supporto Tecnico Clienti, comprimere il file di dump, il log Monitor prestazioni, il file del report di analisi e i log eventi aggiornati (file con estensione evt). Potrebbe essere necessario inviare questi file a un tecnico del supporto BizTalk Server.