Membuat laporan dan bagan dengan penghitung kinerja dengan Alat Analisis Performa Log (PAL) untuk BizTalk Server

Alat PAL (Analisis Performa Log) membaca log penghitung monitor performa dalam format apapun yang diketahui dan menganalisisnya menggunakan ambang batas yang kompleks, yang sudah ditentukan. Alat ini menghasilkan laporan berbasis HTML yang secara grafis memetakan penghitung kinerja yang penting dan mengeluarkan peringatan ketika ambang batas terlampaui. Ambang awalnya didasarkan pada ambang yang ditentukan oleh tim produk Microsoft, termasuk BizTalk Server, dan anggota dukungan Microsoft. Alat ini bukan pengganti analisis performa tradisional, tetapi mengotomatiskan analisis log penghitung kinerja yang cukup untuk membantu menghemat waktu Anda. Alat PAL:

• Menganalisis log penghitung kinerja untuk ambang batas

• Berguna untuk log Perfmon yang besar

• Mengidentifikasi BizTalk Server dan penyempitan penghitung kinerja sistem operasi dengan menganalisis ambang batas

• Dapat diperluas untuk melakukan analisis pada penghitung kinerja apa pun

• Dapat digunakan untuk membantu menulis penghitung Anda sendiri

  PAL tersedia sebagai unduhan gratis di GitHub. Ini memerlukan Microsoft Log Parser. Log Parser adalah alat canggih dan serbaguna yang menyediakan akses kueri universal ke data berbasis teks seperti file log, file XML, dan file CSV, serta sumber data utama pada sistem operasi Windows seperti log peristiwa, registri, sistem file, dan layanan direktori Direktori Aktif®. Anda mungkin ingin menggunakan alat ini untuk mengkueri sejumlah besar informasi pengelogan. Anda dapat mengunduh alat Log Parser.

Menggunakan PAL dengan Log Penghitung Kinerja dalam Berbagai Bahasa

Alat PAL menganalisis log penghitung kinerja hanya dalam bahasa Inggris. Untuk menggunakan alat PAL dengan log penghitung kinerja dalam bahasa lain, Anda harus terlebih dahulu menerjemahkan log ke bahasa Inggris. Anda dapat menggunakan Penerjemah Log Perfmon untuk menerjemahkan file log penghitung kinerja asli ke bahasa Inggris.

Memahami Laporan Perangkat PAL untuk Microsoft BizTalk Server 2010

Alat PAL menyediakan analisis ambang batas log Perfmon untuk sistem operasi Windows, Microsoft SQL Server, dan BizTalk Server. Bagian ini menjelaskan sebagian besar analisis dalam laporan ambang Batas BizTalk Server di alat PAL.

Nota

Topik ini panjang sehingga informasi komprehensif tentang alat PAL dapat dimuat di satu tempat untuk referensi yang mudah.

Analisis dan ambang batas berikut dilaporkan oleh alat PAL.

