Cum se depanează o irosire de memorie sau excep?ie afară-de-memorie în procesul de BizTalk Server

Traduceri articole Traduceri articole
ID articol: 918643 - View products that this article applies to.
Măriți totul | Reduceți totul

În această pagină

REZUMAT

Pierderi de memorie sunt o problemă comună. Trebuie să încercați mai multe etape pentru a găsi cauza specifice o irosire de memorie sau excep?ie afară-de-memorie (OOM) în Microsoft BizTalk Server. Acest articol discută despre lucruri importante să ia în considerare atunci când vă sunt evaluarea Utilizare memorie și posibil problemele de memorie. Aceste considerente includ următoarele:
  • RAM fizică
  • Prelucrarea mari mesaj
  • Utilizarea / 3 GB comuta
  • Utilizarea componentelor particularizate
  • Ce versiune de Microsoft .NET Framework sistemul se execută
  • Numărul de procesoare

INTRODUCERE

Acest articol descrie cum se depanează o irosire de memorie sau excep?ie afară-de-memorie în procesul de BizTalk Server Microsoft BizTalk Server.

INFORMAȚII SUPLIMENTARE

Procesul de BizTalk Server poate fi confruntă cu o irosire de memorie când Utilizare memorie în Microsoft Windows Task Manager consumă mai mult de 50 la sută din RAM fizică. O irosire de memorie poate provoca o excepție afară-de-memorie când Utilizare memorie crește până când procesul rulează din memoria de sistem sau până când procesul se dezactivare funcționarea.

Când apare această problemă, un mesaj de avertizare care seamănă cu următorul mesaj se înregistrează în Jurnalul de evenimente:

Eveniment Tip: avertisment
Eveniment Categorie: (1)
ID eveniment: 5410
Descriere: A apărut o eroare care necesită serviciul BizTalk pentru a termina. Cele mai comune cauze sunt o neașteptată de eroare de memorie și incapacitatea de a conecta sau o pierdere de conectivitate la una din bazele acoperire de date BizTalk. Serviciul va shutdown și auto-restart la 1 minut. Dacă baza acoperire de date problematică rămâne indisponibilă, va repeta acest ciclu.
Mesaj de eroare: excepție de tip System.OutOfMemoryException a fost aruncat.
Sursă de eroare:
BizTalk gazdă Nume: BizTalkServerApplication
Ferestre serviciu Nume: BTSSvc {DCC899FE-C62F-41BE-851A-8720B2EB9C14}

Tip de eveniment: avertisment
Eveniment Categorie: (1)
ID eveniment: 5410
Descriere: Eroare care necesită serviciul BizTalk pentru a termina. Cele mai comune cauze sunt următoarele: 1) la o neașteptată de eroare de memorie. SAU 2) incapacitatea de a conecta sau o pierdere de conectivitate la una din bazele acoperire de date BizTalk. Serviciul va shutdown și auto-restart la 1 minut. Dacă baza acoperire de date problematică rămâne indisponibilă, va repeta acest ciclu.
Mesaj de eroare: excepție de tip "System.OutOfMemoryException" a fost aruncat.
Eroare sursă: mscorlib
BizTalk gazdă Nume: BizTalkServerApplication
Ferestre serviciu Nume: BTSSvc$ BizTalkServerApplication

Considera?ii importante

Fizică RAM și Utilizare memorie

Pentru că poate fi comportamentul așteptat pentru un proces de utilizare aproximativ jumătate RAM fizică, utilizarea Utilizare memorie ca orientare. De exemplu, dacă BizTalk Server are 4 gigaocteți (GO) de RAM și procesul de BizTalk Server utilizează aproximativ 500 de megaocteți (MO) de RAM, poate nu existe scurgeri. Dacă procesul de BizTalk Server utilizează aproximativ 1 GB de RAM, ar putea exista o irosire de memorie sau o situație high memory. Consumul de memorie pot fi cauzate de o procedură stocată de lungă durată sau orchestrație. Asigurați-vă că știți cât de mult memorie gazdă BizTalk utilizează de obicei pentru a determina dacă se produce o irosire memorie sau high memory condiție.

Mesaje mari

Când BizTalk Server procesează mesajele mare, sistemul pare a avea o irosire de memorie. Cu toate acestea, mesajele pot fi folosind o cantitate mare de memorie. Pentru mai multe informații despre mesajele de mare, vizitați următoarele site-uri Rețea Microsoft pentru dezvoltatori (MSDN):
http://blogs.msdn.com/biztalk_core_engine/Archive/2005/02/28/381700.aspx

http://msdn.Microsoft.com/en-us/library/aa560481 (BTS.10) .aspx

De asemenea, a considera că high Utilizare memorie poate fi de așteptat dacă BizTalk Server este prelucrarea mesajelor mari. Poate dori?i să face?i upgrade la hardware-ul îndeplinesc cerin?ele de performan?ă a BizTalk Server din mediul dvs.

Cât marcă de timp este nevoie pentru a reproduce o irosire memorie

Pierderi de memorie poate apărea imediat sau ei pot acumula peste marcă de timp. Ambele scenarii sunt comune.

Utilizarea comutatorul de 3 GB pe computere cu 32-bit

De obicei, un proces poate accesa 2 GB de spațiu de adrese virtuale. Comutatorul de 3 GB este o opțiune pentru sisteme care necesită mai multă memorie adresabilă. Această opțiune poate îmbunătăți Utilizare memorie de prelucrare a mesajelor. Cu toate acestea, comutatorul de 3 GB permite numai 1 GB de memorie adresabilă pentru opera?iunile de mod nucleu. În plus, acest parametru poate crește riscul de a piscina memorie.

