Masuk

Select the product you need help with

Bagaimana memecahkan masalah kebocoran kehabisan memori atau keluar-memori pengecualian dalam proses BizTalk Server

ID Artikel: 918643 - Melihat produk di mana artikel ini berlaku.

Peringatan: artikel ini adalah terjemahan oleh mesin

Klik disini untuk menampilkan sumber Inggris dan terjemahan oleh mesin secara berdampingan

Perbesar semua | Perkecil semua

Kebocoran kehabisan memori adalah masalah umum. Anda mungkin harus mencoba beberapa langkah-langkah untuk menemukan tertentu menyebabkan kebocoran kehabisan memori atau pengecualian out kehabisan memori (OOM) di Microsoft BizTalk Server. Artikel ini membahas hal-hal yang penting untuk dipertimbangkan saat Anda mengevaluasi penggunaan kehabisan memori dan mungkin kehabisan memori yang berhubungan dengan isu-isu. Pertimbangan ini meliputi:

RAM fisik
Pesan besar pengolahan
Penggunaan / 3 GB beralih
Penggunaan komponen kustom
Versi Microsoft.NET Framework sistem berjalan
Jumlah prosesor

Kembali ke atas | Berikan Masukan

PENGENALAN

Artikel ini menjelaskan bagaimana memecahkan masalah kebocoran kehabisan memori atau out kehabisan memori pengecualian dalam proses BizTalk Server Microsoft BizTalk Server.

Kembali ke atas | Berikan Masukan

INFORMASI LEBIH LANJUT

Proses BizTalk Server mungkin mengalami kebocoran kehabisan memori ketika penggunaan kehabisan memori pada Microsoft Windows Task Manager mengkonsumsi lebih dari 50 persen dari RAM fisik. Kebocoran kehabisan memori dapat menyebabkan pengecualian keluar dari kehabisan memori ketika penggunaan kehabisan memori meningkat sampai proses kehabisan kehabisan memori sistem atau sampai proses berhenti berfungsi.

Ketika masalah ini terjadi, pesan peringatan yang menyerupai pesan berikut dicatat dalam log peristiwa:

Peristiwa Tipe: peringatan
Kategori peristiwa: (1)
Event ID: 5410
Keterangan: Sebuah kesalahan telah terjadi yang memerlukan layanan BizTalk untuk mengakhiri. Penyebab paling umum yang tak terduga dari kesalahan kehabisan memori dan ketidakmampuan untuk tautan langsung atau kehilangan konektivitas ke salah satu database BizTalk. Layanan akan shutdown dan auto-restart dalam 1 menit. Jika database bermasalah tetap tidak tersedia, Lingkaran Berkelanjutan ini akan mengulangi.
Pesan galat: pengecualian jenis System.OutOfMemoryException dilemparkan.
Kesalahan sumber:
BizTalk host Nama: BizTalkServerApplication
Nama layanan Windows: BTSSvc {DCC899FE-C62F-41BE-851A-8720B2EB9C14}

Jenis peristiwa: peringatan
Kategori peristiwa: (1)
Event ID: 5410
Keterangan: Terjadi kesalahan yang memerlukan layanan BizTalk untuk mengakhiri. Penyebab paling umum adalah sebagai berikut: 1) tak terduga keluar dari kesalahan kehabisan memori. ATAU 2) ketidakmampuan untuk tautan langsung atau kehilangan konektivitas ke salah satu database BizTalk. Layanan akan shutdown dan auto-restart dalam 1 menit. Jika database bermasalah tetap tidak tersedia, Lingkaran Berkelanjutan ini akan mengulangi.
Pesan galat: pengecualian tipe 'System.OutOfMemoryException' dilemparkan.
Kesalahan sumber: mscorlib
Nama host BizTalk: BizTalkServerApplication
Nama layanan Windows: BTSSvc$ BizTalkServerApplication

Pertimbangan penting

Fisik RAM dan pemakaian kehabisan memori

Karena mungkin perilaku yang diharapkan untuk proses menggunakan sekitar setengah RAM fisik, gunakan penggunaan kehabisan memori sebagai pedoman. Sebagai contoh, jika BizTalk Server telah 4 gigabytes (GB) RAM, dan proses BizTalk Server menggunakan sekitar 500 megabyte (MB) RAM, mungkin tidak ada kebocoran. Jika proses BizTalk Server menggunakan sekitar 1 GB RAM, mungkin ada kebocoran kehabisan memori atau kehabisan memori tinggi situasi. Pemakaian kehabisan memori mungkin disebabkan oleh berjalan lama disimpan prosedur atau orkestrasi. Pastikan bahwa Anda tahu berapa banyak kehabisan memori yang BizTalk host biasanya menggunakan untuk menentukan apakah sebuah kebocoran kehabisan memori atau kehabisan memori tinggi kondisi ini terjadi.

Pesan besar

Ketika BizTalk Server proses pesan besar, sistem tampaknya memiliki kebocoran kehabisan memori. Namun, pesan mungkin menggunakan sejumlah besar kehabisan memori. Untuk informasi selengkapnya tentang pesan besar, kunjungi Website Microsoft Developer Network (MSDN) berikut:

http://Blogs.msdn.com/biztalk_core_engine/Archive/2005/02/28/381700.aspx