Jenis dan Nama Analisis	Deskripsi Analisis
Disk: Ruang Disk Kosong untuk Pembuangan Kernel	Analisis ini memeriksa untuk memastikan ada cukup ruang disk kosong agar sistem operasi dapat membuang semua memori ke disk. Jika ruang disk tidak tersedia, maka sistem operasi akan gagal membuat memory.dmp, file yang diperlukan untuk menganalisis akar penyebab cadangan kernel.
Disk: Analisis Antarmuka Disk Logis/Fisik	Analisis ini melihat waktu menganggur dari setiap disk fisik. Semakin tidak aktif disk, semakin sedikit penggunaannya. Penghitung ini paling baik digunakan ketika satu disk digunakan dalam disk logis. "% Waktu Menganggur" melaporkan persentase waktu disk tidak aktif selama interval sampel. Referensi: Meninjau Masalah Disk-Bound
Analisis Latensi Pembacaan/Penulisan Disk Fisik/Logis	Cara yang paling dapat diandalkan bagi Windows untuk mendeteksi hambatan performa disk adalah dengan mengukur waktu responsnya. Jika waktu respons lebih besar dari .025 (25 milidetik), yang merupakan ambang batas konservatif, maka perlambatan yang terlihat dan masalah performa yang memengaruhi pengguna mungkin terjadi. Untuk informasi selengkapnya, lihat Analisis Latensi Baca/Tulis Disk Logis/Fisik dalam topik ini.
Disk: Transfer Disk Logika/detik	"Transfer Disk/detik" adalah tingkat operasi baca dan tulis pada disk. Ambang batas untuk analisis ini adalah untuk memeriksa apakah salah satu disk logis menunjukkan waktu respons yang buruk (lebih dari 25 ms untuk waktu respons operasi I/O). Jika ini benar, maka transfer disk per detik harus pada atau di atas 80. Jika tidak, maka arsitektur disk perlu diselidiki. Penyebab paling umum dari I/O disk yang buruk adalah kelebihan beban LUN pada SAN. Untuk informasi selengkapnya, lihat Transfer Disk Logis/detik dalam topik ini.
Disk: LogicalDisk % Ruang Kosong	"% Ruang Kosong" adalah persentase dari total ruang yang dapat digunakan yang bebas pada drive disk logis yang dipilih. Performa tidak boleh terpengaruh sampai ruang disk drive yang tersedia kurang dari 30 persen. Ketika 70 persen drive disk digunakan, ruang kosong yang tersisa terletak lebih dekat pada spindle disk di tengah drive disk, yang beroperasi pada tingkat kinerja yang lebih rendah. Kurangnya ruang disk kosong dapat menyebabkan performa disk yang parah.
Disk: Analisis Proses Operasi Data IO per Detik dan Operasi IO Lain per Detik	Penghitung ini menghitung semua aktivitas I/O yang dihasilkan oleh proses untuk menyertakan file, jaringan, dan I/Os perangkat. Analisis ini memeriksa kapan proses melakukan lebih dari 1.000 I/O per detik dan menandainya sebagai peringatan. Analisis ini paling baik digunakan dalam korelasi dengan analisis lain seperti analisis disk untuk menentukan proses mana yang mungkin terlibat dalam aktivitas I/O.
Memori: Memori yang Tersedia	Analisis ini memeriksa apakah total memori yang tersedia rendah – Peringatan diberikan saat memori tersisa 10 persen dan Kritis ketika tersisa 5 persen. Peringatan juga diperingatkan ketika tren penurunan 10 MB per jam terdeteksi, yang dapat menunjukkan potensi kondisi memori mendatang. Memori fisik rendah dapat menyebabkan peningkatan CPU mode istimewa dan penundaan sistem. Untuk informasi selengkapnya, lihat Analisis Memori yang Tersedia dalam topik ini.
Memori: Entri Tabel Halaman Sistem Gratis	Entri Tabel Halaman Sistem Gratis (PTE) adalah jumlah entri tabel halaman yang saat ini tidak digunakan oleh sistem. Analisis ini menentukan apakah sistem kehabisan PTE dengan memeriksa apakah ada kurang dari 5.000 PTE gratis dengan Peringatan jika ada kurang dari 10.000 PTE gratis. Kurangnya PTE yang cukup dapat mengakibatkan hang di seluruh sistem. Perhatikan juga bahwa sakelar /3GB akan menurunkan jumlah PTE yang tersedia secara signifikan. Untuk informasi selengkapnya, lihat Analisis Entri Tabel Halaman Sistem Gratis dalam topik ini.
Memori: Deteksi Kebocoran Memori	Analisis ini menentukan apakah salah satu proses mengonsumsi sejumlah besar memori sistem dan apakah prosesnya meningkat dalam konsumsi memori dari waktu ke waktu. Proses yang mengkonsumsi sebagian besar memori tidak masalah selama proses mengembalikan memori kembali ke sistem. Cari peningkatan tren dalam bagan. Tren yang meningkat dalam jangka waktu yang lama dapat menunjukkan kebocoran memori. "Byte Pribadi" adalah ukuran dalam byte saat ini dari memori yang telah dialokasikan oleh proses ini dan tidak dapat dibagikan dengan proses lain. Analisis ini memeriksa tren peningkatan 10 MB per jam dan 5 MB per jam. Gunakan analisis ini dalam korelasi dengan analisis Memori yang Tersedia di PAL. Untuk informasi selengkapnya, lihat Analisis Deteksi Kebocoran Memori dalam topik ini.
Memori: Menangani Deteksi Kebocoran	Analisis ini memeriksa semua proses untuk menentukan berapa banyak handle yang masing-masing dibuka dan untuk menentukan apakah dicurigai kebocoran handle. Proses dengan sejumlah besar handle dan/atau tren peningkatan yang tajam dapat menunjukkan kebocoran handle, yang biasanya mengakibatkan kebocoran memori. Total jumlah handle yang saat ini terbuka oleh proses ini sama dengan total handle yang saat ini dibuka oleh setiap utas dalam proses ini. Referensi: Alat Diagnostik Debug
Memori: Input Halaman Memori/detik	"Masukan Halaman/detik" adalah tingkat di mana halaman dibaca dari disk untuk mengatasi gangguan halaman keras. Kesalahan halaman berat terjadi ketika sebuah proses merujuk pada halaman dalam memori virtual yang tidak ada dalam set kerjanya atau di tempat lain dalam memori fisik, dan harus diambil kembali dari disk. Analisis ini memeriksa apakah ada lebih dari 10 file halaman yang dibaca per detik.
Memori: Halaman Memori/detik	Analisis ini memeriksa apakah "Halaman per detik" tinggi (di atas 1.000). Jika tinggi, maka sistem kemungkinan kehabisan memori dengan mencoba memindahkan memori ke penyimpanan. "Pages/dtk" adalah tingkat di mana halaman dibaca dari atau ditulis ke disk untuk mengatasi kesalahan halaman keras. Penghitung ini adalah indikator utama dari jenis kesalahan yang menyebabkan penundaan di seluruh sistem. Gunakan analisis ini dalam korelasi dengan analisis Memori yang Tersedia dan analisis Deteksi Kebocoran Memori di PAL. Jika semua analisis ini melemparkan pemberitahuan pada saat yang sama, maka ini dapat menunjukkan sistem kehabisan memori dan proses yang dicurigai terlibat dan mengikuti langkah-langkah analisis yang disebutkan dalam analisis Deteksi Kebocoran Memori di PAL. Untuk informasi selengkapnya, lihat Analisis Halaman Memori/dtk dalam topik ini.
Memori: Byte Cache Sistem Memori yang Menetap	"System Cache Resident Bytes" adalah ukuran, dalam byte, dari kode sistem operasi yang dapat di-pageable dalam cache sistem file. Nilai ini hanya mencakup halaman fisik saat ini dan tidak termasuk halaman memori virtual yang saat ini tidak ada di dalamnya. Nilai ini adalah komponen dari "Memory\\System Code Resident Bytes" yang mewakili semua kode sistem operasi pageable yang saat ini berada dalam memori fisik. Penghitung ini hanya menampilkan nilai terakhir yang diamati; itu bukan rata-rata. Analisis ini memeriksa tren peningkatan 10 MB per jam. Di bawah beban, server mungkin menggunakan cache sistem untuk men-cache aktivitas I/O seperti disk. Gunakan dalam korelasi dengan Analisis Operasi Data IO Proses/detik dan Operasi Lain IO Proses/detik di PAL. Referensi: Performa dan Pengoptimalan Cache File
Memori: Kumpulan Byte Tidak Terhalaman	"Pool Nonpaged Bytes" adalah ukuran, dalam byte, dari kumpulan non-halaman, area memori sistem untuk objek yang tidak dapat ditulis ke disk, tetapi harus tetap dalam memori fisik selama dialokasikan. Analisis ini memeriksa apakah ukuran memori yang tidak dipaginasi dari kumpulan sudah mendekati maksimum. Ini dilakukan dengan memperkirakan ukuran kumpulan dengan mempertimbangkan /3GB, ukuran memori fisik, dan 32-bit/64-bit, lalu menentukan apakah nilainya lebih tinggi dari 60 persen dari perkiraan ukuran kumpulan. Jika sistem mendekati ukuran maksimum, maka sistem dapat mengalami hang sistem secara keseluruhan. Opsi /3GB dalam pengaturan file boot.ini secara signifikan mengurangi ukuran kumpulan memori ini. Untuk informasi selengkapnya, lihat Analisis Byte Non-Halaman Kumpulan dalam topik ini.
Memori: Byte Terpaginasi Kolam	Analisis ini memeriksa untuk melihat apakah sistem mendekati ukuran memori halaman kumpulan maksimum. Ini dilakukan dengan memperkirakan ukuran kumpulan dengan mempertimbangkan /3GB, ukuran memori fisik, dan 32-bit/64-bit, lalu menentukan apakah nilainya lebih tinggi dari 60 persen dari perkiraan ukuran kumpulan. Jika sistem mendekati batas maksimum, maka sistem dapat mengalami gangguan sistem secara keseluruhan. Pilihan /3GB switch dalam file boot.ini secara signifikan mengurangi ukuran kumpulan memori ini. Untuk informasi selengkapnya, lihat Pool Paged Bytes Analysis dalam topik ini.
Memori: Jumlah Utas Proses	Analisis ini memeriksa semua proses untuk menentukan apakah proses memiliki lebih dari 500 utas dan apakah jumlah utas meningkat sebesar 50 utas per jam. Proses dengan sejumlah besar utas dan/atau tren kenaikan yang agresif dapat menunjukkan kebocoran utas yang biasanya mengakibatkan kebocoran memori atau pergantian konteks yang tinggi. Pergantian konteks yang tinggi akan menyebabkan CPU beroperasi dalam mode hak istimewa tinggi.
Memori: Set Kerja Proses	"Set Kerja" adalah ukuran saat ini, dalam byte, dari set kerja proses ini. Set kerja adalah kumpulan halaman memori yang baru-baru ini diakses oleh utas dalam proses. Jika memori bebas di komputer berada di atas ambang batas, halaman dibiarkan dalam rangkaian proses yang berfungsi meskipun tidak digunakan. Ketika memori bebas berada di bawah ambang batas, halaman dipangkas dari set kerja. Jika diperlukan, mereka akan dimasukkan kembali secara lembut ke dalam set kerja sebelum meninggalkan memori utama. Analisis ini memeriksa tren peningkatan 10 MB atau lebih di setiap proses. Gunakan dalam korelasi dengan analisis Memori yang Tersedia di PAL. Referensi: Menemukan dan menghilangkan hambatan
Jaringan: Analisis Panjang Antrean Output Jaringan	Analisis ini memeriksa jumlah utas yang menunggu pada adaptor jaringan. Jika banyak utas menunggu adaptor jaringan, maka sistem mungkin menjenuhkan I/O jaringan karena latensi jaringan atau bandwidth jaringan. "Panjang Antrian Output" adalah panjang antrian paket keluaran (dalam paket). Penundaan ditunjukkan jika ini lebih dari dua, dan hambatan harus ditemukan dan dihilangkan, jika memungkinkan. Penyebab umum antrean output jaringan termasuk banyaknya permintaan jaringan yang kecil dan latensi jaringan.
Jaringan: Analisis Pemanfaatan Jaringan	"Total Byte/detik" adalah laju pengiriman dan penerimaan byte melalui setiap adaptor jaringan, termasuk karakter pembingkai. "Antarmuka Jaringan\Byte Diterima/dtk" adalah penjumlahan dari "Antarmuka Jaringan\Byte Diterima/dtk" dan "Antarmuka Jaringan\Byte Terkirim/dtk". Penghitung ini membantu Anda mengetahui apakah lalu lintas di adaptor jaringan Anda jenuh dan apakah Anda perlu menambahkan adaptor jaringan lain. Seberapa cepat Anda dapat mengidentifikasi masalah tergantung pada jenis jaringan yang Anda miliki serta apakah Anda berbagi bandwidth dengan aplikasi lain. Analisis ini mengonversi "Byte Total/detik" menjadi bit dan membandingkannya dengan bandwidth adaptor jaringan saat ini untuk menghitung pemanfaatan jaringan. Selanjutnya, memeriksa pemanfaatan di atas 50 persen. Referensi: Mengukur performa menggunakan EventCounters di .NET Core
Penggunaan File Halaman % dan Puncak Penggunaan %	Jumlah instans file halaman yang sedang digunakan dalam bentuk persentase. Lihat juga "Proses\\Byte Berkas Halaman". Analisis ini memeriksa apakah persentase penggunaan lebih besar dari 70 persen.
Prosesor: Analisis Pemanfaatan Prosesor dan Penggunaan Prosesor Yang Berlebihan oleh Proses	Penghitung ini adalah indikator utama aktivitas prosesor dan menampilkan persentase rata-rata waktu sibuk yang diamati selama interval sampel. Ini dihitung dengan memantau waktu layanan tidak aktif dan mengurangi nilai tersebut dari 100 persen. Analisis ini memeriksa pemanfaatan yang lebih besar dari 60 persen pada setiap prosesor. Jika demikian, tentukan apakah itu CPU mode pengguna tinggi atau mode hak istimewa tinggi. Jika dicurigai adanya CPU dalam mode istimewa tinggi, lihat analisis mode istimewa CPU di PAL. Jika penyempitan prosesor mode pengguna dicurigai, maka pertimbangkan untuk menggunakan profiler proses untuk menganalisis fungsi yang menyebabkan konsumsi CPU yang tinggi.
Prosesor: Panjang Antrean Prosesor	Analisis ini menentukan apakah panjang antrean prosesor rata-rata melebihi jumlah prosesor. Jika demikian, maka ini dapat menunjukkan penyempitan prosesor. Gunakan analisis ini dalam korelasi dengan analisis CPU Mode Istimewa dan analisis Penggunaan Prosesor Berlebihan oleh Proses di PAL. Untuk informasi terperinci, lihat Analisis Panjang Antrean Prosesor dalam topik ini.
Prosesor: Analisis CPU Mode Istimewa	Penghitung ini menunjukkan persentase waktu thread berjalan dalam mode istimewa. Ketika aplikasi Anda memanggil fungsi sistem operasi (misalnya untuk melakukan I/O file atau jaringan atau untuk mengalokasikan memori), fungsi sistem operasi ini dijalankan dalam mode istimewa. Analisis ini memeriksa untuk melihat apakah CPU mode istimewa mengonsumsi lebih dari 30 persen dari total CPU. Jika demikian, konsumsi CPU kemungkinan disebabkan oleh hambatan lain selain prosesor seperti jaringan, memori, atau I/O disk. Gunakan dalam korelasi dengan Prosesor: % Interupsi Waktu dan Prosesor: Analisis Pengalihan Konteks Tinggi di PAL. Untuk informasi selengkapnya, lihat Analisis CPU Mode Istimewa dalam topik ini.
Prosesor: Waktu Interupsi	"% Interrupt Time" adalah waktu yang dihabiskan prosesor untuk menerima dan melayani interupsi perangkat keras selama interval sampel. Nilai ini adalah indikator tidak langsung dari aktivitas perangkat yang menghasilkan gangguan, seperti jam sistem, mouse, driver disk, baris komunikasi data, kartu antarmuka jaringan, dan perangkat periferal lainnya. Perangkat ini biasanya mengganggu prosesor ketika mereka telah menyelesaikan tugas atau memerlukan perhatian. Eksekusi utas normal ditangguhkan selama interupsi. Sebagian besar jam sistem mengganggu prosesor setiap 10 milidetik, menciptakan aktivitas interupsi di latar belakang. Peningkatan dramatis dalam penghitung ini menunjukkan potensi masalah perangkat keras. Analisis ini memeriksa "Interrupt Time%" yang lebih besar dari 30 persen. Jika ini terjadi, pertimbangkan untuk memperbarui driver perangkat untuk perangkat keras yang berkorelasi dengan pemberitahuan ini. Referensi: Mengukur performa menggunakan EventCounters di .NET Core
Prosesor: Pergantian Konteks Tinggi	Peralihan konteks terjadi ketika utas prioritas yang lebih tinggi mendahului utas prioritas yang lebih rendah yang saat ini berjalan atau ketika utas prioritas tinggi memblokir. Tingkat pengalihan konteks yang tinggi dapat terjadi ketika banyak utas memiliki tingkat prioritas yang sama. Ini sering menunjukkan bahwa terlalu banyak utas yang bersaing untuk prosesor pada sistem. Sebagai aturan umum, tingkat peralihan konteks kurang dari 5.000 per detik per prosesor tidak perlu dikhawatirkan. Jika tingkat peralihan konteks melebihi 15.000 per detik per prosesor, maka ada batasan. Untuk informasi selengkapnya, lihat Analisis Pengalihan Konteks Tinggi dalam topik ini.
Microsof BizTalk Server: BizTalk Dehidrasi Orkestrasi	Ketika banyak proses bisnis yang berjalan lama berjalan pada saat yang sama, masalah memori dan performa dimungkinkan. Mesin orkestrasi mengatasi masalah ini dengan melakukan "dehidrasi" dan "rehidrasi" pada instans orkestrasi. Dehidrasi adalah proses serialisasi status orkestrasi ke dalam database SQL Server. Rehidrasi adalah kebalikan dari proses ini: mendeserialisasi status orkestrasi terakhir yang berjalan dari database. Dehidrasi digunakan untuk meminimalkan penggunaan sumber daya sistem dengan mengurangi jumlah orkestrasi yang harus dibuat dalam memori pada satu waktu. Oleh karena itu, dehirasi menghemat konsumsi memori, tetapi merupakan operasi yang relatif mahal untuk dilakukan. Analisis ini memeriksa dehidrasi 10 persen atau lebih. Jika demikian, BizTalk Server mungkin kehabisan memori (baik virtual atau fisik), sejumlah besar orkestrasi menunggu pesan, atau pengaturan dehidrasi tidak diatur dengan benar. Referensi: Dehidrasi orkestrasi dan Rehidrasi
Microsoft BizTalk Server: Sesi BizTalk dengan Aktifitas Basis Data Tinggi	Penghitung ini memiliki dua nilai yang mungkin: normal (0) atau terlampaui (1). Analisis ini memeriksa nilai 1. Jika demikian, BizTalk telah melebihi ambang jumlah sesi database yang diizinkan. Nilai ini dikontrol oleh nilai "Koneksi database per CPU" di pengaturan Pembatasan Host BizTalk. "Koneksi database per CPU" adalah jumlah maksimum sesi database bersamaan yang diizinkan per CPU sebelum pengendalian dimulai. Anda dapat memantau jumlah koneksi Database aktif dengan menggunakan penghitung kinerja sesi Database di bawah kategori objek performa BizTalk:Agen Pesan. Parameter ini hanya memengaruhi pembatasan pesan keluar. Untuk informasi selengkapnya, lihat Analisis Sesi Database Tinggi BizTalk dalam topik ini.
Microsoft BizTalk Server: Ukuran Database BizTalk yang Tinggi	Penghitung ini akan diatur ke nilai 1 jika salah satu kondisi yang tercantum untuk jumlah pesan dalam ambang batas database terjadi. Secara default jumlah pesan host dalam ambang pembatasan database diatur ke nilai 50.000, yang akan memicu kondisi pembatasan dalam keadaan berikut: - Jumlah total pesan yang dikirim oleh instans host ke antrean kerja, antrean status, dan antrean yang ditangguhkan dari host yang berlangganan melebihi 50.000. - Jumlah pesan dalam tabel spool atau tabel pelacakan melebihi 500.000 pesan. Jika ini terjadi, maka pertimbangkan tindakan yang akan mengurangi jumlah pesan dalam database. Misalnya, pastikan pekerjaan SQL Server di BizTalk Server berjalan tanpa kesalahan dan gunakan halaman Hub Grup di konsol Administrasi BizTalk Server untuk menentukan apakah penyusunan pesan disebabkan oleh sejumlah besar pesan yang ditangguhkan. Untuk informasi selengkapnya, lihat Analisis Ukuran Database Tinggi BizTalk dalam topik ini.
Microsoft BizTalk Server: Jumlah Pesan BizTalk Skor Tinggi In-Process	Analisis ini memeriksa penghitung "Jumlah Pesan In-Process yang Tinggi" untuk menentukan apakah pembatasan semacam ini sedang terjadi. Jika demikian, pertimbangkan untuk menyesuaikan setelan "In-Process pesan per CPU". Parameter ini hanya memengaruhi pembatasan pesan keluar. Masukkan nilai 0 dalam pengaturan "In-Process pesan per CPU" untuk menonaktifkan pembatasan berdasarkan jumlah pesan yang sedang diproses per CPU. Nilai default untuk pengaturan "In-Process pesan per CPU" adalah 1.000. Perhatikan bahwa memodifikasi nilai ini juga dapat berdampak pada latensi pesan yang rendah dan/atau efisiensi sumber daya BizTalk. Untuk informasi selengkapnya, lihat Analisis Jumlah Pesan BizTalk High In-Process dalam topik ini.
Microsoft BizTalk Server: Tingkat Pengiriman Pesan Tinggi BizTalk	Analisis ini memeriksa apakah ada nilai 1 pada penghitung untuk Tingkat Pengiriman Pesan yang Tinggi. Tingkat pengiriman pesan yang tinggi dapat disebabkan oleh kompleksitas pemrosesan tinggi, adaptor keluar yang lambat, atau kekurangan sumber daya sistem sesaat. Untuk informasi selengkapnya, lihat BizTalk High Message Delivery Rate Analysis dalam topik ini.
Microsoft BizTalk Server: Tingkat Kecepatan Penerbitan Pesan BizTalk	Pembatasan host masuk, juga dikenal sebagai pembatasan penerbitan pesan di BizTalk Server, diterapkan ke instans host yang berisi adaptor penerimaan atau orkestrasi yang menerbitkan pesan ke database MessageBox. Analisis ini memeriksa nilai 1 di penghitung Laju Penerbitan Pesan Tinggi. Jika ini terjadi, database tidak dapat mengikuti tingkat penerbitan pesan ke database BizTalk MessageBox. Referensi: - Penghitung Kinerja Pembatasan Host - Cara BizTalk Server Menerapkan Pembatasan Host - Ubah Pengaturan Pembatasan Berbasis Laju - Apa itu Perlambatan Host?
Microsoft BizTalk Server: Memori Proses Tinggi BizTalk	Pengaturan ambang batas penggunaan BizTalk Process Memory adalah persentase memori yang digunakan dibandingkan dengan jumlah ukuran set kerja dan total memori virtual yang tersedia untuk proses jika nilai dari 1 hingga 100 dimasukkan. Ketika nilai persentase ditentukan, ambang batas memori proses dihitung ulang secara berkala. Analisis ini memeriksa nilai 1 di penghitung Memori Proses Tinggi. Untuk informasi selengkapnya, lihat Analisis Memori Proses Tinggi BizTalk dalam topik ini.
Microsoft BizTalk Server: Memori Sistem Tinggi BizTalk	Pengaturan ambang batas pembatasan penggunaan Memori Fisik BizTalk adalah persentase konsumsi memori dibandingkan dengan jumlah total memori fisik yang tersedia jika nilai dari 1 hingga 100 dimasukkan. Pengaturan ini juga dapat menjadi jumlah total memori fisik yang tersedia dalam megabyte jika nilai yang lebih besar dari 100 dimasukkan. Masukkan nilai 0 untuk menonaktifkan pembatasan berdasarkan penggunaan memori fisik. Nilai defaultnya adalah 0. Untuk informasi selengkapnya, lihat Analisis Memori Sistem Tinggi BizTalk dalam topik ini.
Microsoft BizTalk Server: BizTalk Jumlah Utas Tinggi	"Thread Per CPU" adalah jumlah total utas dalam proses host termasuk utas yang digunakan oleh adaptor. Jika ambang batas ini terlampaui, BizTalk Server akan mencoba mengurangi ukuran kumpulan utas EPM dan kumpulan utas agen pesan. Pembatasan berbasis utas harus diaktifkan dalam skenario di mana beban kerja yang tinggi dapat menyebabkan pembuatan sejumlah besar utas. Parameter ini memengaruhi pengaturan pembatasan lalu lintas masuk dan keluar. Pembatasan berbasis utas dinonaktifkan dalam kondisi default. Untuk informasi selengkapnya, lihat Analisis Jumlah Utas Tinggi BizTalk dalam topik ini.
Microsoft BizTalk Server: Panjang Antrian Host BizTalk	Panjang Antrean Host BizTalk melacak jumlah total pesan dalam antrean host tertentu. Anda dapat menggunakan ukuran panjang, misalnya, BizTalk:MessageBox:HostCounters:Host Queue – Length, untuk memberikan tampilan yang lebih rinci tentang jumlah pesan yang diantrekan secara internal dengan menunjukkan kedalaman antrean untuk host individual. Penghitung ini dapat berguna dalam menentukan apakah host tertentu tersempitan. Dengan asumsi host unik digunakan untuk setiap transportasi, ini dapat membantu dalam menentukan potensi kemacetan transportasi. Analisis ini memeriksa antrean yang memiliki panjang rata-rata lebih besar dari 1. Panjang Antrean Host adalah panjang antrean yang diperhitungkan secara tertimbang dengan menggabungkan jumlah rekaman dari semua antrean (Work Q, State Q, Suspended Q) pada host target. Referensi: BizTalk Server 2010: Metodologi Pengujian Performa Server BizTalk
Microsoft BizTalk Server: Panjang Antrean Pesan Yang Ditangguhkan Host BizTalk	Penghitung ini melacak jumlah total pesan yang ditangguhkan untuk host tertentu. Pesan yang ditangguhkan adalah instans pesan atau orkestrasi yang telah berhenti diproses oleh BizTalk Server karena kesalahan dalam sistem atau pesan. Umumnya, instans yang ditangguhkan yang disebabkan oleh kesalahan sistem dapat dilanjutkan setelah penyelesaian masalah sistem. Seringkali, instans yang ditangguhkan karena masalah pesan tidak dapat dilanjutkan, dan pesan itu sendiri harus diperbaiki dan dikirim ulang ke sistem BizTalk Server. Antrian pesan yang ditangguhkan adalah antrian yang berisi item kerja yang mengalami kesalahan atau kegagalan selama pemrosesan. Antrean yang ditangguhkan menyimpan pesan hingga pesan dapat diperbaiki dan diolah ulang, atau dihapus. Analisis ini memeriksa setiap kemunculan pesan yang ditangguhkan. Tren yang meningkat dapat menunjukkan kesalahan pemrosesan yang parah. Referensi: - Memantau Kesehatan dan Performa BizTalk Server - Pemecahan Masalah Microsoft BizTalk Server
BizTalk Server: Orkestrasi BizTalk yang Menganggur	Jumlah instans orkestrasi diam yang dihosting saat ini oleh instans host. Penghitung ini mengacu pada orkestrasi yang tidak membuat kemajuan tetapi tidak dapat didehidrasi. Situasi ini dapat terjadi ketika orkestrasi diblokir, menunggu untuk menerima, mendengarkan, atau mengalami penundaan dalam transaksi atom. Jika sejumlah besar orkestrasi yang tidak dapat didehidrasi terakumulasi, maka BizTalk mungkin kehabisan memori. Dehidrasi adalah proses serialisasi status orkestrasi ke dalam database SQL Server. Rehidrasi adalah kebalikan dari proses ini: mendeserialisasi status orkestrasi terakhir yang berjalan dari database. Dehidrasi digunakan untuk meminimalkan penggunaan sumber daya sistem dengan mengurangi jumlah orkestrasi yang harus dibuat dalam memori pada satu waktu. Mesin melakukan dehidrasi instans dengan menyimpan status, dan membebaskan memori yang diperlukan oleh instans. Dengan mengeringkan instans orkestrasi yang tidak aktif, mesin dapat memungkinkan sejumlah besar proses bisnis jangka panjang untuk berjalan bersamaan pada komputer yang sama. Analisis ini memeriksa adanya tren peningkatan frekuensi satu orkestrasi menganggur setiap jam. Referensi: Dehidrasi orkestrasi dan Rehidrasi.
BizTalk Server: Latensi Masuk BizTalk	Latensi rata-rata dalam milidetik dari ketika mesin olahpesan menerima dokumen dari adaptor hingga waktu diterbitkan ke MessageBox. Mengurangi latensi penting bagi beberapa pengguna BizTalk, oleh karena itu melacak berapa banyak waktu yang dihabiskan dokumen dalam adaptor masuk penting. Untuk informasi selengkapnya, lihat Analisis Latensi Masuk BizTalk dalam topik ini.
BizTalk Server: Penundaan Pengiriman Pesan BizTalk	Ini adalah penundaan saat ini dalam milidetik (md) yang diberlakukan pada setiap batch pengiriman pesan (berlaku jika pengiriman pesan sedang dibatasi). Terkait dengan pengaturan batas kecepatan, penundaan diterapkan dalam penerbitan atau pemrosesan pesan, tergantung apakah pesan tersebut masuk atau keluar. Periode penundaan sebanding dengan tingkat keparahan kondisi pembatasan. Kondisi pembatasan tingkat keparahan yang lebih tinggi akan memulai periode pembatasan yang lebih lama daripada kondisi pembatasan tingkat keparahan yang lebih rendah. Periode penundaan ini disesuaikan secara fleksibel dalam rentang tertentu oleh mekanisme throttle saat kondisi berubah. Periode penundaan saat ini diekspos melalui penundaan pengiriman pesan (ms) dan penghitung kinerja penundaan penerbitan pesan (ms) yang terkait dengan kategori objek performa BizTalk:Agen Pesan. Analisis ini memeriksa keterlambatan pengiriman pesan yang lebih besar dari 5 detik. Penundaan pengiriman pesan panjang dapat menunjukkan pembatasan berat karena beban tinggi. Referensi: Cara BizTalk Server Menerapkan Pembatasan Host.
BizTalk Server: Status Pembatasan Pengiriman Pesan BizTalk	Status pembatasan pengiriman pesan BizTalk adalah salah satu indikator utama pembatasan. Ini adalah indikator yang menunjukkan apakah sistem membatasi pengiriman pesan (memengaruhi pemrosesan pesan XLANG dan pengiriman keluar). Kondisi pembatasan diindikasikan oleh nilai numerik penghitung. Untuk informasi selengkapnya, lihat Analisis Status Pembatasan Pengiriman Pesan BizTalk dalam topik ini.
BizTalk Server: Penundaan Penerbitan Pesan BizTalk	Penundaan yang diterapkan dalam setiap batch yang memenuhi syarat untuk membatasi penerbitan pesan. Dalam hal pengendalian laju, diterapkan penundaan dalam penyampaian atau pemrosesan pesan, tergantung pada apakah pesan tersebut merupakan pesan masuk atau keluar. Periode penundaan sebanding dengan tingkat keparahan kondisi pelambatan. Kondisi pembatasan tingkat keparahan yang lebih tinggi akan memulai periode pembatasan yang lebih lama daripada kondisi pembatasan tingkat keparahan yang lebih rendah. Periode penundaan ini disesuaikan ke atas dan ke bawah dalam rentang tertentu oleh mekanisme pembatasan saat kondisi berubah. Periode penundaan saat ini diekspos melalui penundaan pengiriman pesan (ms) dan penghitung kinerja penundaan penerbitan pesan (ms) yang terkait dengan kategori objek performa BizTalk:Agen Pesan. Analisis ini memeriksa penundaan penerbitan pesan yang lebih besar dari 5 detik. Penundaan pengiriman pesan yang lama dapat menunjukkan pelambatan yang signifikan karena beban kerja yang tinggi. Referensi: Cara BizTalk Server Menerapkan Pembatasan Host.
BizTalk Server: BizTalk MessageBox Kegagalan Koneksi Database	Penghitung kinerja ini adalah jumlah koneksi database yang dicoba yang gagal sejak instans host dimulai. Jika layanan SQL Server yang menghosting database BizTalk menjadi tidak tersedia karena alasan apa pun, kluster database mentransfer sumber daya dari komputer aktif ke komputer pasif. Selama proses failover ini, instans layanan BizTalk Server mengalami kegagalan koneksi database dan secara otomatis menghidupkan ulang untuk terhubung kembali ke database. Komputer database yang berfungsi (sebelumnya komputer pasif) mulai memproses koneksi database setelah mengasumsikan sumber daya selama failover. Untuk informasi selengkapnya, lihat Analisis Kegagalan Koneksi Database BizTalk MessageBox dalam topik ini.
BizTalk Server: Latensi Pengolahan Pesan BizTalk: Latensi Respons atas Permintaan	Latensi rata-rata dalam milidetik dari ketika Mesin Olahpesan menerima dokumen permintaan dari adaptor hingga waktu dokumen respons diberikan kembali ke adaptor. Lihat bagan yang memperlihatkan bagaimana latensi diukur dalam Analisis Latensi Masuk BizTalk dalam topik ini. Dengan asumsi bahwa lingkungan memiliki latensi rendah, analisis ini memeriksa apakah latensi Request-Response lebih besar dari 5 detik. Ini dapat menunjukkan penundaan pemrosesan antara adaptor masuk dan adaptor keluar. Referensi: - Pengiriman/Respons Pesan - Menskalakan Solusi Anda
BizTalk Server: Status Pembatasan Penerbitan Pesan BizTalk	Status pengaturan pembatasan penerbitan pesan BizTalk adalah salah satu indikator utama pembatasan. Ini adalah bendera yang menunjukkan apakah sistem membatasi penerbitan pesan (memengaruhi pemrosesan pesan XLANG dan transportasi masuk). Untuk informasi selengkapnya, lihat Analisis Status Pembatasan Penerbitan Pesan BizTalk dalam topik ini.
BizTalk Server: BizTalk Orchestration Ditangguhkan per detik	Pesan yang ditangguhkan adalah instans pesan atau orkestrasi yang telah berhenti diproses oleh BizTalk Server karena kesalahan dalam sistem atau pesan. Umumnya, instans yang ditangguhkan yang disebabkan oleh kesalahan sistem dapat dilanjutkan setelah penyelesaian masalah sistem. Seringkali, instans yang ditangguhkan karena masalah pesan tidak dapat dilanjutkan, dan pesan itu sendiri harus diperbaiki dan dikirim ulang ke sistem BizTalk Server. Analisis ini memeriksa setiap pesan dan orkestrasi yang ditangguhkan. Referensi: - Memantau Kesehatan dan Performa BizTalk Server - Pemecahan Masalah Microsoft BizTalk Server
BizTalk Server: BizTalk Orchestrations Diselesaikan/detik	Ini adalah jumlah orkestrasi BizTalk yang telah selesai per detik. Ini adalah indikator yang baik tentang berapa banyak throughput yang diproses BizTalk. Analisis ini hanya menyediakan statistik. Referensi: Menskalakan Solusi Anda
BizTalk Server: BizTalk Orchestrations Dibuang	Jumlah instance orkestrasi yang dibuang dari memori sejak instance host dimulai. Orkestrasi dapat dibuang jika mesin gagal mempertahankan statusnya. Analisis ini memeriksa apakah ada pesan yang dibuang. Referensi: Catatan Web Mesin Inti BizTalk
BizTalk Server: Orkestrasi BizTalk Tertanam dalam Memori	Jumlah instans orkestrasi yang saat ini dihosting oleh instans host. Analisis ini memeriksa tren peningkatan dalam orkestrasi yang tinggal dalam memori dan apakah lebih dari 50 persen orkestrasi yang tinggal dalam memori tidak dehidrasi. Untuk informasi selengkapnya, lihat BizTalk Orchestrations Resident in Memory Analysis.
BizTalk Server: Latensi Adaptor Keluar BizTalk	Ini adalah latensi rata-rata dalam hitungan detik sejak adaptor mendapatkan dokumen dari mesin pengolah pesan hingga waktu dokumen tersebut dikirim oleh adaptor. Lihat bagan yang memperlihatkan bagaimana latensi diukur dalam Analisis Latensi Masuk BizTalk dalam topik ini. Dengan asumsi lingkungan latensi rendah, analisis ini memeriksa latensi pada adaptor keluar yang rata-rata lebih dari 5 detik. Ini dapat menunjukkan penundaan pemrosesan dalam transportasi pesan melalui adaptor keluar dalam instans host ini. Jika beberapa adaptor keluar ada dalam instans host ini, pertimbangkan untuk memisahkannya ke host mereka sendiri untuk menentukan adaptor keluar mana yang memiliki latensi tinggi. Referensi: - Pesan Permintaan/Respons. - BizTalk Server 2006: Studi Kasus Skalabilitas Menggunakan Adaptor SOAP di BizTalk Server 2006 - Mengidentifikasi Hambatan di Tingkat BizTalk - Low-Latency Pengoptimalan Skenario untuk BizTalk Server
BizTalk Server: Pesan BizTalk Tertunda	Jumlah pesan yang diterima yang belum diakui sebagai diterima ke MessageBox. Pesan yang tertunda adalah pesan yang telah ditarik ke dalam memori dan dikirimkan ke orkestrasi XLANG, tetapi belum diproses. Keadaan ini tidak ada hubungannya dengan kehilangan data. Mengirimkan pesan ke orkestrasi adalah proses dengan banyak langkah dan hanyalah contoh pesan yang berada di tabel penampung dalam database. Pesan yang tertunda ini dihitung sebagai pesan dalam proses; oleh karena itu, memiliki sejumlah besar dalam memori dapat menyebabkan pembatasan memori pada sistem. Menyesuaikan pengaturan Ukuran Antrean Pesan Internal dapat membantu mengontrol jumlah pesan yang tertunda. Pengaturan In-Process Pesan Per CPU mempengaruhi waktu pemberlakuan pembatasan ketika terjadi sejumlah besar pesan yang tertunda. Pengaturan ini ditemukan di properti Host di Konsol Administrasi BizTalk. Pemeriksaan analisis ini hanya menunjukkan statistik untuk penghitung ini. Referensi: Penghitung Kinerja Mesin Orkestrasi.
BizTalk Server: Poin Persistensi BizTalk/detik	Jumlah rata-rata instans orkestrasi bertahan per detik. Mesin orkestrasi menyimpan status instans orkestrasi yang sedang berjalan pada berbagai titik. Jika perlu merehidrasi instans orkestrasi, memulai dari penghentian terkontrol, atau pulih dari penghentian yang tidak terduga, instans orkestrasi akan dijalankan dari titik persistensi terakhir. Untuk menyimpan instans orkestrasi, semua instans objek yang dirujuk oleh orkestrasi baik secara langsung maupun tidak langsung (misalnya melalui objek lain) harus diserialisasi. Saat frekuensi persistensi pesan (berapa kali data perlu dipertahankan) meningkat, performa keseluruhan menurun. Akibatnya, setiap titik persistensi adalah perjalanan pulang pergi ke database, jadi jika memungkinkan mengurangi frekuensi titik persistensi dengan menghindari atau mengonsolidasikan titik persistensi. Lihat referensi di bawah ini untuk informasi selengkapnya mengenai kapan titik persistensi terjadi. Analisis ini memeriksa rata-rata lebih dari 10 titik persistensi per detik. Ini adalah titik awal umum. Referensi: - Persistensi dalam Orkestrasi - Persistensi dan Mesin Orkestrasi
BizTalk Server: BizTalk Private Bytes	Ini adalah megabyte memori privat yang dialokasikan untuk instans host dan sebanding dengan penghitung kinerja "\Process(*)\Private Bytes". Analisis ini menentukan apakah salah satu instans host mengonsumsi memori sistem dalam ukuran besar dan apakah instans host meningkat dalam konsumsi memori dari waktu ke waktu. Lihat Analisis Byte Privat BizTalk dalam topik ini untuk informasi selengkapnya.
BizTalk Server: Ukuran Tabel BizTalk Spool	Tabel antrian MessageBox berisi catatan untuk setiap pesan dalam sistem (yang aktif atau menunggu untuk dihapus secara otomatis). Memantau jumlah baris dalam tabel ini dan jumlah pesan yang diterima per detik sambil meningkatkan beban sistem memberikan cara mudah untuk menemukan throughput berkelanjutan maksimum. Cukup tingkatkan beban input hingga 1) tabel penampung mulai tumbuh tanpa batas atau 2) jumlah pesan yang diterima per detik mendatar, mana yang lebih dulu terjadi, dan itu adalah throughput berkelanjutan maksimum Anda. Singkatnya, terlepas dari indikator lain, ukuran ini akan memberi Anda cara yang cepat dan mudah untuk menilai apakah sistem Anda sedang melebihi beban atau tidak. Ketika ukuran tabel penampung BizTalk berada pada tren yang meningkat, maka pembatasan karena tingkat pengiriman pesan yang tidak seimbang (laju input melebihi laju output) atau pembatasan karena ukuran Database dapat terjadi. Analisis ini memeriksa apakah ada tren peningkatan dalam Ukuran Tabel BizTalk Spool. Referensi: - Memahami Throughput dan Kapasitas BizTalk Server 2004 SP1 - Uji Beban Berkelanjutan - Rekomendasi Saat Menguji Performa Mesin.
BizTalk Server: Ukuran Data Pelacakan BizTalk	Saat BizTalk Server memproses semakin banyak data pada sistem Anda, database Pelacakan BizTalk (BizTalkDTADb) terus bertambah ukurannya. Pertumbuhan yang tidak terkontrol mengurangi performa sistem dan dapat menghasilkan kesalahan dalam Layanan Pengiriman Data Pelacakan (TDDS). Selain data pelacakan umum, pesan terlacak juga dapat terakumulasi dalam database MessageBox, menyebabkan performa disk yang buruk. Analisis ini memeriksa tren peningkatan lebih dari 5 MB per jam dalam ukuran data pelacakan. Referensi: Pengarsipan dan Pembersihan Database Pelacakan BizTalk
BizTalk Server: BizTalk Transactional Scopes Dibatalkan	Ini adalah jumlah cakupan jangka panjang atau atomik yang telah dibatalkan sejak instans host dimulai. Penghentian cakupan transaksional adalah kegagalan yang terjadi dalam transaksi di dalam sebuah orkestrasi. Penting untuk dipahami bahwa penanganan kompensasi cakupan hanya dipanggil jika cakupan berhasil diselesaikan, tetapi kemudian diperlukan untuk dibatalkan karena cakupan di sekitarnya telah memutuskan untuk membatalkan (karena kegagalan yang mungkin terjadi nanti dalam proses). Selain itu, tidak ada pembatalan status "otomatis" yang terjadi jika transaksi dibatalkan. Anda dapat mencapai hasil ini secara terprogram melalui penangan pengecualian dan kompensasi. Cakupan transaksi yang dihentikan seharusnya tidak terjadi secara normal di lingkungan produksi; oleh karena itu, analisis ini memeriksa terjadinya cakupan transaksi yang dihentikan. Referensi: Transaksi
BizTalk Server: Lingkup Transaksional BizTalk Dikompensasi	Kompensasi dapat dianggap sebagai pembatalan logis dari pekerjaan yang telah berhasil dilakukan sebagai respons terhadap kondisi kesalahan tertentu. Penting untuk dipahami bahwa penangan pengganti pada cakupan hanya dipanggil jika cakupan berhasil diselesaikan, tetapi kemudian perlu dibatalkan karena cakupan di sekitarnya telah memutuskan untuk menghentikan proses tersebut (karena kegagalan yang mungkin terjadi di kemudian hari). Selain itu, tidak ada pembatalan status "otomatis" yang terjadi jika transaksi dibatalkan. Anda dapat mencapai ini secara terprogram melalui penangan pengecualian dan kompensasi. Kompensasi cakupan transaksi tidak boleh terjadi secara normal di lingkungan produksi; oleh karena itu, analisis ini memeriksa terjadinya cakupan transaksi yang dibatalkan. Referensi: Transaksi
BizTalk Server: BizTalk Virtual Bytes	Ini adalah megabyte yang dicadangkan untuk memori virtual pada instance host. Analisis ini menentukan apakah salah satu instans host menggunakan sejumlah besar memori sistem dan apakah instans host meningkat dalam konsumsi memori dari waktu ke waktu. Untuk informasi selengkapnya, lihat Analisis BizTalk Virtual Bytes dalam topik ini.
BizTalk Server: Pengaturan Pembatasan Sesi Database Agen Pesan BizTalk	Ini adalah jumlah koneksi database terbuka ke MessageBox dibandingkan dengan pengaturan pembatasan BizTalk masing-masing. "Koneksi database per CPU" adalah jumlah maksimum sesi database bersamaan yang diizinkan per CPU sebelum pengendalian dimulai. Untuk informasi selengkapnya, lihat Analisis Pembatasan Sesi Database Agen Pesan BizTalk dalam topik ini.
BizTalk Server: Batas Pembatasan Sesi Database Agen Pesan BizTalk	Ini adalah ambang batas saat ini untuk jumlah koneksi database terbuka ke MessageBox. "Koneksi database per CPU" adalah jumlah maksimum sesi database bersamaan yang diizinkan per CPU sebelum pengendalian dimulai. Untuk informasi selengkapnya, lihat BizTalk Message Agent Database Session Throttling Threshold Analysis pada topik ini.
BizTalk Server: Pengaturan Pembatasan Jumlah Pesan Dalam Proses oleh BizTalk Message Agent	Ini adalah jumlah pesan bersamaan yang diproses oleh kelas layanan. Pengaturan "Pesan dalam proses per CPU" di Pengaturan Pembatasan Host adalah jumlah maksimum pesan yang dikirimkan ke End Point Manager (EPM) atau XLANG yang belum diproses. Untuk informasi lebih lanjut, lihat Analisis Pembatasan Jumlah Pesan Dalam Proses Agen Pesan BizTalk dalam topik ini.
BizTalk Server: Ambang Pembatasan Jumlah Pesan Dalam Proses BizTalk Message Agent	Ini adalah ambang batas saat ini untuk jumlah pesan bersamaan yang diproses oleh kelas layanan. Pengaturan "Pesan dalam proses per CPU" di Pengaturan Pembatasan Host adalah jumlah maksimum pesan yang dikirim ke End Point Manager (EPM) atau XLANG yang belum diproses. Untuk informasi selengkapnya, lihat BizTalk Message Agent In-process Message Count Throttling Threshold Analysis dalam topik ini.
BizTalk Server: Penggunaan Memori Proses Agen Pesan BizTalk (MB) Pembatasan	Ini adalah penggunaan memori proses saat ini (MB). Pembatasan memori proses BizTalk dapat terjadi jika batch yang akan diterbitkan memiliki kebutuhan memori yang tinggi, atau jika terlalu banyak thread yang memproses pesan. Untuk informasi selengkapnya, lihat Analisis Pembatasan Penggunaan Memori Proses Agen Pesan BizTalk (MB) dalam topik ini.
BizTalk Server: Ambang Batas Penundaan Penggunaan Memori Proses Agen Pesan BizTalk (MB)	Ini adalah ambang batas saat ini untuk penggunaan memori proses saat ini (MB). Ambang batas dapat disesuaikan secara dinamis tergantung pada jumlah memori aktual yang tersedia untuk proses ini dan pola konsumsi memorinya. Pembatasan memori proses BizTalk dapat terjadi jika batch yang akan diterbitkan memiliki persyaratan memori yang curam, atau jika terlalu banyak utas yang memproses pesan. Untuk informasi lebih lanjut, lihat Analisis Ambang Batas Pembatasan Penggunaan Memori (MB) BizTalk Message Agent Process di topik ini.
BizTalk Server: Penurunan Jumlah Thread Agen Pesan BizTalk	Jumlah total utas dalam proses BizTalk. "Thread Per CPU" adalah jumlah total utas dalam proses host termasuk utas yang digunakan oleh adaptor. Jika ambang batas ini terlampaui, BizTalk Server akan mencoba mengurangi ukuran kumpulan utas EPM dan kumpulan utas agen pesan. Pembatasan berbasis utas harus diaktifkan dalam skenario di mana beban kerja yang tinggi dapat menyebabkan pembuatan sejumlah besar utas. Parameter ini memengaruhi pengaturan pembatasan lalu lintas masuk dan keluar. Pembatasan berbasis utas dinonaktifkan dalam kondisi default. Analisis ini memeriksa apakah jumlah BizTalk Thread lebih besar dari 80 persen dari nilai ambang batas pembatasan yang menunjukkan kemungkinan kondisi pembatasan. Referensi: - Penghitung Kinerja Pembatasan Host - Cara BizTalk Server Menerapkan Pembatasan Host - Cara Mengubah Pengaturan Pembatasan Host Default - Parameter Konfigurasi yang Memengaruhi Performa Adapter - Thread, sesi DB, dan pembatasan
BizTalk Server: Batas Penghitungan Utas Agen Pesan BizTalk	Ini adalah ambang batas saat ini untuk jumlah total utas dalam proses. "Thread Per CPU" adalah jumlah total utas dalam proses host termasuk utas yang digunakan oleh adaptor. Jika ambang batas ini terlampaui, BizTalk Server akan mencoba mengurangi ukuran kumpulan utas EPM dan kumpulan utas agen pesan. Pembatasan berbasis utas harus diaktifkan dalam skenario di mana beban tinggi dapat menyebabkan pembentukan banyak utas. Parameter ini memengaruhi pengaturan pembatasan lalu lintas masuk dan keluar. Analisis ini memeriksa apakah pengaturan pembatasan ini diatur ke nilai non-default. Pembatasan berbasis utas dinonaktifkan dalam kondisi default. Referensi: - Penghitung Kinerja Pembatasan Host - Cara BizTalk Server Menerapkan Pembatasan Host - Cara Mengubah Pengaturan Pembatasan Kecepatan Host Default - Parameter Konfigurasi yang Memengaruhi Performa Adapter - Thread, sesi DB, dan pengendalian