Pentru mai multe informații despre 3 GB comuta, vizitați următoarele site-ul Rețea Microsoft pentru dezvoltatori (MSDN):
http://msdn.Microsoft.com/en-us/library/ms791558.aspx
Când comutatorul de 3 GB este activat pe o versiune pe 32 de biți de Windows, procesul poate accesa 3 GB de adrese virtuale spațiu dacă procesul este mare-adresa conștient. Este un proces mare-adresa conștient când executabil a IMAGE_FILE_LARGE_ADDRESS_AWARE de pavilion în antetul de imagine. Deoarece procesul de BizTalk este mare-adresa conștient, BizTalk vor beneficia de la comutatorul de 3 GB.

Dacă un 32-bit BizTalk gazdă instanță se execută pe o versiune de 64-bit de Ferestre (AMD64), BizTalk proces beneficiile de 4 GB memorie de spațiu de adrese deoarece BizTalk este mare-adresa conștient. Prin urmare, se deplasează aplicațiile high memory la un server de 64-bit poate fi cea mai bună soluție.

Un proces de BizTalk 64-bit on un 64-bit traducere de Ferestre (AMD64) a 8 TB de memorie adresabilă.

Se recomandă, de asemenea, bytes virtuale și octeți private utilizate de procesul. Un exemplu de BizTalk gazdă (care este un.NET Framework aplicarea) pot primi o afară de eroare de memorie înainte de valoarea de octeți Virtual atinge 2 GB. Aceasta se poate întâmpla chiar dacă memoria maximă adresabili printr-un proces pe o versiune pe 32 de biți de Windows (fără comutatorul de 3 GB ) este de 2 GB. Pentru o explicație de ce aceasta se poate întâmpla, vizitați următoarele site-uri Rețea Microsoft pentru dezvoltatori (MSDN):
http://msdn.Microsoft.com/en-us/library/ms972959.aspx
http://blogs.msdn.com/Tess/Archive/2005/11/25/496898.aspx
Comutatorul de 3 GB , de asemenea, crește maximă privat octeți a procesului BizTalk la 800 MB de 1 800 MB. Pentru mai multe informații despre.NET Framework aplicarea performanță cu comutatorul de 3 GB activat, vizitați următoarele site-ul Rețea Microsoft pentru dezvoltatori (MSDN):
http://msdn2.Microsoft.com/en-us/library/ms998583.aspx
Următorul tabel rezumă această informație și include limitele practice pentru virtual de octeți și privat octeți.
Reduceți tabelulMăriți tabelul
ProcesWindowsMemorie adresabilă (cu un proces adresa-aware mare)Limita practice pentru virtual octețiLimita practice pentru privat octeți
32-bit32-bit2 GB1 400 MB800 MB
32-bit32-bit cu 3 GB3 GB2400 MB1800 MB
32-bit64-bit4 GB3400 MB2 800 MB
64-bit64-bit8 TBnu se aplicănu se aplică
Pentru mai multe informații despre memoria adresabilă pentru 32-bit vs-64-bit Windows, vizitați următorul site Rețea Microsoft pentru dezvoltatori (MSDN):
http://msdn.Microsoft.com/en-us/library/aa366778.aspx
Următorul tabel listează PAE și 3 GB supportability pentru diferite versiuni de BizTalk Server.
Reduceți tabelulMăriți tabelul
ProdusPAE3 GB
BizTalk Server 2004danu
BizTalk Server 2006dada
BizTalk Server 2006 R2dada
BizTalk Server 2009dada
Dacă trebuie să activați parametrul 3 GB pentru a satisface cerin?ele de performan?ă a computerului care este execută BizTalk Server, poate doriți să ia în considerare adăugarea de fermă de servere la grupul BizTalk. Acest lucru vă permite să scară la instanțele memorie gazdă.

BizTalk componente care se execută în interiorul unui proces de Internet Information Services (IIS) pot beneficiază, de asemenea, atunci când comutatorul de 3 GB este activată.

Comutatorul de 3 GB nu este acceptată pe computere care execută Windows SharePoint Services 2.0 sau versiunile ulterioare sau SharePoint Portal Server 2003 SP2 sau versiuni mai recente. Pentru mai multe informații, faceți clic pe următorul număr de articol pentru a vedea articolul în bază de cunoștințe Microsoft:
933560Comutatorul de 3 GB Windows Server 2003 nu este acceptată în Windows SharePoint Services 2.0 sau în versiunile ulterioare SharePoint Portal Server 2003 pachet Service Pack 2 sau în versiunile ulterioare

Utilizarea componentelor particularizate

Dacă utilizați componente particularizate, cum ar fi conductele sau consolidare servicii componente, trebuie să știți ce face aceste componente. Trebuie să știi, de asemenea, efectul poten?ial al acestor componente pe Utilizare memorie. A problemă comună de memorie apare atunci când o componentă este transformarea unui document. The operațiunea de transformare este o operațiune de memorie. Când un document este transformat, BizTalk Server trece curent de mesaj de la Microsoft .NET Cadru XslTransform clasa în cadrul procesului de BizTalk.

O altă problemă comună apare când există manipulare string intensivă. Șir intensivă manipulare poate consuma o mulțime de memorie. Pentru mai multe informații despre moduri de îmbunătăți performanța, vizitați următoarele site-ul Rețea Microsoft pentru dezvoltatori (MSDN):
http://msdn2.Microsoft.com/en-us/library/ms998547