(http://blogs.msdn.com/biztalk_core_engine/archive/2005/02/28/381700.aspx)

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

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

Juga, mempertimbangkan bahwa penggunaan kehabisan memori tinggi mungkin diharapkan jika BizTalk Server memproses pesan besar. Anda mungkin ingin meng-upgrade peranti penangkap keras Anda untuk memenuhi persyaratan kinerja BizTalk Server di lingkungan Anda.

Berapa lama waktu yang dibutuhkan untuk mereproduksi kebocoran kehabisan memori

Kebocoran kehabisan memori dapat terjadi segera atau mereka dapat mengumpulkan atas waktu. Skenario kedua umum.

Penggunaan 3 GB saklar pada komputer 32-bit

Biasanya, proses dapat mengakses 2 GB ruang alamat penyuratan virtual. tombol tekan 3 GB adalah pilihan untuk sistem yang memerlukan lebih banyak kehabisan memori addressable. Pilihan ini dapat meningkatkan penggunaan kehabisan memori untuk memproses pesan. Namun, switch 3 GB memungkinkan untuk hanya 1 GB kehabisan memori addressable untuk kernel modus operasi. Selain itu, switch ini dapat meningkatkan risiko kehabisan kehabisan memori kolam renang.

Untuk informasi lebih lanjut tentang 3 GB beralih, kunjungi website Microsoft Developer Network (MSDN) berikut:

http://MSDN.Microsoft.com/en-us/library/ms791558.aspx

(http://msdn.microsoft.com/en-us/library/ms791558.aspx)

Bila tombol tekan 3 GB diaktifkan pada versi 32-bit Windows, proses dapat mengakses 3 GB alamat penyuratan virtual ruang jika proses besar alamat penyuratan sadar. Proses besar alamat penyuratan sadar ketika executable memiliki bendera IMAGE_FILE_LARGE_ADDRESS_AWARE yang ditetapkan dalam gambar header. Karena proses BizTalk besar alamat penyuratan sadar, BizTalk akan mendapatkan keuntungan dari tombol tekan 3 GB.

Jika contoh host BizTalk 32-bit yang sedang berjalan di versi 64-bit Windows (AMD64), BizTalk proses manfaat dari kehabisan memori 4 GB ruang alamat penyuratan karena BizTalk besar alamat penyuratan sadar. Oleh karena itu, bergerak aplikasi kehabisan memori tinggi Anda ke server 64-bit mungkin menjadi solusi terbaik.

Proses BizTalk 64-bit versi 64-bit Windows (AMD64) memiliki 8 TB addressable kehabisan memori.

Anda juga harus mempertimbangkan byte virtual dan byte swasta yang digunakan oleh proses. Contoh host BizTalk (yang.NET Framework aplikasi) dapat menerima keluar dari kesalahan kehabisan memori sebelum nilai byte Virtual mencapai 2 GB. Hal ini dapat terjadi meskipun kehabisan memori maksimum yang dapat dialamatkan oleh proses pada versi 32-bit Windows (tanpa tombol tekan 3 GB ) adalah 2 GB. Untuk penjelasan mengapa hal ini dapat terjadi, kunjungi Website Microsoft Developer Network (MSDN) berikut:

http://MSDN.Microsoft.com/en-us/library/ms972959.aspx

(http://msdn.microsoft.com/en-us/library/ms972959.aspx)

http://Blogs.msdn.com/Tess/Archive/2005/11/25/496898.aspx

(http://blogs.msdn.com/tess/archive/2005/11/25/496898.aspx)

tombol tekan 3 GB juga meningkatkan byte swasta maksimum dari proses BizTalk dari 800 MB 1800 MB. Untuk informasi lebih lanjut tentang.NET Framework aplikasi kinerja dengan 3 GB switch diaktifkan, kunjungi website Microsoft Developer Network (MSDN) berikut:

http://msdn2.Microsoft.com/en-us/library/ms998583.aspx

(http://msdn2.microsoft.com/en-us/library/ms998583.aspx)

Daftar Tabel berikut ini merangkum informasi ini dan termasuk batas praktis untuk virtual byte dan byte swasta.

Perkecil tabel iniPerbesar tabel ini

Proses	Windows	kehabisan memori addressable (dengan alamat-sadar proses besar)	Batas praktis untuk virtual byte	Batas praktis untuk byte swasta
32-bit	32-bit	2 GB	1400 MB	800 MB
32-bit	32-bit dengan 3 GB	3 GB	2400 MB	1800 MB
32-bit	64-bit	4 GB	3400 MB	2800 MB
64-bit	64-bit	8 TB	tidak sahih	tidak sahih

Untuk informasi lebih lanjut tentang kehabisan memori addressable untuk 32-bit vs Windows 64-bit, kunjungi website Microsoft Developer Network (MSDN) berikut:

http://MSDN.Microsoft.com/en-us/library/aa366778.aspx

(http://msdn.microsoft.com/en-us/library/aa366778.aspx)

Daftar Tabel berikut mencantumkan supportability PAE dan 3 GB untuk versi yang berbeda dari BizTalk Server.

Perkecil tabel iniPerbesar tabel ini

Produk	PAE	3 GB
BizTalk Server 2004	Ya	Tidak
BizTalk Server 2006	Ya	Ya
BizTalk Server 2006 R2	Ya	Ya
BizTalk Server 2009	Ya	Ya

Jika Anda harus mengaktifkan tombol tekan 3 GB untuk memenuhi persyaratan kinerja komputer yang menjalankan BizTalk Server, Anda mungkin ingin pertimbangkan untuk menambahkan server ke grup BizTalk. Hal ini memungkinkan Anda untuk skala keluar contoh memori-intensif host.

BizTalk komponen yang berjalan di dalam proses Layanan Informasi Internet (IIS) mungkin juga memperoleh manfaat bila tombol tekan 3 GB diaktifkan.

tombol tekan 3 GB tidak didukung pada komputer yang menjalankan Windows SharePoint Services 2.0 atau versi yang lebih baru atau Server Portal SharePoint 2003 SP2 atau versi yang lebih baru. Untuk informasi lebih lanjut, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:

933560

(http://support.microsoft.com/kb/933560/ )

tombol tekan 3 GB Windows Server 2003 tidak didukung di Windows SharePoint Services 2.0 atau dalam versi Server Portal SharePoint 2003 paket layanan 2 atau di dalam versi

Penggunaan komponen kustom

Jika Anda menggunakan komponen kustom, seperti pipa atau layanan komponen, Anda harus tahu apa komponen-komponen ini. Anda juga harus tahu efek potensial komponen ini penggunaan kehabisan memori. A masalah kehabisan memori umum terjadi ketika sebuah komponen adalah mengubah sebuah kumpulan dokumen. The mengubah operasi adalah operasi intensif dari kehabisan memori. Ketika adalah sebuah kumpulan dokumen berubah, BizTalk Server melewati sungai pesan ke Microsoft.NET Kerangka XslTransform kelas dalam proses BizTalk.

Masalah umum lainnya terjadi ketika ada manipulasi string intensif. String intensif manipulasi dapat mengkonsumsi banyak kehabisan memori. Untuk informasi lebih lanjut tentang cara untuk meningkatkan kinerja, kunjungi website Microsoft Developer Network (MSDN) berikut:

http://msdn2.Microsoft.com/en-us/library/ms998547

(http://msdn2.microsoft.com/en-us/library/ms998547)

Versi.NET Framework

Microsoft.NET Framework 2.0 dan.NET Framework 1.1 memiliki kehabisan memori yang berbeda perilaku. Oleh karena itu, Anda dapat melihat hasil yang berbeda-beda antara mereka. Jika Anda menggunakan.NET Framework, mengkonfirmasi bahwa terbaru.NET Framework paket layanan 1 telah diinstal. paket layanan ini alamat penyuratan beberapa isu-isu dikenal kehabisan memori. Untuk informasi lebih lanjut, klik nomor artikel berikut:

945757

(http://support.microsoft.com/default.aspx?scid=kb;EN-US;945757)

Masalah yang diperbaiki dalam.NET Framework 2.0 paket layanan 1
867460

(http://support.microsoft.com/kb/867460/ )

Daftar bug yang diperbaiki dalam.NET Framework 1.1 Service Pack 1

Jumlah prosesor

Common language runtime (CLR) memiliki berikut sampah kolektor (GCs):

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

Jika komputer yang menjalankan BizTalk Server adalah sebuah sistem multiprosesor,.NET Framework menggunakan versi Server mesin eksekusi. Ini adalah aktivitas default. Server garbage collector dirancang untuk maksimal throughput. Selain itu, Server garbage collector skala untuk memberikan kinerja yang sangat tinggi. Ini garbage collector mengalokasikan kehabisan memori dan kemudian kemudian membebaskan kehabisan memori untuk memberikan kinerja tinggi pada sistem. Oleh karena itu, sebuah komputer yang menjalankan BizTalk Server bersama dengan beberapa.NET Framework komponen tampaknya memiliki kebocoran kehabisan memori. Namun, dalam skenario ini, penggunaan kehabisan memori tinggi adalah perilaku yang diharapkan. Jika komputer kehabisan kehabisan memori sistem, atau jika proses berhenti bekerja karena kehabisan memori tidak cukup addressable, kondisi kebocoran kehabisan memori yang mungkin ada.

Jika komputer yang menjalankan BizTalk Server adalah sistem prosesor tunggal.NET Framework menggunakan Workstation versi mesin eksekusi. Ini adalah default perilaku. Workstation garbage collector alokasi algoritma ini dirancang untuk skala atau untuk maksimal throughput. Kolektor sampah ini menggunakan bersamaan garbage collector metode. Metode ini dirancang untuk aplikasi yang memiliki antarmuka pengguna yang kompleks. Aplikasi tersebut mungkin memerlukan pengumpulan sampah lebih agresif.

Penting Bagian ini, metode, atau tugas yang memuat langkah-langkah yang memberitahu Anda bagaimana untuk mengubah registri. Namun, masalah serius mungkin muncul saat Anda salah memodifikasi registri. Oleh karena itu, pastikan Anda mengikuti langkah-langkah ini dengan hati-hati. Untuk perlindungan tambahan, buat cadangan registri sebelum Anda memodifikasinya. Kemudian, Anda dapat memulihkan registri apabila ada masalah. Untuk informasi lebih lanjut tentang cara membuat cadangan dan memulihkan registri, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:

322756

(http://support.microsoft.com/kb/322756/ )

Cara membuat cadangan dan memulihkan registri pada Windows

Kadang-kadang, itu mungkin cocok untuk menjalankan versi Workstation mesin eksekusi pada sistem multiprosesor. Anda dapat menggunakan bukti kunci registri berikut untuk beralih ke Workstation versi mesin eksekusi.

BizTalk 2006 dan versi

Membuat bukti kunci registri CRL Hosting String berikut dengan nilai-nilai yang sesuai:

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

Nama: rasa
Data: wks

BizTalk 2004

Membuat bukti kunci registri CRL Hosting String berikut dengan nilai-nilai yang sesuai:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc {pengenal unik global} \CLR Host

Nama: rasa
Data: wks

Untuk informasi lebih lanjut, kunjungi Website Microsoft Developer Network (MSDN) berikut:

http://msdn2.Microsoft.com/en-us/library/ms973838

(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

(http://blogs.msdn.com/tess/archive/2008/04/17/how-does-the-gc-work-and-what-are-the-sizes-of-the-different-generations.aspx)

Penyebab umum dan resolusi

Penggunaan kehabisan memori proses dan penggunaan kehabisan memori fisik throttling ambang batas

Penggunaan kehabisan memori proses dan penggunaan kehabisan memori fisik throttling ambang batas dapat diubah pada BizTalk Server 2006 dan di versi yang lebih baru.

secara asali, Penggunaan kehabisan memori proses pelambatan ambang diatur ke 25. Jika nilai ini melampaui dan penggunaan kehabisan memori proses BizTalk lebih dari 300 MB, kondisi pelambatan dapat terjadi. Pada server 32-bit, Anda dapat meningkatkan nilai penggunaan kehabisan memori proses untuk 50. Pada server 64-bit, Anda dapat meningkatkan nilai ini untuk 100. Hal ini memungkinkan untuk lebih banyak kehabisan memori konsumsi oleh proses BizTalk sebelum throttling terjadi.
The Penggunaan kehabisan memori fisik pelambatan ambang memiliki nilai asali 0. Ambang batas ini ukuran kehabisan memori sistem total. Oleh karena itu, jika nilai selain 0 dikonfigurasi, kondisi pelambatan dapat terjadi jika non-BizTalk proses yang menggunakan kehabisan memori tinggi.

Untuk selengkapnya tentang batas pelambatan, kunjungi website Microsoft Developer Network (MSDN) berikut:

http://MSDN.Microsoft.com/en-us/library/aa559628.aspx

(http://msdn.microsoft.com/en-us/library/aa559628.aspx)

Dehidrasi throttling ambang batas

Dehidrasi kehabisan memori default ambang batas dapat menyebabkan dehidrasi terlalu banyak ketika orchestrations dijalankan pada sejumlah 64-bit. Untuk informasi lebih lanjut tentang masalah ini, lihat topik Dehidrasi Default properti pada website Microsoft Developer Network (MSDN) berikut:

http://MSDN.Microsoft.com/en-us/library/aa560586.aspx

(http://msdn.microsoft.com/en-us/library/aa560586.aspx)

Catatan 64-bit host didukung dalam BizTalk Server 2006 dan versi.

Pada peranti penangkap keras yang setara dalam contoh host 32-bit, dehidrasi diamati nominal ketika orchestrations sama dijalankan dengan menggunakan kehabisan memori default dehidrasi throttling ambang batas.

Karena 64-bit arsitektur menyediakan ruang alamat penyuratan kehabisan memori diperluas (16 TB bukannya 4 GB), 64-bit host contoh yang dialokasikan secara signifikan lebih banyak kehabisan memori dari 32-bit host contoh. Ini dapat menyebabkan kehabisan memori standar batas pelambatan untuk dilampaui.

Untuk mengatasi perilaku ini, Ubah nilai-nilai VirtualMemoryThrottlingCriteria dan PrivateMemoryThrottlingCriteria pada berkas BTSNTSvc64.exe.config. Menggunakan Process\Virtual byte dan penghitung Monitor kinerja byte Process\Private untuk menentukan jumlah kehabisan memori yang sedang dialokasikan oleh contoh orkestrasi terbesar.

Mengatur nilai OptimalUsage kedua properti berdasarkan berikut:
VirtualMemoryThrottlingCriteria: \Process\Virtual Bytes nilai + 10 %
PrivateMemoryThrottlingCriteria: \Process\Private Bytes nilai + 10 %
Menetapkan MaximalUsage untuk kedua properti untuk OptimalUsage nilai + 30 %

Sebagai contoh, apakah \Process\Virtual byte kinerja Monitor counter nilai misalnya orkestrasi 5,784,787,695 byte (5,517 MB), menetapkan nilai OptimalUsage untuk VirtualMemoryThrottlingCriteria untuk 6,069 MB (5,784,787,695 * 1.10 = 6,363,266,464.5 byte). Mengatur nilai MaximalUsage untuk VirtualMemoryThrottlingCriteria untuk 7,889 MB (6,363,266,464.5 * 1,30 = 8,272,246,403.85 byte).

Apakah \Process\Private nilai counter Monitor kinerja byte 435689400 bytes (415 MB), menetapkan nilai OptimalUsage untuk PrivateMemoryThrottlingCriteria untuk 457 MB (435689400 * 1.10 = 479258340 byte). Mengatur nilai MaximalUsage untuk PrivateMemoryThrottlingCriteria untuk 594 MB (479258340 * 1,30 = 623035842).

Untuk contoh ini, nilai berikut akan ditentukan di file BTSNTSvc64.exe.config untuk mengurangi throttling.

Perkecil tabel iniPerbesar tabel ini

Performa counter Monitor	kehabisan memori dialokasikan	OptimalUsage	MaximalUsage
\Process\Virtual byte	5784787695 byte (5517 MB)	6069	7889
\Process\Private byte	435689400 byte (415 MB)	457	594

Nilai-nilai ini akan kemudian diwakili dalam BTSNTSvc64.exe.config file sebagai berikut:

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

Menentukan contoh host yang menjalankan orkestrasi, Anda dapat menyesuaikan ID proses dari \BizTalk:Messaging\ID proses dan penghitung Monitor kinerja proses \Process\ID. Kemudian, periksa nilai rata-rata yang ditampilkan untuk sesuai \Process\Virtual byte dan penghitung Monitor kinerja byte \Process\Private.

Catatan Dehidrasi tinggi dapat menyebabkan penurunan yang signifikan dalam kinerja ketika BizTalkMsgBoxDb database berjalan pada SQL Server 2008.

BizTalk Server paket layanan dan pembaruan kumulatif

BizTalk Server paket layanan dan pembaruan kumulatif termasuk perbaikan terbaru. Ini termasuk orang-orang yang mempengaruhi masalah System.OutOfMemoryException yang diketahui.

2281783

(http://support.microsoft.com/default.aspx?scid=kb;en-US;2281783)

Daftar paket layanan dan pembaruan kumulatif untuk BizTalk Server 2006 R2

Microsoft BizTalk Server 2004 paket layanan 2

(http://www.microsoft.com/downloads/en/details.aspx?FamilyId=D20B4510-E5A6-4D7B-87A1-4BD52BDD57B8&displaylang=en)

HeapDeCommitFreeBlockThreshold

secara asali, nilai bukti kunci registri theHeapDeCommitFreeBlockThreshold adalah 0. Nilai 0 berarti bahwa tumpukan manajer decommits setiap 4-Kilobita (KB) halaman yang tersedia. Decommit operasi dapat menyebabkan fragmentasi kehabisan memori virtual. Ukuran HeapDeCommitFreeBlockThreshold pengaturan di tumpukan manager akan tergantung pada jenis pekerjaan yang sistem melakukan. Ukuran 0x00040000 adalah mulai direkomendasikan nilai.

Mempertimbangkan informasi berikut sebelum Anda mengubah nilai dari

HeapDeCommitFreeBlockThreshold

registri kunci:

Perubahan ini hanya berlaku untuk fragmentasi kehabisan memori masalah.
Perubahan ini sistem-lebar. Oleh karena itu, sebagian besar proses akan menggunakan lebih banyak kehabisan memori pada startup.
Hanya mempertimbangkan perubahan ini untuk sistem yang memiliki BizTalk Server sebagai misi utama mereka.

Untuk membantu mengurangi fragmentasi kehabisan memori virtual, Anda dapat meningkatkan ukuran HeapDeCommitFreeBlockThreshold pengaturan di tumpukan manager dengan mengubah nilai bukti kunci registri berikut:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manajer

Nama nilai: HeapDeCommitFreeBlockThreshold
Jenis nilai: REG_DWORD
Data nilai: 0x00040000 (ini adalah nilai awal dianjurkan.)
Nilai default: tidak ada

Untuk informasi lebih lanjut tentang bukti kunci registri HeapDeCommitFreeBlockThreshold, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:

315407

(http://support.microsoft.com/kb/315407/ )

bukti kunci registri "HeapDecommitFreeBlockThreshold"

Mengubah operasi

Ketika melakukan BizTalk Server XML mengubah operasi pada pesan yang cukup besar di pelabuhan menerima, di pelabuhan kirim, atau di XLANG, transformasi XSL memuat seluruh pesan dalam kehabisan memori.

Untuk mengatasi masalah ini, gunakan salah satu metode berikut:

Mengurangi jumlah pesan yang BizTalk Server proses pada saat yang sama.
Mengurangi ukuran pesan XML yang sedang berubah.

Objek System.Policy.Security.Evidence sering digunakan dalam transformasi dan dapat mengkonsumsi banyak kehabisan memori. Ketika peta berisi functoid skrip yang menggunakan inline C# (atau bahasa inline lainnya), Majelis yang dibuat dalam kehabisan memori. System.Policy.Security.Evidence obyek menggunakan objek Majelis panggilan yang sebenarnya. Situasi ini menciptakan sebuah objek berakar yang tidak dihapus sampai layanan BizTalk di-restart.

Sebagian besar default BizTalk functoids diimplementasikan sebagai inline skrip. Item ini dapat menyebabkan System.Byte [] objek untuk mengumpulkan dalam kehabisan memori. Untuk meminimalkan pemakaian kehabisan memori, kami menyarankan Anda membuat setiap peta yang menggunakan functoids ini ke Majelis kecil. Kemudian, referensi Majelis itu. Menggunakan Daftar Tabel berikut untuk menentukan functoids yang menggunakan inline skrip dan functoids yang tidak menggunakan inline skrip.

Di kolom kedua, "Ya" berarti bahwa functoid ini diimplementasikan sebagai inline script, dan bahwa hal itu akan menyebabkan System.Byte [] objek untuk mengumpulkan dalam kehabisan memori. "Tidak" berarti bahwa functoid ini tidak diimplementasikan sebagai inline script, dan tidak akan menyebabkan System.Byte [] objek untuk mengumpulkan dalam kehabisan memori.

Perkecil tabel iniPerbesar tabel ini

Functoids	Inline skrip?
Semua String Functoids	Ya
Semua matematika Functoids	Ya
Semua Functoids logis kecuali IsNil	Ya
Logis IsNil Functoid	Tidak
Semua tanggal/waktu Functoids	Ya
Semua konversi Functoids	Ya
Semua ilmiah Functoids	Ya
Semua kumulatif Functoids	Ya
Semua Database Functoids	Tidak

Maju Functoids	Inline skrip?
Perulangan Functoid	Tidak
Nilai pemetaan meratakan Functoid	Tidak
Menegaskan Functoid	Tidak
Daftar Tabel Extractor Functoid	Tidak
Daftar Tabel perulangan Functoid	Tidak
Scripting Functoid dengan Inline C#	Ya
Scripting Functoid dengan Inline JScript.NET	Ya
Scripting Functoid dengan Inline Visual Basic.NET	Ya
Scripting Functoid dengan Inline XSLT	Tidak
Skrip Functoid dengan panggilan Inline XSLT Template	Tidak
Scripting Functoid memanggil eksternal Majelis	Tidak
Nol nilai Functoid	Tidak
Nilai pemetaan Functoid	Tidak
Massa kopi karbon Functoid	Tidak
Iterasi Functoid	Tidak
Indeks Functoid	Tidak
Catatan Count Functoid	Tidak

BizTalk Server 2006 dan versi secara signifikan meningkatkan manajemen kehabisan memori untuk dokumen-dokumen yang besar. Untuk melakukan ini, BizTalk Server mengimplementasikan pesan dikonfigurasi batas ukuran untuk memuat kumpulan dokumen ke dalam kehabisan memori selama mengubah operasi. Batas ukuran pesan default adalah 1 MB. Untuk informasi lebih lanjut tentang pengaturan TransformThreshold, kunjungi situs Microsoft Developer Network (MSDN) berikut:

http://msdn2.Microsoft.com/en-us/library/aa560481.aspx

(http://msdn2.microsoft.com/en-us/library/aa560481.aspx)

Nilai atribut yang besar dan nilai-nilai besar elemen

Ketika BizTalk Server mengeksekusi menerima pipa atau kirim pipa pada kumpulan dokumen XML, payload diproses di kehabisan memori jika kumpulan dokumen berisi satu atau lebih entitas berikut:

Nilai atribut besar
Nilai-nilai besar elemen
Besar elemen atau atribut tag

Untuk mengatasi masalah ini, membatasi ukuran entitas ini. Jika ini metode ini tidak mungkin, pastikan bahwa Anda contoh BizTalk HOST tidak proses beberapa kumpulan dokumen seperti ini pada saat yang sama.

Komponen kustom pipa

Anda menggunakan komponen kustom pipa yang memuat seluruh Streaming ke kehabisan memori. Semua komponen yang disertakan dengan BizTalk Server, kecuali Mentransformasi, mendukung streaming. Komponen ini tidak menggunakan sebanyak kehabisan memori selama streaming. Namun, komponen kustom pipa mungkin tidak mendukung streaming.

Streaming di bawah tekanan berat

Kirim host kehabisan kehabisan memori ketika mereka beroperasi di bawah tekanan berat. BizTalk Server mengirim pipa dan mengirim adapter dukungan streaming. Dalam streaming, masing-masing komponen banyak fragmen kecil dari sungai ke dalam kehabisan memori. Karena setiap pesan termasuk struktur data lain, bersama-sama dengan pesan konteks yang dapat besar atau kecil, perilaku ini mempengaruhi perilaku BizTalk Server di bawah tekanan berat.

Perilaku BizTalk Server dipengaruhi karena mesin memuat jumlah pesan yang telah dikonfigurasikan. Jumlah pesan yang mesin beban didasarkan pada nilai-nilai yang muncul di LowWaterMark lapangan dan bidang HighWaterMark Daftar Tabel Adm_serviceClass. Daftar Tabel Adm_serviceClass adalah dalam BizTalk Manajemen Database. Nilai-nilai ini mengendalikan jumlah pesan yang BizTalk Server proses atau mengirim pada waktu yang sama.

Nilai HighWaterMark adalah jumlah pesan yang mesin proses pada saat yang sama. nilai asali adalah 200 pesan per CPU. Oleh karena itu, pada 8-prosesor server, host mengirim akan mencoba untuk memproses 1.600 pesan (200 * 8) pada saat yang sama. Jika Anda menganggap bahwa setiap pesan adalah 50 KB, pesan sama 80 MB (1, 600 * 50 = 80, 000 KB).

Untuk mengatasi masalah ini, Anda dapat mengubah nilai HighWaterMark dan nilai LowWaterMark dalam database. Nilai-nilai yang Anda gunakan bergantung pada ukuran pesan.

Untuk informasi lebih lanjut tentang penyebab umum out kehabisan memori kondisi, lihat bagian "Memori pertumbuhan di BizTalk pesan" pada website Microsoft berikut:

http://Blogs.msdn.com/biztalkperformance

(http://blogs.msdn.com/biztalkperformance)

Untuk BizTalk Server 2006 dan versi yang lebih baru, Anda dapat mengubah default host pelambatan pengaturan. Untuk informasi lebih lanjut tentang cara mengubah default host pelambatan pengaturan, kunjungi website Microsoft Developer Network (MSDN) berikut:

http://msdn2.Microsoft.com/en-us/library/aa559628.aspx

(http://msdn2.microsoft.com/en-us/library/aa559628.aspx)

Mencoba untuk menyederhanakan masalah

Jika Anda telah mengidentifikasi kebocoran kehabisan memori, cobalah untuk menentukan penyebab dengan menghapus komponen kustom atau menyederhanakan peta. Juga, cobalah untuk mereproduksi masalah dengan menggunakan orkestrasi sederhana atau solusi sederhana. Biasanya, Anda harus membuat terpisah menerima host untuk menerima adapter. Anda juga harus Buat host terpisah Kirim untuk mengirim adapter. Bila Anda menggunakan metode ini, setiap adaptor dapat menjalankan dalam proses terpisah. Oleh karena itu, jika proses BizTalk Server Anda pengalaman kondisi out kehabisan memori, Anda akan tahu komponen yang terlibat.

Langkah pemecahan masalah

Untuk mengatasi kondisi out kehabisan memori, gunakan Debug Alat diagnostik untuk memantau alokasi kehabisan memori Dari Waktu ke waktu. Diagnostik Debug alat dapat membuat dan menganalisis kebocoran berkas dump kehabisan memori (.dmp). Ketika Anda memecahkan masalah kebocoran kehabisan memori, tujuannya adalah untuk melampirkan Leaktrack.dll sebelum tinggi kehabisan memori kondisi mereproduksi untuk menangkap kehabisan memori pertumbuhan Dari Waktu ke waktu. Leaktrack.dll disertakan dengan alat Debug diagnostik.

Instal alat diagnostik Debug.

Berkas berikut ini tersedia untuk di-download dari Pusat Download Microsoft:

Perkecil gambar iniPerbesar gambar ini
Download paket Debug alat diagnostik sekarang.
(http://www.microsoft.com/en-us/download/details.aspx?id=26798)

Untuk informasi lebih lanjut tentang cara mengunduh berkas dukungan Microsoft, klik nomor artikel berikut ini untuk melihat artikel tersebut di dalam Pangkalan Pengetahuan Microsoft:
119591
(http://support.microsoft.com/kb/119591/ )
Cara mendapatkan berkas Dukungan Microsoft dari layanan online
Microsoft memindai berkas untuk virus. Microsoft menggunakan peranti penangkap lunak pendeteksi virus terbaru yang tersedia pada tanggal ketika berkas dikirimkan. Berkas tersebut disimpan pada server aman yang membantu mencegah pengubahan yang tidak sah terhadap berkas.
Menggunakan Monitor kinerja untuk mengumpulkan data tentang sistem kinerja. Data ini dapat memberikan indikator penting tentang efisiensi lingkungan BizTalk Server Anda. Tujuannya adalah untuk menangkap proses kinerja Dari Waktu ke waktu. Oleh karena itu, mengaktifkan logging Monitor kinerja sebelum kebocoran kehabisan memori terjadi.

Cara menggunakan Monitor kinerja logging

Pilih data login

Untuk memilih data login, gunakan metode yang sesuai sistem operasi Anda:

Untuk Windows Server 2008 dan Windows Server 2008 R2
1. Di Administrative Tools, buka Keandalan dan kinerja Monitor.
2. Klik kanan-atas Monitor kinerja, klik Baru kemudian klik Kumpulan data kolektor.
3. Dalam Nama kotak, ketik nama deskriptif, dan kemudian klik Berikutnya.
4. Perhatikan direktori akar, dan kemudian klik Berikutnya.
5. Klik Mulai kolektor data ini mengatur sekarang, lalu klik Menyelesaikan.
6. Memperluas Data kolektor set, memperluas Ditetapkan pengguna dan kemudian pilih file.
7. Klik kanan-atas Log Monitor Sistem, lalu klik Properti.
8. Klik Tambahkan pada Penghitung kinerja tab. Pilih objek berikut, dan kemudian klik Tambahkan Setelah Anda memilih setiap objek:
  - .NET CLR pengecualian
  - .NET CLR kehabisan memori
  - BizTalk: pesan
  - BizTalk:TDDS
  - kehabisan memori
  - Proses
  - Prosesor
  - Orchestrations XLANG/s
  Apakah SQL Server lokal, juga menambahkan objek berikut:
  - SQLServer:Databases
  - Statistik SQLServer:General
  - SQLServer:Memory Manager
9. Klik Oke.
10. Perubahan Sampel Interval nilai kotak 5 detik.
  
  Catatan Nilai sampel Interval dan waktu untuk mulai memantau adalah subjektif. Nilai-nilai ini tergantung pada ketika kebocoran kehabisan memori direproduksi. Karena berkas log dapat besar, menentukan interval di mana Anda dapat memperoleh informasi yang Anda harus tanpa berlebihan server.
11. Klik Oke.
Untuk berhenti mengumpulkan data, klik Stop pada Tindakan menu.

Untuk Windows Server 2003 atau Windows XP
1. Memperluas Kinerja log dan Alert.
2. Klik kanan-atas Counter log, dan kemudian Klik Baru Log pengaturan. The Baru Log pengaturankotak dialog akan muncul.
3. Dalam Nama Ketik jenis deskriptif nama, dan kemudian klik Oke.
4. Perhatikan lokasi file log. (Anda juga dapat mengklik File log tab, dan kemudian klik Mengkonfigurasi untuk mengubah lokasi file log.)
5. Klik Menambahkan Counter.
6. Pilih Semua Counter dan Semua contoh.
7. Dalam Kinerja objek Daftar, pilih objek berikut. Klik Tambahkan Setelah Anda memilih setiap objek.
  - .NET CLR pengecualian
  - .NET CLR kehabisan memori
  - BizTalk: pesan
  - BizTalk:TDDS
  - kehabisan memori
  - Proses
  - Prosesor
  - Orchestrations XLANG/s
  Apakah SQL Server lokal, juga menambahkan objek berikut:
  - SQLServer:Databases
  - Statistik SQLServer:General
  - SQLServer:Memory Manager
8. Klik Tutup.
9. Mengubah nilai dalam Data Sampling Interval untuk 5 detik.
  
  Catatan Nilai Data Sampling Interval dan waktu untuk mulai memantau adalah subjektif. Nilai-nilai ini tergantung pada ketika kebocoran kehabisan memori direproduksi. Karena berkas log dapat besar, menentukan interval di mana Anda dapat memperoleh informasi yang Anda harus tanpa berlebihan server.
10. Klik Oke.
Untuk berhenti mengumpulkan data, klik kanan-atas nama counter log dan kemudian klik Stop.

Mendapatkan berkas dump

Untuk mendapatkan berkas dump, gunakan salah satu metode berikut:

Metode 1: otomatis
Menciptakan kehabisan memori dan menangani kebocoran aturan dengan DebugDiag adalah pendekatan yang disarankan untuk menangkap dump kehabisan memori. kehabisan memori dan menangani kebocoran aturan secara otomatis melampirkan Leaktrack.dll. Ini digunakan untuk melacak alokasi kehabisan memori. Untuk membuat aturan kehabisan memori dan menangani kebocoran, ikuti langkah berikut:
1. Memulai Debug Alat diagnostik 1.1.
2. Pilih kehabisan memori dan menangani kebocoran, dan kemudian klik Berikutnya.
3. Pilih Btsntsvc.exe proses, dan kemudian klik Berikutnya.
4. Pada halaman mengkonfigurasi kebocoran aturan, ikuti langkah berikut:
  1. Klik untuk memilih Mulai kehabisan memori pelacakan segera ketika aturan diaktifkan kotak centang. Jika tidak, Anda dapat menentukan waktu pemanasan sebelum LeakTrack.dll disuntikkan dalam proses BTSNTSvc.exe.
  2. Klik Mengkonfigurasi, dan kemudian melakukan hal berikut:
    - Mengkonfirmasi bahwa Auto-membuat aturan kecelakaan dipilih. Dengan memilih opsi ini, dump kehabisan memori akan dibuat secara otomatis jika proses BTSNTSvc.exe berhenti.
    - Klik untuk memilih Menghasilkan userdump ketika virtual byte mencapai centang kotak, dan menjaga nilai asali 1024.
    - Klik untuk memilih dan masing-masing tambahan Periksa kotak, dan menjaga default 200.
    Dengan memilih byte virtual mencapai pilihan, dump kehabisan memori akan secara otomatis dibuat ketika virtual byte menggunakan 1024 MB. Jika virtual byte meningkat oleh 200 MB, lain kehabisan memori dump secara otomatis dibuat.
  3. Klik Simpan & tutup.
  4. Klik berikutnya.
5. Pada halaman Pilih Dump lokasi dan nama aturan, klik Berikutnya.
  
  Catatan Anda juga dapat mengubah lintasan berkas dump di Lokasi Userdump kotak pada Halaman ini.
6. Klik Menyelesaikan untuk membuat aturan aktif sekarang.
Catatan Aturan status sekarang Pelacakan. Setiap kali sebuah dump kehabisan memori dibuat, nilai akan meningkat dalam kolom Userdump Count pada tab Aturan. Lokasi dump kehabisan memori default adalah c: Files\DebugDiag\Logs.
Metode 2: Manual
Anda dapat juga secara manual melampirkan Leaktrack.dll dan manual mendapatkan berkas dump kehabisan memori. Hal ini memungkinkan Anda untuk mengontrol kehabisan memori dump yang dibuat. Untuk melakukannya, ikuti langkah berikut:
1. Memulai Debug Alat diagnostik 1.1.
2. Klik Proses tab.
3. Klik kanan-atas Btsntsvc.exe proses, dan kemudian klik Monitor kebocoran.
4. Dalam Debug alat diagnostik dialog kotak, klik Ya, lalu klik Oke.
Membuat aturan kecelakaan untuk memantau proses Btsntsvc.exe yang sama dalam kasus proses berhenti sebelum Anda dapat membuat dump memori:
1. Memulai Debug alat diagnostik 1.1.
2. Pilih Kecelakaan, lalu klik Berikutnya.
3. Pilih Proses tertentu, lalu klik Berikutnya.
4. Pilih proses Btsntsvc.exe yang sama, dan kemudian klik Berikutnya.
5. Pada Konfigurasi lanjut (opsional) Halaman, klik Berikutnya.
6. Dalam Pilih Dump lokasi dan nama aturan (opsional) kotak dialog, klik Berikutnya.
7. Pilih Mengaktifkan aturan sekarang, lalu klik selesai.
Ketika proses mencapai 60 persen untuk 80 persen dari RAM, klik-kanan proses Btsntsvc.exe, dan kemudian klik Membuat penuh Userdump. Jika proses BizTalk berhenti sebelum Anda dapat membuat pengguna dump, aturan kecelakaan harus berlaku dan menciptakan kehabisan memori dump.

Berhenti Monitor kinerja logging

Jika Anda menangkap kehabisan memori dump dan Monitor kinerja data, berhenti Monitor kinerja logging sekitar dua menit setelah kehabisan memori dump dibuat.

Menganalisis berkas dump

Untuk membantu menentukan penyebab kebocoran kehabisan memori, Anda dapat menggunakan Debug Alat diagnostik untuk menganalisis berkas dump. Untuk melakukannya, ikuti langkah berikut:

Klik Analisis lanjutantab.
Klik Menambahkan file Data, dan kemudian cari .dmp file.
Pilih kehabisan memori tekanan analisisscript, dan kemudian klik Mulai analisis.

secara asali, berkas laporan analisis (.mht) akan dibuat di folder C:\Program Files\DebugDiag\Reports setelah analisis selesai. File laporan juga akan ditampilkan dalam browser Anda. File laporan berisi hasil analisis. Selain itu, file laporan mungkin berisi rekomendasi untuk bagaimana menyelesaikan kebocoran kehabisan memori.

Jika Anda menggunakan custom Dll, Anda dapat menambahkan garis jatuh berseri simbol berkas .pdb kustom untuk analisis. Untuk melakukan ini, ikuti langkah berikut:

Buka alat Debug diagnostik.
Pada Alat menu, klik Pilihan dan pengaturan.
Dalam Simbol lintasan pencarian untuk Debuggingkotak, ketik lintasan simbol.

Jika Anda ingin membantu menganalisis berkas dump, hubungi Microsoft Layanan dukungan pelanggan. Untuk daftar lengkap dari layanan dukungan pelanggan telepon nomor dan informasi mengenai biaya dukungan, kunjungi berikut Situs Microsoft:

http://support.Microsoft.com/contactus/?ws=support

(http://support.microsoft.com/contactus/?ws=support)

Sebelum Anda menghubungi layanan dukungan pelanggan, kompres berkas dump, log Monitor kinerja, file laporan analisis, dan log peristiwa diperbarui (.evt file). Anda mungkin harus mengirim file ini ke BizTalk Server mendukung insinyur.

Kembali ke atas | Berikan Masukan

Properti

ID Artikel: 918643 - Kajian Terakhir: 13 Juni 2012 - Revisi: 1.0

Berlaku bagi:

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 Edition
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 KbMtid

Penerjemahan Mesin

PENTING: Artikel ini diterjemahkan menggunakan perangkat lunak mesin penerjemah Microsoft dan bukan oleh seorang penerjemah. Microsoft menawarkan artikel yang diterjemahkan oleh seorang penerjemah maupun artikel yang diterjemahkan menggunakan mesin sehingga Anda akan memiliki akses ke seluruh artikel baru yang diterbitkan di Pangkalan Pengetahuan (Knowledge Base) dalam bahasa yang Anda gunakan. Namun, artikel yang diterjemahkan menggunakan mesin tidak selalu sempurna. Artikel tersebut mungkin memiliki kesalahan kosa kata, sintaksis, atau tata bahasa, hampir sama seperti orang asing yang berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab terhadap akurasi, kesalahan atau kerusakan yang disebabkan karena kesalahan penerjemahan konten atau penggunaannya oleh para pelanggan. Microsoft juga sering memperbarui perangkat lunak mesin penerjemah.

Klik disini untuk melihat versi Inggris dari artikel ini: 918643

(http://support.microsoft.com/kb/918643/en-us/ )

Kembali ke atas | Berikan Masukan