Analisis Latensi Pembacaan/Penulisan Disk Fisik/Logis

Cara yang paling dapat diandalkan bagi Windows untuk mendeteksi hambatan performa disk adalah dengan mengukur waktu responsnya. Jika waktu respons lebih besar dari .025 (25 milidetik), yang merupakan ambang batas konservatif, maka perlambatan yang terlihat dan masalah performa yang memengaruhi pengguna mungkin terjadi.

Penyebab umum latensi disk yang buruk adalah fragmentasi disk, cache performa, SAN yang terlalu jenuh, dan terlalu banyak beban pada disk. Gunakan alat SPA untuk membantu mengidentifikasi file dan proses teratas menggunakan disk. Periksa juga "Operasi Data Proses IO/detik" dan "Proses IO Operasi Lain/detik" untuk melihat proses mana yang paling banyak menggunakan I/O disk. Perlu diingat bahwa penghitung pemantauan performa tidak dapat menentukan file mana yang terlibat.

Referensi

• Menyingkirkan Masalah Disk-Bound

• Cara Mengidentifikasi Hambatan Performa Disk Menggunakan Alat Microsoft Server Performance Advisor (SPA)

• Rincian Unduhan untuk Microsoft Service Performance Advisor (SPA)

Transfer yang Logis/Disk/detik