Versiune.NET Framework

Microsoft .NET Framework 2.0 și.NET Framework 1.1 au memorie diferite comportament. Prin urmare, este posibil să vedeți rezultate diferite între ele. Dacă utilizați.NET Framework, să confirme că cele mai recente.NET cadru pachet Service Pack 1 este instalat. Aceste pachete de service adresa mai multe probleme de memorie cunoscut. Pentru mai multe informații, faceți clic pe următoarele numere de articol:

945757 Problemele care sunt fixate în.NET Framework 2.0 pachet Service Pack 1
867460 Listă de bug-uri care sunt fixate în.NET Framework 1.1 pachet Service Pack 1

Numărul de procesoare

motor comun de execuție pentru limbaje (CLR) are următoarele gunoi Colectionari (GCs):
  • Stație de lucru (Mscorwks.dll)
  • Server (Mscorsvr.dll)
În cazul în care computerul pe care se execută BizTalk Server este un sistem multiprocesor,.NET Framework utilizează versiunea Server de motorul de executare. Acesta este comportamentul implicit. Colectorul gunoiului Server este proiectat pentru throughput maximă. În plus, colector de gunoi Server cântare pentru a oferi performanță foarte mare. Acest Colectorul gunoiului alocă memorie și apoi mai târziu eliberează memorie pentru a oferi performanță înaltă pe sistem. Prin urmare, un computer care execută BizTalk Server împreună cu unele.NET Framework componente pare a avea o irosire de memorie. Cu toate acestea, în acest scenariu, high Utilizare memorie este comportamentul așteptat. În cazul în care computerul execută de memorie de sistem sau dacă procesul se dezactivare de lucru din cauza memoriei insuficiente adresabili, poate exista o condiție de scurgere de memorie.

Dacă computerul care execută BizTalk Server este un sistem unic de procesor,.NET Framework utilizează versiunea de stație de lucru de motorul de executare. Aceasta este implicit comportament. Colectorul gunoiului Workstation alocarea algoritmul nu este proiectat pentru scalare sau, pentru throughput maximă. Utilizează acest Colectorul gunoiului Colectorul gunoiului concurente metode. Aceste metode sunt proiectate pentru aplicații care au interfețe utilizator complexe. Aceste cereri pot solicita colectare gunoi mai agresiv.

Important Această secțiune, metoda sau activitate conține pași care-ți spun cum să modificați registry-ul. Cu toate acestea, ar putea apărea probleme grave dacă modificați registry incorect. Prin urmare, asigurați-vă că urmați acești pași, cu atenție. Pentru o protecție sporită, rezervă de registry, înainte de a se modifica. Apoi, restabiliți registry dacă apare o problemă. Pentru mai multe informații despre modul de rezervă și restaurați registry, faceți clic pe următorul număr de articol pentru a vedea articolul în bază de cunoștințe Microsoft:
322756 Cum la spre spate sus și restaurarea registry în Windows
Uneori, poate fi necesar să executați versiunea de stație de lucru de motorul de executare pe un sistem multiprocesor. Puteți utiliza următoarea cheie de registry pentru a comuta de la versiunea de stație de lucru de motorul de executare.

BizTalk 2006 și versiunile ulterioare

Creați următoarea cheie de registry LCR gazduieste șir cu valorile corespunzătoare:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR gazduieste

Nume: aroma
Date: wks

BizTalk 2004

Creați următoarea cheie de registry LCR gazduieste șir cu valorile corespunzătoare:

Gazdă HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc {GUID} \CLR

Nume: aroma
Date: wks

Pentru mai multe informații, vizitați următoarele site-uri Rețea Microsoft pentru dezvoltatori (MSDN):
http://msdn2.Microsoft.com/en-us/library/ms973838

http://blogs.msdn.com/Tess/Archive/2008/04/17/how-does-the-GC-work-and-what-are-the-sizes-of-the-different-generations.aspx

Comune cauze și rezoluțiile

Procesul de Utilizare memorie și utilizarea memoriei fizice supraîncărcarea praguri

Procesul de Utilizare memorie și utilizarea memoriei fizice supraîncărcarea praguri pot fi modificate în BizTalk Server 2006 și în versiunile ulterioare.
  • implicit, Procesul de Utilizare memorie limitare prag este stabilit la 25. În cazul în care această valoare este depă?ită ?i BizTalk procesul de Utilizare memorie este mai mult de 300 MB, poate apărea o condiție de limitare. Pe un server de 32 de biți, puteți crește valoarea procesul Utilizare memorie de 50. Pe un server de 64 de biți, puteți crește această valoare la 100. Acest lucru permite mai mult consumul de memorie de procesul de BizTalk înainte de supraîncărcarea apare.
  • The Utilizare memorie fizică pragul de limitare are o valoare prestabilită 0. Acest prag măsuri memoria de sistem totală. Prin urmare, dacă este configurată o valoare diferită de 0, stare limitare poate apărea dacă un proces de non-BizTalk este folosind high memory.
Pentru mai multe informații despre pragurile limitare, vizitați următoarele site-ul Rețea Microsoft pentru dezvoltatori (MSDN):
http://msdn.Microsoft.com/en-us/library/aa559628.aspx

Deshidratarea supraîncărcarea praguri

Memorie implicit deshidratare pragurile poate provoca prea mult deshidratare când orchestrations se execută pe un 64-bit gazdă. Pentru mai multe informații despre această problemă, consultați subiectul Deshidratare Default Properties pe site web Rețea Microsoft pentru dezvoltatori (MSDN) următoarele:
http://msdn.Microsoft.com/en-us/library/aa560586.aspx
Notă 64-bit gazdă sunt acceptate în BizTalk Server 2006 și versiunile ulterioare.

