Momentan sunteți offline, așteptați să vă reconectați la internet

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

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
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): 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): 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): 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): Următorul tabel rezumă această informaţie şi include limitele practice pentru virtual de octeţi şi privat octeţi.
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): Următorul tabel listează PAE şi 3 GB supportability pentru diferite versiuni de BizTalk Server.
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):

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):

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):

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: 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.
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.
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):

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: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):

Î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:

    DownloadDescă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: Î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.

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 918643 - Ultima examinare: 06/13/2012 08:44:00 - Revizie: 1.0

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

  • kbhowto kbmt KB918643 KbMtro
Feedback