"Transfer Disk/detik" adalah tingkat operasi baca dan tulis pada disk. Meskipun transfer disk bukan korelasi langsung dengan I/O disk, mereka memberi tahu kami berapa banyak operasi disk yang terjadi. Jika Anda menghitung rata-rata dari I/O berurutan dan I/O acak, maka Anda mendapatkan sekitar 80 I/O per detik sebagai aturan praktis umum. Oleh karena itu, kita harus mengharapkan drive SAN untuk melakukan lebih dari 80 I/O per detik ketika di bawah beban. Ambang batas untuk analisis ini adalah untuk memeriksa apakah salah satu disk logis menunjukkan waktu respons yang buruk (lebih dari 25 ms untuk waktu respons operasi I/O). Jika ini benar, maka kita harus mengharapkan transfer disk per detik berada di atau di atas 80. Jika tidak, maka arsitektur disk perlu diselidiki. Penyebab paling umum dari I/O disk yang buruk adalah kelebihan beban nomor unit logis (LUN) pada SAN - yang berarti kondisi di mana lebih dari satu LUN menggunakan array disk fisik kecil.

Analisis Memori yang Tersedia

"Tersedia Mbyte" adalah jumlah memori fisik yang tersedia untuk proses yang berjalan di komputer, dalam megabyte. Virtual Memory Manager terus menyesuaikan ruang yang digunakan dalam memori fisik dan pada disk untuk mempertahankan jumlah minimum byte yang tersedia untuk sistem operasi dan proses. Ketika byte yang tersedia berlimpah, Virtual Memory Manager memungkinkan kumpulan kerja proses bertambah, atau menjaganya tetap stabil dengan menghapus halaman lama untuk setiap halaman baru yang ditambahkan. Ketika byte yang tersedia sedikit, Virtual Memory Manager harus mengurangi set kerja proses untuk menjaga batas minimum yang diperlukan.