Pe hardware-ul echivalent într-o instanță de 32-bit gazdă, observate deshidratarea este nominală când orchestrations același sunt executați utilizând implicit memorie deshidratare supraîncărcarea praguri.

Deoarece arhitectura pe 64 de biți oferă spațiu de adrese de memorie extinsă (16 TB în loc de 4 GB), 64-bit gazdă instanțe sunt alocate semnificativ mai multă memorie decât-32-bit gazdă instanțe. Acest lucru poate cauza implicit memorie limitare pragurile care trebuie depă?ite.

Pentru a rezolva acest comportament, modificați valorile VirtualMemoryThrottlingCriteria și PrivateMemoryThrottlingCriteria în fișierul BTSNTSvc64.exe.config. Utilizați octeți Process\Virtual și contoare de Process\Private Bytes Performance Monitor pentru a determina cea mai mare sumă de memorie care este fiind alocate de către o instanță de orchestrație.
  • Setarea valorii OptimalUsage pentru ambele proprietăți bazate pe următoarele:
    VirtualMemoryThrottlingCriteria: \Process\Virtual Bytes valoarea + 10 %
    PrivateMemoryThrottlingCriteria: \Process\Private Bytes valoarea + 10 %
  • MaximalUsage set pentru ambele proprietăți la valoarea de OptimalUsage + 30 %
De exemplu, dacă \Process\Virtual Bytes Performance Monitor contor de valoare pentru o instanță de orchestrație este 5,784,787,695 bytes (5,517 MB), setați valoarea OptimalUsage pentru VirtualMemoryThrottlingCriteria la 6,069 MB (5,784,787,695 * 1.10 = 6,363,266,464.5 bytes). Setați valoarea MaximalUsage pentru VirtualMemoryThrottlingCriteria la 7,889 MB (6,363,266,464.5 * 1.30 = 8,272,246,403.85 bytes).

Dacă \Process\Private Bytes Performance Monitor contor de valoare este 435689400 bytes (415 MB), setați valoarea OptimalUsage pentru PrivateMemoryThrottlingCriteria la 457 MB (435689400 * 1.10 = 479258340 bytes). Setați valoarea MaximalUsage pentru PrivateMemoryThrottlingCriteria la 594 MB (479258340 * 1.30 = 623035842).

Pentru acest exemplu, următoarele valori ar fi specificată în fișierul BTSNTSvc64.exe.config pentru a reduce supraîncărcarea.
Reduceți tabelulMăriți tabelul
Performance Monitor counterMemorie alocatăOptimalUsageMaximalUsage
\Process\Virtual octeți5784787695 octeți (5517 MB)60697889
\Process\Private octeți435689400 octeți (415 MB)457594
Aceste valori apoi sunt reprezentate în fișierul BTSNTSvc64.exe.config după cum urmează:
<xlangs>
      <Configuration>
                  <Dehydration>
                              <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
                              <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
                  </Dehydration>
      </Configuration>
</xlangs>
Pentru a determina care instanță gazdă se execută orchestrație, aveți posibilitatea să potriviți procesului, ID-ul de la \BizTalk:Messaging\ID proces și \Process\ID proces Performance Monitor contoare. Apoi, verifica valoarea medie afișate pentru corespunzătoare \Process\Virtual octeți și \Process\Private Bytes Performance Monitor contoare.

Notă Deshidratare mare poate provoca o scădere semnificativă de performanță atunci când baza acoperire de date BizTalkMsgBoxDb se execută pe SQL Server 2008.

BizTalk Server pachete de consolidare servicii și actualizări Cumulative

BizTalk Server pachete de consolidare servicii și actualizări cumulative include remedierile mai recente. Acestea includ pe cele care afectează probleme cunoscute System.OutOfMemoryException.

2281783 Listă tabel pachet Service Pack și actualizarea cumulativă pentru BizTalk Server 2006 R2

Microsoft BizTalk Server 2004 pachet Service Pack 2

HeapDeCommitFreeBlockThreshold

implicit, valoarea cheii de registry theHeapDeCommitFreeBlockThreshold este 0. O valoare 0 înseamnă că zona de lucru Manager decommits fiecare pagină de 4-kiloocteți (KB) care devine disponibilă. Decommit opera?iuni poate provoca fragmentarea de memorie virtuală. Dimensiunea setarea HeapDeCommitFreeBlockThreshold în heap manager va depinde de tipul de lucru care sistemul este de a face. O dimensiune de 0x00040000 este un început recomandată valoarea.

Luați în considerare următoarele informa?ii înainte de a modifica valoarea de
HeapDeCommitFreeBlockThreshold
registry cheie:
  • Această modificare se aplică numai la fragmentarea de memorie probleme.
  • Această schimbare este la nivel de sistem. Prin urmare, cele mai multe procese va utilizați mai multă memorie la pornire.
  • Doar ia în considerare această schimbare pentru sistemele care au BizTalk Server ca misiunea lor principală.
Pentru a reduce fragmentarea de memorie virtuală, puteți crește dimensiunea setarea HeapDeCommitFreeBlockThreshold în manager heap prin modificarea valorii de următoarea cheie de registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager


Nume pentru valoarea: HeapDeCommitFreeBlockThreshold
Tip valoare: REG_DWORD
Date valoare: 0x00040000 (aceasta este valoarea de pornire recomandată.)
Valoare implicită: nu prezintă
Pentru informații suplimentare despre cheie de registry HeapDeCommitFreeBlockThreshold, faceți clic pe următorul număr de articol pentru a vedea articolul în bază de cunoștințe Microsoft:
315407cheie de registry "HeapDecommitFreeBlockThreshold"

Opera?iunile de transformare

Atunci când efectuează BizTalk Server XML transforma opera?iuni pe mesaje destul de mare într-un port de primire, într-un port de trimitere, sau în XLANG, transformări XSL încărca întregul mesaj în memorie.

Pentru a rezolva această problemă, utilizați una dintre următoarele metode:
  • Reduce numărul de mesaje care BizTalk Server procese în același marcă de timp.
  • Reduce dimensiunea mesajului XML care este în curs de transformat.
Obiectul System.Policy.Security.Evidence este frecvent utilizat în transformări și pot consuma multă memorie. Atunci când o hartă conține o functoid scripting care utilizează inline C# (sau orice altă limbă inline), Adunarea este creat în memoria. Obiectul System.Policy.Security.Evidence utilizează obiectul Adunarea tonuri reale. Această situație creează un obiect înrădăcinate, care nu este ștearsă până când este repornit serviciul BizTalk.

Cele mai multe functoids de BizTalk implicite sunt implementate ca inline script-ul. Aceste elemente poate provoca System.Byte [] obiecte pentru a colecta în memorie. Pentru a reduce consumul de memorie, vă recomandăm ca tu a pune orice hartă care utilizează aceste functoids într-o adunare mici. Apoi, de referin?ă acestei adunări. Utilizați diagrama următoare pentru a determina care functoids utilizarea inline script-ul și functoids care nu utilizați script-ul inline.

În coloana a doua, "Da" înseamnă că acest functoid este implementat ca script-ul inline, și că aceasta va cauza System.Byte [] obiecte pentru a colecta în memorie. "Nu" înseamnă că acest functoid nu este implementată ca script-ul inline, și că nu va provoca System.Byte [] obiecte pentru a colecta în memorie.
Reduceți tabelulMăriți tabelul
FunctoidsScript-ul inline?
Toate șir Functoidsda
Toate Functoids matematiceda
Toate Functoids logice cu excep?ia IsNilda
Logică IsNil Functoidnu
Toate Functoids de dată/orăda
Toate Functoids de conversieda
Toate Functoids științificeda
Toate Functoids cumulativăda
Toate Functoids acoperire de datenu
Functoids avansateScript-ul inline?
Looping Functoidnu
Valoarea Mapping aplatizare Functoidnu
Afirma Functoidnu
Tabelul Extractor Functoidnu
Tabelul Looping Functoidnu
Functoid scripting cu Inline C#da
Functoid scripting cu Inline JScript.NETda
Functoid scripting cu Inline Visual Basic.NETda
Functoid scripting cu Inline XSLTnu
Functoid scripting cu Inline XSLT apel sosit șablonnu
Functoid scripting asteptare Adunarea externenu
Functoid valoarea zeronu
Valoarea Mapping Functoidnu
Masă copie Functoidnu
Repetare Functoidnu
Index Functoidnu
Numărul de înregistrare Functoidnu
BizTalk Server 2006 și versiunile ulterioare îmbunătăți semnificativ gestionare de memorie pentru documentele mari. Pentru a face acest lucru, BizTalk Server implementează un mesaj configurabil pragul de dimensiune pentru încărcare documente în memoria în timpul opera?iunilor de transformare. Pragul de dimensiune mesaj implicit este 1 MB. Pentru mai multe informații despre setarea TransformThreshold, următorul site Web Rețea Microsoft pentru dezvoltatori (MSDN):
http://msdn2.Microsoft.com/en-us/library/aa560481.aspx

Valorile de atribut mare și mare element

Când BizTalk Server execută o primire conducte sau o conductă de trimitere la un document XML, sarcina utilă este prelucrat în memorie dacă documentul conține unul sau mai multe dintre entită?ile men?ionate în continuare:
  • Valorile atributelor mare
  • Element mari valori
  • Mare atribut sau element etichete
Pentru a rezolva această problemă, limita dimensiunea acestor entită?i. Dacă acest metoda nu este posibil, asigurați-vă că vă instanță BizTalk gazdă nu proces multiple documente cum ar fi acestea în același marcă de timp.

Componente de conducte particularizate

Utilizați o componentă de conducte particularizate care încarcă întreaga Stream în memorie. Toate componentele care sunt incluse cu BizTalk Server, cu excep?ia transformări, suport de streaming. Aceste componente nu utilizați cât mai mult memorie în timpul de streaming. Cu toate acestea, conducte particularizate componente să nu accepte streaming.

Streaming sub stres grele

Trimite gazde a alerga afară de memorie atunci când operează sub stres grele. BizTalk Server trimite conducte și trimite adaptoare suport streaming. În streaming, fiecare componentă încarcă un mic fragment de stream în memorie. Deoarece fiecare mesaj include alte structuri acoperire de date, împreună cu un mesaj contextul care pot fi mari sau mici, acest comportament afectează comportamentul BizTalk Server sub stres grele.

Este afectat comportamentul BizTalk Server deoarece motorul încarcă un număr preconfigurate de mesaje. Numărul de mesajele care încarcă motorului se bazează pe valorile care apar în LowWaterMark și câmpul HighWaterMark din tabelul Adm_serviceClass. Tabelul de Adm_serviceClass este în baza acoperire de date pentru gestiune BizTalk. Aceste valori controlează numărul de mesaje care BizTalk Server procese sau trimite acela?i marcă de timp.