Analisis ini memeriksa apakah total memori yang tersedia rendah - Peringatan jika 10 persen tersedia dan Bahaya jika 5 persen tersedia. Peringatan juga diberikan ketika tren penurunan 10 MB setiap jam terdeteksi, mengindikasikan potensi masalah memori. Memori fisik rendah dapat menyebabkan peningkatan CPU mode istimewa dan penundaan sistem.

Referensi

• Mengecualikan Masalah Memory-Bound

Analisis Deteksi Kebocoran Memori

Analisis ini menentukan apakah salah satu proses mengonsumsi sejumlah besar memori sistem dan apakah prosesnya meningkat dalam konsumsi memori dari waktu ke waktu. Proses yang mengkonsumsi sebagian besar memori tidak apa-apa selama proses mengembalikan memori kembali ke sistem. Cari peningkatan tren dalam bagan. Tren yang meningkat dalam jangka waktu yang lama dapat menunjukkan kebocoran memori. Private Bytes adalah ukuran saat ini, dalam byte, dari memori yang telah dialokasikan oleh proses ini dan tidak dapat dibagikan dengan proses lain. Analisis ini memeriksa tren peningkatan 10 MB per jam dan 5 MB per jam. Gunakan analisis ini dalam korelasi dengan analisis Memori yang Tersedia.

Selain itu, perlu diingat bahwa proses yang baru dimulai awalnya akan muncul sebagai kebocoran memori ketika itu hanya perilaku startup normal. Kebocoran memori terjadi ketika proses terus mengonsumsi memori dan tidak melepaskan memori dalam jangka waktu yang lama.

Jika Anda mencurigai kondisi kebocoran memori, instal dan gunakan alat Debug Diag. Untuk informasi selengkapnya tentang Alat Diagnosis Debug, lihat bagian referensi.

Referensi

Alat Diagnostik Debug

Analisis Halaman Memori per Detik

Analisis ini memeriksa apakah "Halaman/detik" tinggi. Jika tinggi, maka sistem kemungkinan kehabisan memori dengan mencoba memindahkan memori ke penyimpanan. "Pages/dtk" adalah tingkat di mana halaman dibaca dari atau ditulis ke disk untuk mengatasi kesalahan halaman keras. Penghitung ini adalah indikator utama dari jenis kesalahan yang menyebabkan penundaan di seluruh sistem. Ini adalah jumlah "Memori\Halaman Input/dtk" dan "Memori\Halaman Output/dtk". Ini dihitung dalam jumlah halaman, sehingga dapat dibandingkan dengan jumlah halaman lain, seperti "Memori\Kesalahan Halaman/detik".

Penghitung ini harus selalu di bawah 1.000. Analisis ini memeriksa nilai di atas 1.000. Gunakan analisis ini dalam korelasi dengan Analisis Memori yang Tersedia dan analisis Deteksi Kebocoran Memori. Jika semua analisis melemparkan pemberitahuan pada saat yang sama, maka ini dapat menunjukkan bahwa sistem kehabisan memori. Ikuti langkah-langkah analisis yang disebutkan dalam Informasi Tambahan Mengenai analisis Deteksi Kebocoran Memori dalam topik ini.

Referensi

Mengecualikan Masalah Memory-Bound

Analisis Byte Cache Sistem Memori yang Tersimpan

"System Cache Resident Bytes" adalah ukuran, dalam byte, dari kode sistem operasi yang dapat di-pageable dalam cache sistem file. Nilai ini hanya mencakup halaman fisik saat ini dan tidak termasuk halaman memori virtual yang saat ini tidak ada di dalamnya. Ini sama dengan nilai Cache Sistem yang tertera di Task Manager. Akibatnya, nilai ini mungkin lebih kecil dari jumlah memori virtual aktual yang digunakan oleh cache sistem file. Nilai ini adalah komponen dari "Memory\\System Code Resident Bytes", yang mewakili semua kode sistem operasi pageable yang saat ini berada dalam memori fisik. Penghitung ini hanya menampilkan nilai terakhir yang diamati; itu bukan rata-rata.

Analisis ini memeriksa tren peningkatan 10 MB per jam. Di bawah beban, server mungkin menggunakan cache sistem untuk men-cache aktivitas I/O seperti disk. Gunakan dalam korelasi dengan Process IO Data Operations/detik dan Process IO Other Operations/sec analyses.

Analisis Pemanfaatan Prosesor dan Penggunaan Prosesor Yang Berlebihan berdasarkan Proses

"% Waktu Prosesor" adalah persentase waktu yang berlalu yang dihabiskan prosesor untuk menjalankan utas yang tidak menganggur. Ini dihitung dengan mengukur berapa lama utas idle aktif dalam interval sampel, lalu mengurangi waktu tersebut dari durasi interval. (Setiap prosesor memiliki utas menganggur yang mengonsumsi siklus ketika tidak ada utas lain yang siap dijalankan.) Penghitung ini adalah indikator utama aktivitas prosesor dan menampilkan persentase rata-rata waktu sibuk yang diamati selama interval sampel. Ini dihitung dengan memantau waktu layanan tidak aktif, dan mengurangi nilai tersebut dari 100 persen.

Analisis ini memeriksa pemanfaatan yang lebih besar dari 60 persen pada setiap prosesor individu. Jika demikian, tentukan apakah itu CPU mode pengguna tinggi atau mode hak istimewa tinggi. Jika mode hak istimewa tinggi pada CPU dicurigai, lihat "Analisis CPU Mode Istimewa". Jika penyempitan prosesor mode pengguna dicurigai, maka pertimbangkan untuk menggunakan profiler proses untuk menganalisis fungsi yang menyebabkan konsumsi CPU yang tinggi. Lihat artikel "Cara Mengidentifikasi Fungsi yang menyebabkan hambatan CPU mode pengguna yang tinggi untuk aplikasi server di lingkungan produksi" di bagian referensi untuk informasi lebih lanjut.

Analisis Panjang Antrean Prosesor

"Panjang Antrean Prosesor" adalah jumlah utas dalam antrean prosesor. Tidak seperti penghitung disk, penghitung ini hanya menunjukkan utas siap, bukan utas yang berjalan. Terdapat sebuah antrean tunggal untuk waktu prosesor bahkan pada komputer yang memiliki beberapa prosesor. Oleh karena itu, jika komputer memiliki beberapa prosesor, Anda perlu membagi nilai ini dengan jumlah prosesor yang melayani beban kerja. Antrean prosesor berkelanjutan kurang dari 10 utas per prosesor biasanya dapat diterima, tergantung pada beban kerja.

Analisis ini menentukan apakah panjang antrean prosesor rata-rata melebihi jumlah prosesor. Jika demikian, maka ini dapat menunjukkan penyempitan prosesor. Gunakan analisis ini dalam korelasi dengan Analisis CPU Mode Istimewa dan Penggunaan Prosesor Berlebihan berdasarkan Proses. Antrean prosesor adalah kumpulan utas yang siap tetapi tidak dapat dijalankan oleh prosesor karena utas aktif lain saat ini sedang dijalankan. Antrian utas yang berkelanjutan atau berulang dengan jumlah utas lebih banyak daripada jumlah prosesor adalah indikasi yang baik dari kemacetan prosesor.

Anda dapat menggunakan penghitung ini bersama dengan penghitung "Prosesor\% Waktu Prosesor" untuk menentukan apakah aplikasi Anda dapat memperoleh manfaat dari lebih banyak CPU. Ada satu antrean untuk waktu pemrosesan, bahkan pada komputer multiprosesor. Oleh karena itu, dalam komputer multiprosesor, bagi nilai "Panjang Antrean Prosesor" (PQL) dengan jumlah prosesor yang melayani beban kerja

Jika CPU sangat sibuk (90 persen dan pemanfaatan yang lebih tinggi) dan rata-rata PQL secara konsisten lebih tinggi daripada jumlah prosesor, maka Anda mungkin memiliki hambatan prosesor yang dapat memperoleh manfaat dari CPU tambahan. Atau, Anda dapat mengurangi jumlah utas dan antrean di tingkat aplikasi. Ini akan menyebabkan lebih sedikit peralihan konteks, yang baik untuk mengurangi beban CPU. Alasan umum untuk PQL tinggi dengan penggunaan CPU yang rendah adalah permintaan waktu prosesor yang tiba secara acak, dan proses menuntut jumlah waktu yang tidak teratur dari prosesor. Ini berarti bahwa prosesor bukan hambatan. Sebagai gantinya, logika utas Anda yang perlu ditingkatkan.

Jika penyempitan prosesor mode pengguna dicurigai, maka pertimbangkan untuk menggunakan profiler proses untuk menganalisis fungsi yang menyebabkan konsumsi CPU yang tinggi. Lihat artikel "Cara: Mengidentifikasi Fungsi yang menyebabkan hambatan CPU mode pengguna yang tinggi untuk aplikasi server dalam lingkungan produksi" di bagian referensi untuk informasi selengkapnya.

Analisis CPU Mode Istimewa

Penghitung ini menunjukkan persentase waktu thread berjalan dalam mode istimewa. Ketika aplikasi Anda memanggil fungsi sistem operasi (misalnya untuk melakukan I/O file atau jaringan atau untuk mengalokasikan memori), fungsi sistem operasi ini dijalankan dalam mode istimewa.

CPU mode prioritas tinggi menunjukkan bahwa komputer menghabiskan terlalu banyak waktu dalam I/O sistem dibandingkan dengan pekerjaan yang sebenarnya (mode pengguna). "% Privileged Time" adalah persentase waktu yang berlalu yang dihabiskan utas proses untuk mengeksekusi kode dalam mode istimewa. Ketika layanan sistem Windows dipanggil, layanan akan sering berjalan dalam mode istimewa untuk mendapatkan akses ke data privat sistem. Data tersebut aksesnya dicegah oleh thread yang dijalankan dalam mode pengguna. Panggilan ke sistem bisa eksplisit atau implisit, seperti kesalahan halaman atau gangguan. Tidak seperti beberapa sistem operasi awal, Windows menggunakan batas proses untuk perlindungan subsistem selain perlindungan tradisional pengguna dan mode istimewa. Beberapa pekerjaan yang dilakukan oleh Windows atas nama aplikasi mungkin muncul dalam proses subsistem lainnya selain waktu istimewa dalam proses.