Valoarea HighWaterMark este numărul total de mesaje care motorul proceselor în același marcă de timp. valoare implicită este 200 mesaje pe CPU. Prin urmare, pe un 8-procesor server, gazdă trimite va încerca să procesului 1.600 mesaje (200 * 8) la acela?i marcă de timp. Dacă vă asumați că fiecare mesaj este 50 KB, mesajele egală cu 80 MB (1, 600 * 50 = 80, 000 KB).

Pentru a rezolva această problemă, modificați valoarea HighWaterMark și valoarea LowWaterMark în baza acoperire de date. Valorile pe care le utiliza?i depind de mărimea de mesaje.

Pentru mai multe informații despre cauzele comune de un out-of-memory condiție, consultați secțiunea "Memorie creștere în BizTalk mesaje" la situl Microsoft următoarele:
http://blogs.msdn.com/biztalkperformance
Pentru BizTalk Server 2006 și versiunile ulterioare, aveți posibilitatea să modificați implicită gazdă supraîncărcarea setările. Pentru mai multe informații despre cum se modifică implicit gazdă supraîncărcarea setări, vizitați următoarele site-ul Rețea Microsoft pentru dezvoltatori (MSDN):
http://msdn2.Microsoft.com/en-us/library/aa559628.aspx

Încercați să simplifice problema

Dacă ați identificat o irosire de memorie, încercați pentru a determina cauza eliminând componentele particularizat sau prin simplificarea o hartă. De asemenea, încercați să reproduceți problema utilizând o orchestrație simplă sau o soluție simplă. De obicei, vă trebuie crea separate primi hosts pentru a primi adaptoare. Ar trebui, de asemenea Creați gazde trimite separate pentru adaptoarele trimite. Când utilizați această metodă, fiecare adaptorul poate rula într-un proces separat. Prin urmare, în cazul în care procesul de BizTalk Server experiențele o condiție afară-de-memorie, va știu care componentele sunt implicate.

Pașii de depanare

Pentru a depana o condiție afară-de-memorie, utilizați depanare Instrumentul de diagnosticare pentru a monitoriza alocări de memorie în marcă de timp. Diagnostice depanare Instrumentul poate crea și analiza un memorie leak dump dosar (.dmp). Atunci când vă Depanarea pierderi de memorie, scopul este de a atașa Leaktrack.dll înainte de mare Stare memorie reproduce pentru a capta creștere memorie în marcă de timp. Leaktrack.dll este inclus cu instrumentul Diagnostice Debug.
  1. Instalați instrumentul de diagnosticare Debug.

    Fișierul este disponibil pentru descărcare de la centrul de descărcări Microsoft:

    Reduceți imagineaMăriți imaginea
    Download
    Descărcați acum pachetul Debug instrumentul de diagnosticare.

    Pentru mai multe informații despre modul de descărcare a fi?ierelor suport Microsoft, faceți clic pe următorul număr de articol pentru a vedea articolul în bază de cunoștințe Microsoft:
    119591 Cum se obțin fișierele suport Microsoft de la serviciile online
    Microsoft a scanat acest fișier pentru a detecta viruși. Microsoft a utilizat cele mai recente produse software de detectare a virusilor care erau disponibile la data la care fisierul a fost înregistrat. Fișierul este stocat pe fermă de servere securizate care ajută la prevenirea modificărilor neautorizate ale fișierului.
  2. Utilizați Performance Monitor pentru a colecta date despre sistem performanță. Aceste date pot furniza indicatorii importante despre eficiența mediul BizTalk Server. Scopul este de a capta procesul de performanță în marcă de timp. Prin urmare, permite Performance Monitor logare înainte de pierderi de memorie se produce.

Cum să utilizați Performance Monitor logare