Analisis ini memeriksa untuk melihat apakah CPU mode istimewa mengonsumsi lebih dari 30 persen dari total CPU. Jika demikian, konsumsi CPU kemungkinan disebabkan oleh hambatan lain selain prosesor seperti jaringan, memori, atau I/O disk. Gunakan dalam korelasi dengan Waktu Interupsi % dan analisis Pengalihan Konteks Tinggi.

Analisis Pengalihan Konteks Tinggi

Peralihan konteks terjadi ketika utas prioritas yang lebih tinggi mendahului utas prioritas yang lebih rendah yang saat ini berjalan atau ketika utas prioritas tinggi memblokir. Tingkat pengalihan konteks yang tinggi dapat terjadi ketika banyak utas memiliki tingkat prioritas yang sama. Ini sering menunjukkan bahwa terlalu banyak utas yang bersaing untuk prosesor pada sistem. Jika Anda tidak melihat banyak pemanfaatan prosesor dan Anda melihat tingkat pergantian konteks yang sangat rendah, hal ini dapat menunjukkan bahwa utas diblokir.

Pengalihan konteks tinggi hanya boleh diselidiki ketika CPU mode istimewa dan CPU keseluruhan tinggi. Sebagai aturan umum, tingkat peralihan konteks kurang dari 5.000 per detik per prosesor tidak perlu dikhawatirkan. Jika tingkat peralihan konteks melebihi 15.000 per detik per prosesor, maka ada batasan.

Analisis ini memeriksa penggunaan CPU yang tinggi, CPU dalam mode hak istimewa yang tinggi, dan peralihan konteks sistem yang tinggi (lebih dari 5.000 per prosesor) per detik yang semuanya terjadi pada saat yang sama. Jika pergantian konteks yang tinggi terjadi, maka kurangi jumlah utas dan proses yang berjalan pada sistem.

Analisis Sesi Database Tinggi BizTalk

Penghitung ini memiliki dua nilai yang mungkin yaitu normal (0) atau terlampaui (1). Analisis ini memeriksa nilai 1. Jika demikian, BizTalk telah melebihi ambang jumlah sesi database yang diizinkan. Nilai ini dikontrol oleh nilai "Koneksi database per CPU" di pengaturan Pembatasan Host BizTalk.

"Koneksi database per CPU" adalah jumlah maksimum sesi database bersamaan yang diizinkan per CPU sebelum pengendalian dimulai. Sesi database diam di kumpulan sesi per host umum tidak ditambahkan ke hitungan ini, dan pemeriksaan ini dilakukan secara ketat pada jumlah sesi yang benar-benar digunakan oleh instans host. Opsi ini dinonaktifkan secara default; biasanya, pengaturan ini hanya boleh diaktifkan jika server database menjadi hambatan atau untuk server database kelas bawah di sistem BizTalk Server. Anda dapat memantau jumlah koneksi database aktif dengan menggunakan penghitung kinerja sesi database di bawah kategori objek performa BizTalk:Agen Pesan. Parameter ini hanya memengaruhi pembatasan pesan keluar. Masukkan nilai 0 untuk menonaktifkan pembatasan yang didasarkan pada jumlah sesi database. Nilai defaultnya adalah 0.

Nota

Kunci registri "MaxWorkerThreads" memengaruhi jumlah utas yang tersedia untuk BizTalk dan dapat berguna jika sebagian besar utas BizTalk yang tersedia sibuk dengan koneksi database.

Referensi

• Penghitung Kinerja Pengendalian Host

• Thread, sesi Basis Data, dan pembatasan

• Parameter Konfigurasi yang Memengaruhi Performa Adapter

• Cara Mengubah Pengaturan Pembatasan Kecepatan Host Bawaan

Analisis Database Berukuran Besar BizTalk

Penghitung ini merujuk pada jumlah pesan dalam antrian basis data yang telah diterbitkan oleh proses ini. Nilai ini diukur berdasarkan jumlah item dalam tabel antrean untuk semua host serta jumlah item dalam tabel penampung dan tabel pelacakan. Antrean mencakup antrean kerja, antrean status, dan antrean yang ditangguhkan. Jika sebuah proses menerbitkan pesan ke beberapa antrean, maka penghitung ini mencerminkan rata-rata tertimbang dari semua antrean tersebut.

Jika host dimulai ulang, statistik yang disimpan dalam memori akan hilang. Karena beberapa beban tambahan terlibat, BizTalk Server akan melanjutkan pengumpulan statistik hanya ketika setidaknya ada 100 publikasi, dengan 5 persen dari total publikasi berada dalam proses host yang telah dimulai ulang.

Penghitung ini akan diatur ke nilai 1 jika salah satu kondisi yang tercantum untuk jumlah pesan dalam ambang batas database terjadi. Ambang batas ini didokumentasikan dalam topik Cara Mengubah Pengaturan Laju Pembatasan Host Default yang dirujuk di bawah ini. Secara default jumlah pesan host dalam ambang pembatasan database diatur ke nilai 50.000, yang akan memicu kondisi pembatasan dalam keadaan berikut:

• Jumlah total pesan yang diterbitkan oleh instans host ke antrean kerja, status, dan yang ditangguhkan dari host yang berlangganan melebihi 50.000.

• Jumlah pesan dalam tabel spool atau tabel pelacakan melebihi 500.000 pesan.

  Karena pesan yang ditangguhkan disertakan dalam jumlah pesan dalam perhitungan database, pembatasan penerbitan pesan dapat terjadi bahkan jika server BizTalk mengalami pemuatan rendah atau tidak ada beban.

  Analisis ini memeriksa nilai 1. Jika ini terjadi, maka pertimbangkan tindakan yang akan mengurangi jumlah pesan dalam database. Misalnya, pastikan tugas BizTalk SQL Server berjalan lancar tanpa kesalahan dan gunakan fitur Hub Grup di konsol Administrasi BizTalk untuk menentukan apakah penumpukan pesan disebabkan oleh sejumlah besar pesan yang ditahan.

Referensi

• Pesan yang Ditangguhkan Disertakan dalam Hitungan Pesan di Batas Pembatasan Basis Data

• Cara Mengubah Pengaturan Pembatasan Kecepatan Host Bawaan

• Penghitung Kinerja Pengendalian Host

Analisis Jumlah Pesan bizTalk High In-Process

Pengaturan "Pesan dalam proses per CPU" di Pengaturan Pembatasan Host adalah jumlah maksimum pesan yang dikirim ke End Point Manager (EPM) atau XLANG yang belum diproses. Jumlah ini tidak menyertakan pesan yang sudah diambil dari database tetapi masih menunggu untuk dikirim dalam antrean memori. Anda dapat memantau jumlah pesan yang sedang diproses dengan menggunakan penghitung kinerja jumlah pesan dalam proses di bawah kategori objek performa BizTalk:Agen Pesan. Parameter ini memberikan petunjuk pada mekanisme pembatasan saat mempertimbangkan kondisi pembatasan. Ambang batas aktual tunduk pada penyesuaian otomatis. Anda dapat memverifikasi ambang batas aktual dengan memantau penghitung kinerja jumlah pesan dalam proses.

Parameter ini dapat diatur ke nilai yang lebih kecil untuk skenario pesan besar, di mana ukuran pesan rata-rata tinggi, atau pemrosesan pesan mungkin memerlukan sejumlah besar pesan. Hal ini akan terlihat jika skenario mengalami pembatasan berbasis memori terlalu sering dan jika ambang memori disesuaikan secara otomatis dengan nilai yang sangat rendah. Perilaku tersebut akan menunjukkan bahwa transportasi keluar harus memproses lebih sedikit pesan secara bersamaan untuk menghindari penggunaan memori yang berlebihan. Selain itu, untuk skenario di mana adaptor lebih efisien saat memproses beberapa pesan sekaligus (misalnya, saat mengirim ke server yang membatasi koneksi bersamaan), parameter ini mungkin disetel ke nilai yang lebih rendah daripada default.

Analisis ini memeriksa penghitung "Jumlah Pesan In-Process yang Tinggi" untuk menentukan apakah pembatasan semacam ini sedang terjadi. Jika demikian, pertimbangkan untuk menyesuaikan setelan "In-Process pesan per CPU". Parameter ini hanya memengaruhi pembatasan pesan keluar. Masukkan nilai 0 dalam pengaturan "In-Process pesan per CPU" untuk menonaktifkan pembatasan berdasarkan jumlah pesan yang sedang diproses per CPU. Nilai default untuk pengaturan "In-Process pesan per CPU" adalah 1.000. Perhatikan bahwa memodifikasi nilai ini juga dapat berdampak pada latensi pesan yang rendah dan/atau efisiensi sumber daya BizTalk.

Referensi

• Cara Mengubah Pengaturan Pembatasan Kecepatan Host Bawaan

• Penghitung Kinerja Pengendalian Host

Analisis Tingkat Pengiriman Pesan Tinggi BizTalk

Untuk pesan keluar (terkirim), BizTalk Server membatasi pengiriman pesan jika laju masuk pengiriman pesan untuk instans host melebihi laju keluar * faktor overdrive (persen) yang telah ditentukan. Parameter faktor kecepatan overdrive (prosentase) dapat dikonfigurasi pada kotak dialog Pengaturan Pembatasan Pemrosesan Pesan. Pembatasan berbasis laju untuk pesan keluar dilakukan terutama dengan memicu penundaan sebelum mengeluarkan pesan dari antrean dalam memori dan mengirimkan pesan ke pengelola titik akhir (EPM) atau mesin orkestrasi untuk diproses. Tidak ada tindakan lain yang diambil untuk mencapai pembatasan berbasis tarif untuk pesan keluar.

Pembatasan aliran keluar dapat menyebabkan pengiriman pesan tertunda dan pesan dapat menumpuk dalam antrean memori serta menyebabkan utas de-antrean diblokir hingga kondisi pembatasan teratasi. Saat utas dequeue diblokir, tidak ada pesan tambahan yang ditarik dari MessageBox ke dalam antrian memori untuk pengiriman keluar.

Analisis ini memeriksa apakah ada nilai 1 pada penghitung untuk Tingkat Pengiriman Pesan yang Tinggi. Tingkat pengiriman pesan yang tinggi dapat disebabkan oleh kompleksitas pemrosesan tinggi, adaptor keluar yang lambat, atau kekurangan sumber daya sistem sesaat.

Referensi

• Penghitung Kinerja Pengendalian Host

• Cara BizTalk Server Menerapkan Pembatasan Host

• Cara Mengubah Pengaturan Pembatasan Kecepatan Host Bawaan

Analisis terhadap Memori Proses yang Tinggi pada BizTalk

Pengaturan ambang batas penggunaan BizTalk Process Memory adalah persentase memori yang digunakan dibandingkan dengan jumlah ukuran set kerja dan total memori virtual yang tersedia untuk proses jika nilai dari 1 hingga 100 dimasukkan. Secara default, pengaturan pembatasan Penggunaan Memori Proses BizTalk adalah 25. Ketika nilai persentase ditentukan, ambang batas memori proses dihitung ulang secara berkala. Jika pengguna menentukan nilai persentase, nilai tersebut dihitung berdasarkan memori yang tersedia untuk diterapkan dan penggunaan Memori Proses saat ini.

Analisis ini memeriksa nilai 1 di penghitung Memori Proses Tinggi. Jika ini terjadi, coba tentukan penyebab peningkatan memori dengan menggunakan Debug Diag (lihat referensi dalam analisis Deteksi Kebocoran Memori). Perhatikan bahwa normal bagi proses untuk mengonsumsi sebagian besar memori selama startup dan ini awalnya mungkin muncul sebagai kebocoran memori, tetapi kebocoran memori yang sebenarnya terjadi ketika proses gagal melepaskan memori yang tidak lagi dibutuhkan, sehingga mengurangi jumlah memori yang tersedia dari waktu ke waktu. Lihat referensi "Cara Mengambil Cadangan Memori dari Proses yang Membocorkan Memori" di bawah ini dan/atau analisis "Deteksi Kebocoran Memori" di PAL untuk informasi selengkapnya tentang cara menganalisis kebocoran memori proses secara umum di BizTalk.

Pengendalian memori proses yang tinggi dapat terjadi jika batch yang akan dipublikasikan membutuhkan memori yang tinggi, atau terlalu banyak thread memproses pesan. Jika sistem tampaknya terlalu membatasi, pertimbangkan untuk meningkatkan nilai yang terkait dengan ambang penggunaan memori proses untuk host dan pastikan bahwa instans host tidak menghasilkan kesalahan "kehabisan memori". Jika kesalahan "kehabisan memori" dilaporkan dengan meningkatkan ambang batas penggunaan memori untuk proses, pertimbangkan untuk mengurangi nilai ambang batas ukuran antrean pesan internal dan pesan dalam proses per CPU. Strategi ini sangat relevan dalam skenario pemrosesan pesan besar. Selain itu, nilai ini harus diatur ke nilai rendah untuk skenario yang memiliki persyaratan memori besar per pesan. Mengatur nilai rendah akan memicu pembatasan lebih awal dan mencegah lonjakan memori dalam proses.

Jika server BizTalk Anda secara teratur kehabisan memori virtual, pertimbangkan BizTalk Server 64-bit. Setiap proses pada server 64-bit dapat mengatasi memori virtual hingga 4 TB versus 2 GB dalam 32-bit. Secara umum, BizTalk 64-bit dan SQL Server 64-bit sangat disarankan. Lihat referensi "Dukungan BizTalk Server 64-bit" untuk informasi selengkapnya.