Selectați datele de jurnal
Pentru a selecta datele pentru a vă conecta, utilizați metoda care este adecvat pentru sistemul de operare:
  • Pentru Ferestre a servi 2008 și Ferestre a servi 2008 R2
    1. În instrumente Administrative, deschideți Fiabilitatea și Performance Monitor.
    2. Faceți clic dreapta pe Performance Monitor, faceți clic pe Noi apoi faceți clic pe Set colectori acoperire de date.
    3. În nume caseta, tastați un nume descriptiv și apoi faceți clic pe Următorul.
    4. Notă director rădăcină, și apoi faceți clic pe Următorul.
    5. Faceți clic pe Începe acest colector acoperire de date setat acum, apoi faceți clic pe Terminare.
    6. Extinde Seturi de colector acoperire de date, extindeți Definite de utilizator și apoi selectați fișierul.
    7. Faceți clic dreapta pe Sistem Monitor jurnal, apoi faceți clic pe Proprietăți.
    8. Faceți clic pe Adăuga pe Contoare de performanță tab. Selectați următoarele obiecte, și apoi faceți clic pe Adăuga după ce selectați fiecare obiect:
      • .Net CLR excepții
      • .Net CLR memorie
      • BizTalk: mesagerie
      • BizTalk:TDDS
      • Memorie
      • Proces
      • Procesor
      • XLANG/s Orchestrations
      Dacă SQL Server este locale, de asemenea, adăuga următoarele obiecte:
      • SQLServer:Databases
      • SQLServer:General statistici
      • SQLServer:Memory Manager
    9. Faceți clic pe ok.
    10. Schimbarea Valoare de Interval de probă caseta de 5 secunde.

      Notă Valoarea din Interval de e?antion și marcă de timp pentru a începe să monitorizeze sunt subiectivă. Aceste valori depind atunci când scurgere de memorie este reprodus. Deoarece fișierul jurnal poate fi mare, specificați un interval în care aveți posibilitatea să obțineți informațiile pe care trebuie să aveți fără copleșitoare pe server.
    11. Faceți clic pe ok.
    Pentru a opri colectarea acoperire de date, faceți clic pe oprește-te pe Acțiune meniul.
  • Pentru Windows Server 2003 sau pentru Windows XP
    1. Extinde Jurnalele de performanță și Avertizări.
    2. Faceți clic dreapta pe Contor jurnalele, apoi Faceți clic pe Noile setări de jurnal. The Noile setări de jurnalapare casetă de dialog.
    3. În nume caseta, tastați o descriptiv nume de sign-in și apoi faceți clic pe ok.
    4. Notați locația fișierului jurnal. (Aveți posibilitatea, de asemenea, faceți clic pe Fișierele jurnal tab, și apoi faceți clic pe Configurați pentru a modificați amplasarea fișierului jurnal).
    5. Faceți clic pe Adăugare contoare.
    6. Selectați Toate de contoare și Toate instanțele.
    7. În obiect de performanță Listă tabel, selectați următoarele obiecte. Faceți clic pe Adăuga după ce selectați fiecare obiect.
      • .Net CLR excepții
      • .Net CLR memorie
      • BizTalk: mesagerie
      • BizTalk:TDDS
      • Memorie
      • Proces
      • Procesor
      • XLANG/s Orchestrations
      Dacă SQL Server este locale, de asemenea, adăuga următoarele obiecte:
      • SQLServer:Databases
      • SQLServer:General statistici
      • SQLServer:Memory Manager
    8. Faceți clic pe închide.
    9. Modificați valoarea în E?antionare date Interval la 5 secunde.

      Notă Valoarea acoperire de date interval de eșantionare și de marcă de timp pentru a începe să monitorizeze sunt subiectivă. Aceste valori depind atunci când scurgere de memorie este reprodus. Deoarece fișierul jurnal poate fi mare, specificați un interval în care aveți posibilitatea să obțineți informațiile pe care trebuie să aveți fără copleșitoare pe server.
    10. Faceți clic pe ok.
    Pentru a opri colectarea acoperire de date, faceți clic dreapta pe nume de sign-in Jurnalul de contor și apoi faceți clic pe oprește-te.
Obține fișierul imagine de memorie
Pentru a obține fișierul imagine de memorie, utilizați una dintre următoarele metode:
  • Metoda 1: automată
    Crearea de o regulă de memorie și ocupa de scurgere cu DebugDiag este abordarea recomandată pentru a captura o imagine de memorie. Regula memorie și manipula scurgere atașează automat Leaktrack.dll. Acest lucru este utilizat pentru a urmări alocări de memorie. Pentru a crea regula memorie și ocupa de scurgere, urmați acești pași:
    1. Începe depanare Instrumentul de diagnosticare 1.1.
    2. Selectați Memorie și mâner de scurgere, și apoi faceți clic pe Următorul.
    3. Selectați Btsntsvc.exe proces, și apoi faceți clic pe Următorul.
    4. În pagina Configurare scurgere de regulă, urmați acești pași:
      1. Faceți clic pentru a selecta Start urmărire imediat atunci când regula este activat de memorie casetă de selectare. În caz contrar, se poate specifica un marcă de timp de încălzire înainte de LeakTrack.dll este injectat în procesul de BTSNTSvc.exe.
      2. Faceți clic pe Configurați, apoi efectuați următoarele:
        • Confirmă că Auto-creați o regulă de accident este selectat. Selectând această opțiune, o imagine de memorie va fi creat automat dacă se dezactivare procesul de BTSNTSvc.exe.
        • Faceți clic pentru a selecta Genera o userdump atunci când ajunge la octeți virtual casetă de selectare, și să păstreze valoare implicită 1024.
        • Faceți clic pentru a selecta și fiecare suplimentare casetă de selectare, și să păstreze implicit de 200.
        Prin selectarea octeți virtual ajunge la opțiune, o imagine de memorie va fi creat automat atunci când octeți virtual utilizează 1024 MB. Dacă octeți virtual crește de 200 MO, automat va fi creat un alt memorie dump.
      3. Faceți clic pe Salvare și închidere.
      4. Faceți clic pe Următorul.
    5. În pagina Selectare Dump locația și nume de sign-in regulii, faceți clic pe Următorul.

      Notă Aveți posibilitatea să modificați calea fișierului dump în Userdump locație caseta de pe această pagină.
    6. Faceți clic pe Terminare pentru a activa regula acum.
    Notă Starea de regulă este acum de urmărire. Fiecare dată când este creat un memorie dump, valoarea va crește în coloana Userdump conta pe fila reguli. Memorie dump locație implicită este C:\Program Files\DebugDiag\Logs.
  • Metoda 2: Manual
    Puteți, de asemenea, manual atașați Leaktrack.dll și obține manual fișierul de imagine memorie. Acest lucru vă permite pentru a controla când se creează imagine memorie. Pentru aceasta, urmați acești pași:
    1. Începe depanare Instrumentul de diagnosticare 1.1.
    2. Faceți clic pe Procese fila.
    3. Faceți clic dreapta pe Btsntsvc.exe proces, și apoi faceți clic pe Monitor pentru scurgeri.
    4. În Instrumentul de diagnosticare a depanare dialog caseta, faceți clic pe da, apoi faceți clic pe ok.
    Creați o regulă de accident de a monitoriza același proces Btsntsvc.exe, în cazul în care procesul se dezactivare înainte de a crea imagine de memorie:
    1. Start Debug instrumentul de diagnosticare a 1.1.
    2. Selectați Accident, apoi faceți clic pe Următorul.
    3. Selectați Un proces specifice, apoi faceți clic pe Următorul.
    4. Selectați același proces Btsntsvc.exe, și apoi faceți clic pe Următorul.
    5. Pe Advanced Configuration (opțional) pagina, faceți clic pe Următorul.
    6. În Selectați Dump locație și nume de sign-in regulii (opțional) casetă de dialog, faceți clic pe Următorul.
    7. Selectați Activați regula acum, apoi faceți clic pe Terminare.
    Când procesul ajunge la 60% la 80% din RAM, faceți clic dreapta pe procesul de Btsntsvc.exe, și apoi faceți clic pe Creați complet Userdump. Dacă procesul de BizTalk se dezactivare înainte de a crea imagine de utilizator, regula Crash ar trebui să ia efect și de a crea imagine de memorie.