Referensi

• Cara BizTalk Server Menerapkan Pembatasan Host

• Cara Mengubah Pengaturan Penjagaan Host Default

• Cara Mengambil Dump Memori dari Proses yang Mengalami Kebocoran Memori

• Dukungan BizTalk Server 64-bit

Analisis Penggunaan Memori Sistem Tinggi di BizTalk

Pengaturan ambang batas pembatasan penggunaan Memori Fisik BizTalk adalah persentase konsumsi memori dibandingkan dengan jumlah total memori fisik yang tersedia jika nilai dari 1 hingga 100 dimasukkan. Pengaturan ini juga dapat menjadi jumlah total memori fisik yang tersedia dalam megabyte jika nilai yang lebih besar dari 100 dimasukkan. Masukkan nilai 0 untuk menonaktifkan pembatasan berdasarkan penggunaan memori fisik. Nilai defaultnya adalah 0.

Analisis ini memeriksa nilai 1 di penghitung Memori Sistem Tinggi. Karena ini mengukur total memori sistem, kondisi pembatasan dapat dipicu jika proses non-BizTalk Server mengkonsumsi sejumlah besar memori sistem. Oleh karena itu jika ini terjadi, pendekatan terbaik adalah mengidentifikasi proses mana yang menggunakan memori fisik paling banyak dan/atau menambahkan memori fisik tambahan ke server. Selain itu, pertimbangkan untuk mengurangi beban dengan mengurangi ukuran default kumpulan utas EPM, dan/atau ukuran batch adaptor. Untuk informasi selengkapnya, lihat analisis Deteksi Kebocoran Memori di PAL.

Referensi

• Penghitung Kinerja Pengendalian Host

• Cara Mengubah Pengaturan Pembatasan Kecepatan Host Default

• Cara BizTalk Server Menerapkan Pembatasan Host

Analisis Jumlah Utas Tinggi pada BizTalk

"Thread Per CPU" adalah jumlah total utas dalam proses host termasuk utas yang digunakan oleh adaptor. Jika ambang batas ini terlampaui, BizTalk Server akan mencoba mengurangi ukuran kumpulan utas EPM dan kumpulan utas agen pesan. Pembatasan berbasis utas harus diaktifkan dalam skenario di mana beban kerja yang tinggi dapat menyebabkan pembuatan sejumlah besar utas. Parameter ini memengaruhi pengaturan pembatasan lalu lintas masuk dan keluar. Pembatasan berbasis utas dinonaktifkan dalam kondisi default.

Nota

Nilai yang ditentukan pengguna digunakan sebagai pedoman, dan host dapat secara dinamis menyetel nilai ambang batas ini berdasarkan pola penggunaan memori dan persyaratan utas proses.

Analisis ini memeriksa nilai 1 di penghitung Thread Tinggi. Pertimbangkan untuk menyesuaikan ukuran berbagai kumpulan utas agar sistem tidak membuat terlalu banyak utas. Analisis ini dapat dikorelasikan dengan Pengalihan Konteks per Detik untuk menentukan apakah sistem operasi jenuh karena terlalu banyak utasan, tetapi dalam kebanyakan kasus jumlah utasan yang tinggi menyebabkan lebih banyak persaingan pada basis data backend dibandingkan dengan di server BizTalk. Untuk informasi selengkapnya tentang memodifikasi ukuran kumpulan utas, lihat Cara Mengubah Pengaturan Pembatasan Host Default dalam referensi.

Referensi

• Penghitung Kinerja Pengendalian Host

• Cara BizTalk Server Menerapkan Pembatasan Host

• Cara Mengubah Pengaturan Pengendalian Host Default

• Parameter Konfigurasi yang Memengaruhi Performa Adapter

• Thread, sesi basis data, dan pembatasan

  Analisis Latensi Masuk BizTalk Rata-rata latensi dalam milidetik dari ketika mesin olah pesan menerima dokumen dari adaptor hingga saat dokumen tersebut diterbitkan ke kotak pesan. Mengurangi latensi penting bagi beberapa pengguna BizTalk, oleh karena itu melacak berapa banyak waktu yang dihabiskan dokumen dalam adaptor masuk penting.

  Berikut adalah bagan yang menunjukkan bagaimana latensi diukur.

1	2	3	4	5	6
Adaptor menerima pesan dan mengirimkannya ke mesin. Pekerjaan yang dilakukan di dalam adaptor sebelum pesan diberikan kepada mesin tidak terlihat dalam penghitung kinerja ini.	Mesin menerima pesan dari adaptor, menjalankan alur penerimaan, peta, evaluasi langganan, pesan persisten di DB.	Orkestrasi atau port Solicit-Response berjalan dan menghasilkan pesan respons.	Pesan respons dihapus dari antrian dalam mesin olahpesan, jalankan alur kirim, pemetaaan.	Mesin olahpesan memberikan pesan respons ke adaptor.	Adaptor menginformasikan pesan mesin sudah selesai.
	Saya
	RR	RR	RR
			O	O	O
				OA	OA

I = Latensi Masuk

RR = Latensi Permintaan Respons

O = Latensi ke Luar

OA = Latensi Adaptor Keluar

Dengan asumsi lingkungan latensi rendah, analisis ini memeriksa apakah dokumen menghabiskan lebih dari 5 detik dalam adaptor masuk. Ini dapat menunjukkan penundaan pemrosesan dalam pengangkutan pesan melalui adaptor masuk dalam instans host ini. Jika beberapa adaptor masuk ada dalam instans host ini, maka pertimbangkan untuk memisahkannya ke host mereka sendiri untuk menentukan adaptor masuk mana yang memiliki latensi tinggi.

Referensi

• Mengoptimalkan Performa Database

• Permintaan/Respons Pesan

• Mengidentifikasi Hambatan di Tingkat BizTalk

Analisis Status Pembatasan Pengiriman Pesan BizTalk

Status pembatasan pengiriman pesan BizTalk adalah salah satu indikator utama pembatasan. Ini adalah indikator yang menunjukkan apakah sistem membatasi pengiriman pesan (memengaruhi pemrosesan pesan XLANG dan pengiriman keluar). Kondisi pembatasan diindikasikan oleh nilai numerik penghitung. Berikut adalah daftar nilai dan maknanya masing-masing:

Kondisi penurunan kecepatan	Deskripsi
0	Tanpa pembatasan
1	Pembatasan karena tingkat pengiriman pesan yang tidak seimbang (laju input melebihi laju output)
3	Pembatasan karena jumlah pesan dalam proses yang tinggi
4	Pembatasan akibat tekanan pada memori proses
5	Pengendalian performa karena tekanan memori sistem
9	Pengendalian laju karena jumlah utas yang tinggi
10	Pembatasan karena perubahan oleh pengguna pada pengiriman

Analisis ini memeriksa masing-masing nilai ini dan memiliki pemberitahuan khusus untuk masing-masing nilai tersebut.

Referensi

• Penghitung Kinerja Pengendalian Host

• Cara BizTalk Server Menerapkan Pembatasan Host

Analisis Koneksi Gagal pada Database BizTalk MessageBox

Penghitung kinerja ini adalah jumlah koneksi database yang dicoba yang gagal sejak instans host dimulai. Jika layanan SQL Server yang menghosting database BizTalk menjadi tidak tersedia karena alasan apa pun, kluster database mentransfer sumber daya dari komputer aktif ke komputer pasif. Selama proses failover ini, instans layanan BizTalk Server mengalami kegagalan koneksi database dan secara otomatis menghidupkan ulang untuk terhubung kembali ke database. Komputer database yang berfungsi (sebelumnya komputer pasif) mulai memproses koneksi database setelah mengasumsikan sumber daya selama failover.

Kesalahan DBNetLib (Pustaka Jaringan Database) terjadi ketika runtime BizTalk Server tidak dapat berkomunikasi dengan MessageBox atau database manajemen. Ketika ini terjadi, instans runtime BizTalk Server yang menangkap pengecualian dimatikan dan kemudian berputar setiap menit untuk memeriksa apakah database tersedia. Lihat bagian referensi untuk informasi selengkapnya tentang topik ini.

Ketika klien memulai koneksi soket TCP/IP ke server, klien biasanya terhubung ke port tertentu di server dan meminta server merespons klien melalui port sementara, atau berumur pendek, TCP atau UDP. Pada Windows Server 2003 dan Windows XP, rentang default port ephemeral yang digunakan oleh aplikasi klien adalah dari 1025 hingga 5000. Dalam kondisi tertentu, ada kemungkinan bahwa port yang tersedia dalam rentang default akan habis. Lihat bagian referensi untuk informasi selengkapnya tentang topik ini.

Analisis ini memeriksa setiap kemunculan kegagalan koneksi database. Kegagalan koneksi database sangat penting karena BizTalk tidak dapat berfungsi tanpa database. Jika penyebab kegagalan koneksi database tidak diketahui, pertimbangkan referensi yang tercantum di bawah ini dan/atau hubungi Dukungan Microsoft untuk menentukan sifat kegagalan konektivitas.

Referensi

• DatabaseScaled-Out

• Menghindari Pengecualian DBNETLIB

• Menghindari Kelelahan Port TCP/IP

Analisis Status Pembatasan Penerbitan Pesan BizTalk

Status pengaturan pembatasan penerbitan pesan BizTalk adalah salah satu indikator utama pembatasan. Ini adalah bendera yang menunjukkan apakah sistem membatasi penerbitan pesan (memengaruhi pemrosesan pesan XLANG dan transportasi masuk). Kondisi pembatasan ditunjukkan oleh nilai numerik penghitung. Berikut adalah daftar nilai dan maknanya masing-masing:

Kondisi penurunan kecepatan	Deskripsi
0	Tanpa pembatasan
2	Pembatasan karena tingkat penerbitan pesan yang tidak seimbang (laju input melebihi laju output)
4	Pembatasan akibat tekanan pada memori proses
5	Pengendalian performa karena tekanan memori sistem
6	Pembatasan karena pertumbuhan database
8	Pengendalian kecepatan karena jumlah sesi yang tinggi
9	Pengendalian laju karena jumlah utas yang tinggi
11	Pembatasan kecepatan karena pengguna memotong proses penerbitan

Analisis ini memeriksa masing-masing nilai ini dan memiliki pemberitahuan khusus untuk masing-masing nilai tersebut.

Referensi

• Penghitung Kinerja Pengendalian Host

• Cara BizTalk Server Menerapkan Pembatasan Host

BizTalk Orchestrations Resident dalam Memori

Jumlah instans orkestrasi yang saat ini dihosting oleh instans host. Sementara lonjakan atau semburan orkestrasi yang berada dalam memori mungkin dianggap normal, tren yang meningkat dapat menunjukkan penumpukan orkestrasi di dalam memori. Tren yang meningkat dari waktu ke waktu dapat terjadi ketika BizTalk tidak dapat mendehidrasi pesan/instans orkestrasi. Cobalah untuk menghubungkan penghitung ini dengan "XLANG/s Orkestrasi(?)\Orkestrasi yang dapat didehidrasi" di mana tanda tanya (?) menunjukkan instans penghitung yang sama dengan penghitung ini.

Jika sejumlah besar orkestrasi berada dalam memori dan jika sejumlah kecil orkestrasi yang dapat mengalami dehidrasi, maka orkestrasi Anda kemungkinan tidak aktif dalam memori dan dapat menyebabkan masalah kebocoran memori. Gunakan analisis ini dalam kaitannya dengan "\XLANG/s Orchestrations(*)\Idle orkestrasi" jika ada. Peningkatan tren dalam BizTalk Idle Orchestrations merupakan indikator yang lebih baik dari kebocoran memori karena ketidakmampuan untuk menghilangkan dehidrasi instans orkestrasi.

Analisis ini memeriksa tren yang meningkat dalam orkestrasi yang tinggal dalam memori dan jika lebih dari 50% orkestrasi yang berada dalam memori tidak dapat didehidrasi.

Referensi

• Penghitung Kinerja Mesin Orkestrasi

• Dehidrasi dan Rehidrasi Orkestrasi

Analisis Byte Privat BizTalk

Ini adalah megabyte memori privat yang dialokasikan untuk instans host dan sebanding dengan penghitung kinerja "\Process(*)\Private Bytes". Byte Pribadi adalah ukuran saat ini, dalam byte, dari memori yang telah dialokasikan oleh suatu proses yang tidak dapat dibagikan dengan proses lain. Analisis ini menentukan apakah salah satu instans host mengonsumsi memori sistem dalam ukuran besar dan apakah instans host meningkat dalam konsumsi memori dari waktu ke waktu. Instans host yang mengkonsumsi sebagian besar memori baik-baik saja selama mengembalikan memori ke sistem. Cari peningkatan tren dalam bagan. Tren yang meningkat dalam jangka waktu yang lama dapat menunjukkan kebocoran memori.

Analisis ini memeriksa tren peningkatan 10 MB per jam. Gunakan analisis ini dalam korelasi dengan analisis Memori yang Tersedia dan analisis Kebocoran Memori. Selain itu, perlu diingat bahwa instans host yang baru dimulai awalnya mungkin terlihat seperti kebocoran memori padahal sebenarnya itu adalah perilaku memulai yang normal. Kebocoran memori adalah ketika proses terus mengonsumsi memori dan tidak melepaskan memori dalam jangka waktu yang lama. Jika Anda mencurigai kondisi kebocoran memori, baca artikel "Pertumbuhan Memori di Olahpesan BizTalk" yang dirujuk di bawah ini. Jika tidak, instal dan gunakan alat Debug Diag. Untuk informasi selengkapnya tentang Alat Diagnosis Debug, lihat bagian referensi.