Stop Performance Monitor logare
Dacă vă sunt capturarea o memorie dump și Performance Monitor date, stop Performance Monitor logare aproximativ două minute după imagine de memorie este creat.
Analiza fișierului dump
Pentru a determina cauza o irosire de memorie, aveți posibilitatea să utilizați depanare Instrumentul de diagnosticare pentru a analiza dump dosar. Pentru aceasta, urmați acești pași:
  1. Faceți clic pe Analiză avansatefila.
  2. Faceți clic pe Adăugați fișierele acoperire de date, apoi localizați Fișier .dmp.
  3. Selectați Memorie presiune analizascript-ul, și apoi faceți clic pe Analiza de start.
implicit, un fișier de raport analiză (.mht) vor fi create în folderul C:\Program Files\DebugDiag\Reports atunci când analiza este terminat. Fișierul de raport, de asemenea, vor fi afișate în browser-ul dumneavoastră. Fișierul de raport conține rezultatele analizei. În plus, fișierul raport poate conține recomandări pentru modul de a rezolva o irosire memorie.

Dacă utilizați custom DLL-uri, puteți adăuga calea simbol fișierele .pdb particularizate pentru analiză. Pentru a face Acest lucru, urmați acești pași:
  1. Deschide instrumentul Diagnostice Debug.
  2. Pe Instrumente meniu, faceți clic pe Opțiuni și setări.
  3. În Simbol căutare calea pentru depanarecaseta, tastați calea simbol.
Dacă doriți ajutor analiza fișierului dump, contactați Microsoft Serviciile de asistență pentru clienți. Pentru o listă completă de serviciile de asistență pentru clienți telefon numere și informații referitoare la costul suportului, vizitați următorul Site Web Microsoft:
http://support.Microsoft.com/contactus/?ws=support
Înainte să contactați serviciile de asistență pentru clienți, comprimați fișierul dump, Jurnalul Performance Monitor, fișierul de raport analiză și actualizat jurnalele de evenimente (.evt dosar). Trebuie să trimiteți aceste fișiere pe un Server de BizTalk suport inginer.

Proprietă?i

ID articol: 918643 - Ultima examinare: 13 iunie 2012 - Revizie: 1.0
SE APLICĂ LA:
  • Microsoft BizTalk Server Branch 2010
  • Microsoft BizTalk Server Developer 2010
  • Microsoft BizTalk Server Enterprise 2010
  • Microsoft BizTalk Server Standard 2010
  • Microsoft BizTalk Server 2009 Branch
  • Microsoft BizTalk Server 2009 Developer
  • Microsoft BizTalk Server 2009 Enterprise
  • Microsoft BizTalk Server 2009 Standard
  • Microsoft BizTalk Server 2006 R2 Branch
  • Microsoft BizTalk Server 2006 R2 Developer Edition
  • Microsoft BizTalk Server 2006 R2 Enterprise Edition
  • Microsoft BizTalk Server 2006 R2 Standard Edition
  • Microsoft BizTalk Server 2006 Enterprise Edition
  • Microsoft BizTalk Server 2006 Developer Edition
  • Microsoft BizTalk Server 2006 Standard Edition
  • Microsoft BizTalk Server 2004 Enterprise Edition
  • Microsoft BizTalk Server 2004 Developer Edition
  • Microsoft BizTalk Server 2004 Partner Edition
  • Microsoft BizTalk Server 2004 Standard Edition
Cuvinte cheie: 
kbhowto kbmt KB918643 KbMtro
Traducere automată
IMPORTANT: Acest articol a fost tradus de software-ul de traducere automată Microsoft, si nu de un traducător. Microsoft vă oferă atât articole traduse de persoane, cât și articole traduse automat, astfel incat aveti access la toate articolele din Baza noastră de informatii în limba dvs. materna. Totuși, un articol tradus automat nu este întotdeauna perfect. Acesta poate conține greșeli de vocabular, sintaxă sau gramatică, la fel cum un vorbitor străin poate face greșeli vorbind limba dvs. materna. Compania Microsoft nu este responsabilă pentru nici o inexactitate, eroare sau daună cauzată de traducerea necorespunzătoare a conținutului sau de utilizarea traducerii necorespunzătoare de către clienții nostri. De asemenea, Microsoft actualizează frecvent software-ul de traducere automată.
Face?i clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 918643

Trimite?i feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com