Referensi

• Alat Diagnostik Debug

• Pertumbuhan Memori dalam Olahpesan BizTalk

Analisis BizTalk Virtual Byte

Ini adalah megabyte yang dicadangkan untuk memori virtual pada instance host. Analisis ini menentukan apakah salah satu instans host menggunakan sejumlah besar memori sistem dan apakah instans host meningkat dalam konsumsi memori dari waktu ke waktu. Instans host yang mengkonsumsi sebagian besar memori tidak masalah selama mengembalikan memori ke sistem. Cari peningkatan tren dalam bagan. Tren yang meningkat dalam jangka waktu yang lama dapat menunjukkan kebocoran memori.

Analisis ini memeriksa tren kenaikan 10 MB per jam pada byte virtual. Gunakan analisis ini dalam korelasi dengan analisis Memori yang Tersedia dan analisis Kebocoran Memori. Selain itu, perlu diingat bahwa instans host yang baru dimulai awalnya mungkin terlihat seperti kebocoran memori padahal sebenarnya itu adalah perilaku memulai yang normal. Kebocoran memori adalah ketika proses terus mengonsumsi memori dan tidak melepaskan memori dalam jangka waktu yang lama. Jika Anda mencurigai kondisi kebocoran memori, baca artikel "Pertumbuhan Memori di Olahpesan BizTalk" di bawah ini. Jika tidak, instal dan gunakan alat Debug Diag. Untuk informasi selengkapnya tentang Alat Diagnosis Debug, lihat bagian referensi.

Referensi

• Alat Diagnostik Debug

• Pertumbuhan Memori dalam Olahpesan BizTalk

Analisis Pembatasan Sesi Basis Data untuk Agen Pesan BizTalk

Ini adalah jumlah koneksi database terbuka ke MessageBox dibandingkan dengan pengaturan pembatasan BizTalk masing-masing. "Koneksi database per CPU" adalah jumlah maksimum sesi database bersamaan yang diizinkan per CPU sebelum pengendalian dimulai. Sesi database diam di kumpulan sesi per host umum tidak ditambahkan ke hitungan ini, dan pemeriksaan ini dilakukan secara ketat pada jumlah sesi yang benar-benar digunakan oleh instans host. Opsi ini dinonaktifkan secara default; biasanya pengaturan ini hanya boleh diaktifkan jika server database menjadi hambatan dalam sistem BizTalk Server. Anda dapat memantau jumlah koneksi database aktif dengan menggunakan penghitung kinerja sesi database di bawah kategori objek performa BizTalk:Agen Pesan. Parameter ini hanya memengaruhi pembatasan pesan keluar. Masukkan nilai 0 untuk menonaktifkan pembatasan yang didasarkan pada jumlah sesi database. Nilai defaultnya adalah 0.

Kunci registri MaxWorkerThreads berdampak pada jumlah utas yang tersedia untuk BizTalk dan dapat membantu ketika sebagian besar utas BizTalk sibuk dengan koneksi database. Analisis ini memeriksa apakah jumlah koneksi basis data terbuka ke MessageBox melebihi 80 persen dari pengaturan Pemadatan Sesi Basis Data, yang menunjukkan kemungkinan besar mengalami kondisi pembatasan.

Referensi

• Penghitung Kinerja Pengendalian Host

• Parameter Konfigurasi yang Memengaruhi Performa Adapter

• Thread, sesi basis data, dan pembatasan

Analisis Ambang Batas Pembatasan Sesi Basis Data Agen Pesan BizTalk

Ini adalah ambang batas saat ini untuk jumlah koneksi database terbuka ke MessageBox. "Koneksi database per CPU" adalah jumlah maksimum sesi database bersamaan yang diizinkan per CPU sebelum pengendalian dimulai. Sesi database diam di kumpulan sesi per host umum tidak ditambahkan ke hitungan ini, dan pemeriksaan ini dilakukan secara ketat pada jumlah sesi yang benar-benar digunakan oleh instans host. Opsi ini dinonaktifkan secara default; biasanya pengaturan ini hanya boleh diaktifkan jika server database menjadi hambatan dalam sistem BizTalk Server. Anda dapat memantau jumlah koneksi database aktif dengan menggunakan penghitung kinerja sesi database di bawah kategori objek performa BizTalk:Agen Pesan. Parameter ini hanya memengaruhi pembatasan pesan keluar. Masukkan nilai 0 untuk menonaktifkan pembatasan yang didasarkan pada jumlah sesi database. Nilai defaultnya adalah 0.

Kunci registri MaxWorkerThreads memiliki pengaruh pada jumlah utas yang tersedia untuk BizTalk dan dapat membantu dalam kasus di mana sebagian besar utas BizTalk sibuk dengan koneksi database. Analisis ini memeriksa nilai ini untuk melihat apakah nilai tersebut telah dimodifikasi dari pengaturan defaultnya. Secara default, pengaturan ini adalah 0, yang berarti pembatasan pada sesi database dinonaktifkan.

Referensi

• Penghitung Kinerja Pengendalian Host

• Parameter Konfigurasi yang Memengaruhi Performa Adapter

• Thread, sesi basis data, dan pembatasan

Analisis Pengendalian Jumlah Pesan Dalam Proses Agen Pesan BizTalk

Ini adalah jumlah pesan bersamaan yang diproses oleh kelas layanan. Pengaturan "Pesan dalam proses per CPU" di Pengaturan Pembatasan Host adalah jumlah maksimum pesan yang dikirim ke End Point Manager (EPM) atau XLANG yang belum diproses. Ini tidak termasuk pesan yang diambil dari database tetapi masih menunggu pengiriman dalam antrean memori. Anda dapat memantau jumlah pesan dalam proses dengan menggunakan penghitung kinerja "Jumlah pesan dalam proses" di bawah kategori objek kinerja BizTalk:Agen Pesan. Parameter ini memberikan petunjuk pada mekanisme pembatasan untuk mempertimbangkan kondisi-kondisi pembatasan. Ambang batas aktual tunduk pada penyesuaian otomatis. Anda dapat memverifikasi ambang batas aktual dengan memantau penghitung kinerja jumlah pesan yang sedang diproses.

Untuk skenario pesan besar (di mana ukuran pesan rata-rata tinggi, atau pemrosesan pesan mungkin memerlukan sejumlah besar pesan), parameter ini dapat diatur ke nilai yang lebih kecil. Skenario pesan besar ditunjukkan jika pembatasan berbasis memori terjadi terlalu sering dan jika ambang memori disesuaikan secara otomatis dengan nilai yang sangat rendah. Perilaku tersebut akan menunjukkan bahwa transportasi keluar harus memproses lebih sedikit pesan secara bersamaan untuk menghindari penggunaan memori yang berlebihan. Selain itu, untuk skenario di mana adaptor lebih efisien saat memproses beberapa pesan sekaligus (misalnya, saat mengirim ke server yang membatasi koneksi bersamaan), parameter ini mungkin disetel ke nilai yang lebih rendah daripada default. Analisis ini memeriksa penghitung Hitungan Pesan Tinggi In-Process untuk menentukan apakah jumlah pesan tersebut melebihi 80 persen dari pengaturan pembatasannya dengan nama yang sama, yang mengindikasikan bahwa kemungkinan terjadi kondisi pembatasan.

Referensi

• Penghitung Kinerja Pengendalian Host

• Cara Mengubah Pengaturan Pengendalian Host Default

Analisis Ambang Batas Pembatasan Jumlah Pesan Dalam Proses oleh Agen Pesan di BizTalk

Ini adalah ambang batas saat ini untuk jumlah pesan bersamaan yang diproses oleh kelas layanan. Pengaturan "Pesan dalam proses per CPU" di Pengaturan Pembatasan Host adalah jumlah maksimum pesan yang dikirim ke End Point Manager (EPM) atau XLANG yang belum diproses. Ini tidak termasuk pesan yang diambil dari database tetapi masih menunggu pengiriman dalam antrean memori. Anda dapat memantau jumlah pesan dalam proses dengan menggunakan penghitung kinerja "Jumlah pesan dalam proses" di bawah kategori objek kinerja BizTalk:Agen Pesan. Parameter ini memberikan petunjuk pada mekanisme pembatasan untuk mempertimbangkan kondisi-kondisi pembatasan. Ambang batas aktual tunduk pada penyesuaian otomatis. Anda dapat memverifikasi ambang batas aktual dengan memantau penghitung kinerja jumlah pesan yang sedang diproses.

Untuk skenario pesan besar (di mana ukuran pesan rata-rata tinggi, atau pemrosesan pesan mungkin memerlukan sejumlah besar pesan), parameter ini dapat diatur ke nilai yang lebih kecil. Skenario pesan besar ditunjukkan jika pembatasan berbasis memori terjadi terlalu sering dan jika ambang memori disesuaikan secara otomatis dengan nilai yang sangat rendah. Perilaku tersebut akan menunjukkan bahwa transportasi keluar harus memproses lebih sedikit pesan secara bersamaan untuk menghindari penggunaan memori yang berlebihan. Selain itu, untuk skenario di mana adaptor lebih efisien saat memproses beberapa pesan sekaligus (misalnya, saat mengirim ke server yang membatasi koneksi bersamaan), parameter ini mungkin disetel ke nilai yang lebih rendah daripada default. Analisis ini memeriksa ambang batas pembatasan untuk penghitungan pesan In-Process yang tinggi dengan nilai non-default.

Referensi

• Penghitung Kinerja Pengendalian Host

• Cara Mengubah Pengaturan Pengendalian Host Default

Analisis Pengaturan Pembatasan Penggunaan Memori Proses Agen Pesan BizTalk (MB)

Ini adalah penggunaan memori proses saat ini (MB). Pembatasan memori proses BizTalk dapat terjadi jika batch yang akan diterbitkan memiliki persyaratan memori yang curam, atau jika terlalu banyak utas yang memproses pesan. Jika sistem tampaknya terlalu membatasi, pertimbangkan untuk meningkatkan nilai yang terkait dengan ambang penggunaan memori proses untuk host dan pastikan bahwa instans host tidak menghasilkan kesalahan "kehabisan memori". Jika kesalahan "kehabisan memori" terjadi akibat peningkatan ambang batas penggunaan memori proses, maka pertimbangkan untuk mengurangi nilai untuk ukuran antrean pesan internal dan pesan dalam proses per CPU. Strategi ini sangat relevan dalam skenario pemrosesan pesan besar.

Jika server BizTalk Anda secara teratur kehabisan memori virtual, pertimbangkan BizTalk Server 64-bit. Setiap Proses pada server 64-bit dapat mengatasi memori virtual hingga 4 TB versus 2 GB dalam 32-bit. Secara umum, BizTalk 64-bit dan SQL Server 64-bit sangat disarankan. Lihat referensi "Dukungan BizTalk Server 64-bit" untuk informasi selengkapnya. Analisis ini memeriksa apakah penggunaan memori proses lebih besar dari 80 persen dari ambang pembatasan masing-masing dengan nama yang sama. Secara default, pengaturan pembatasan Penggunaan Memori Proses BizTalk adalah 25 persen dari memori virtual yang tersedia untuk proses. Sakelar /3GB tidak berpengaruh pada pengaturan ini.

Referensi

• Cara BizTalk Server Menerapkan Pembatasan Host

• Cara Mengubah Pengaturan Pengendalian Host Default

• Cara Mengambil Dump Memori dari Proses yang Mengalami Kebocoran Memori

• Dukungan BizTalk Server 64-bit

BizTalk: Analisis Ambang Batas Penggunaan Memori Proses Agen Pesan (MB)

Ini adalah ambang batas saat ini untuk penggunaan memori proses saat ini (MB). Ambang batas dapat disesuaikan secara dinamis tergantung pada jumlah memori aktual yang tersedia untuk proses ini dan pola konsumsi memorinya. Pembatasan memori proses BizTalk dapat terjadi jika batch yang akan diterbitkan memiliki persyaratan memori yang curam, atau jika terlalu banyak utas yang memproses pesan. Jika sistem tampaknya terlalu membatasi, pertimbangkan untuk meningkatkan nilai yang terkait dengan ambang penggunaan memori proses untuk host dan pastikan bahwa instans host tidak menghasilkan kesalahan "kehabisan memori". Jika terjadi kesalahan "kehabisan memori" karena peningkatan ambang batas penggunaan memori proses, maka pertimbangkan untuk mengurangi nilai ukuran antrean pesan internal dan batas pesan dalam proses per CPU. Strategi ini sangat relevan dalam skenario pemrosesan pesan besar.

Jika server BizTalk Anda secara teratur kehabisan memori virtual, pertimbangkan BizTalk Server 64-bit. Setiap Proses pada server 64-bit dapat mengatasi memori virtual hingga 4 TB versus 2 GB dalam 32-bit. Secara umum, BizTalk 64-bit dan SQL Server 64-bit sangat disarankan. Lihat referensi "Dukungan BizTalk Server 64-bit" untuk informasi selengkapnya. Analisis ini memeriksa apakah pembatasan memori proses diatur ke nilai bukan bawaan.

Referensi

• Cara BizTalk Server Menerapkan Pembatasan Host

• Cara Mengubah Pengaturan Pengendalian Host Default

• Cara Mengambil Dump Memori dari Proses yang Mengalami Kebocoran Memori

• Dukungan BizTalk Server 64-bit