BizTalk Server كيفية استكشاف أخطاء وإصلاحها تسرب لذاكرة أو استثناء نفاد الذاكرة في عملية

ينطبق على: BizTalk Server Branch 2010BizTalk Server Developer 2010BizTalk Server Enterprise 2010

ملخص


تسرب الذاكرة قضية مشتركة. قد تضطر لإعادة العديد من الخطوات للبحث عن السبب المحدد لتسرب لذاكرة أو استثناء خارج ذاكرة (أوم) في Microsoft BizTalk Server. تتناول هذه المقالة الأمور الهامة في الاعتبار عند تقييم استخدام الذاكرة والمسائل المتعلقة بالذاكرة. وتشمل هذه الاعتبارات ما يلي:
  • ذاكرة الوصول العشوائي الفعلية
  • معالجة الرسائل الكبيرة
  • استخدام رمز التبديل /3GB
  • استخدام مكونات مخصصة
  • أي إصدار من Microsoft.NET Framework يقوم النظام بتشغيله
  • عدد المعالجات

مقدمة


توضح هذه المقالة كيفية استكشاف أخطاء وإصلاحها تسرب لذاكرة أو استثناء نفاد الذاكرة في عملية BizTalk Server من Microsoft BizTalk Server.

مزيد من المعلومات


قد تواجه عملية خادم BizTalk تسرب لذاكرة عند استخدام الذاكرة في إدارة مهام Windows Microsoft يستهلك أكثر من 50 في المائة من ذاكرة الوصول العشوائي الفعلية. يؤدي استثناء خارج الذاكرة تسرب لذاكرة عند زيادة استخدام الذاكرة حتى يتم تشغيل العملية من ذاكرة النظام أو حتى توقف العملية يعمل.

عند حدوث هذه المشكلة، يتم تسجيل رسالة تحذير تشبه الرسالة التالية في سجل الأحداث:

اعتبارات هامة

استخدام ذاكرة الوصول العشوائي والذاكرة الفعلية

لأنه قد يكون السلوك المتوقع لعملية لاستخدام حوالي نصف الذاكرة RAM الفعلية، استخدم استخدام الذاكرة كمبدأ توجيهي. على سبيل المثال، إذا كان خادم BizTalk 4 غيغابايت (GB) من ذاكرة الوصول العشوائي، وعملية BizTalk Server يستخدم حوالي 500 ميغا بايت من ذاكرة الوصول العشوائي، ربما لا تسرب. إذا كانت عملية BizTalk Server يستخدم حوالي 1 غيغابايت من ذاكرة الوصول العشوائي، قد يكون هناك تسرب لذاكرة أو حالة ذاكرة العليا. قد يكون سبب استهلاك الذاكرة طويلة إجراء مخزن أو تزامن. تأكد من أنك تعرف مقدار الذاكرة يستخدم المضيف BizTalk عادة لتحديد ما إذا كان يتم حدوث تسرب للذاكرة أو شرط الذاكرة العليا.

رسائل كبيرة الحجم

عندما تقوم بمعالجة BizTalk Server رسائل كبيرة الحجم، يبدو النظام قد تسرب ذاكرة. ومع ذلك، قد تستخدم الرسائل قدرا كبيرا من الذاكرة. لمزيد من المعلومات حول رسائل كبيرة الحجم، قم بزيارة مواقع شبكة مطوري Microsoft (MSDN) التالية على الويب:أيضا، ضع في اعتبارك قد المتوقع استخدام الذاكرة العليا إذا كان خادم BizTalk يعالج الرسائل الكبيرة. قد تحتاج إلى ترقية الأجهزة لديك لتلبية متطلبات الأداء BizTalk Server في البيئة الخاصة بك.

كم من الوقت يلزم إعادة إنشاء تسرب الذاكرة

يمكن أن يحدث تسرب للذاكرة مباشرة أو قد تتراكم مع مرور الوقت. كلا السيناريوهين شائعة.

استخدام رمز التبديل/3GB أجهزة الكمبيوتر 32-بت

بشكل عام، عملية الوصول إلى 2 غيغابايت من مساحة العنوان الظاهرية. رمز التبديل /3GB هو خيار للأنظمة التي تتطلب المزيد من الذاكرة عنونة. قد يحسن هذا الخيار استخدام الذاكرة لمعالجة الرسائل. ومع ذلك، يسمح رمز التبديل /3GB ل 1 غيغابايت من الذاكرة عنونة لعمليات وضع kernel فقط. بالإضافة إلى ذلك، قد تزيد من رمز التبديل هذا خطر نفاد ذاكرة التجمع.

لمزيد من المعلومات حول 3 غيغابايت التبديل، قم بزيارة موقع شبكة مطوري Microsoft (MSDN) التالي على الويب:عند تمكين مفتاح التبديل /3GB على إصدار 32 بت من Windows، العملية يمكن الوصول إلى 3 غيغابايت من مساحة العنوان الظاهرية إذا كانت العملية العنوان الكبيرة على علم. عملية العنوان الكبيرة على علم عندما علم IMAGE_FILE_LARGE_ADDRESS_AWARE في صورة رأس الملف التنفيذي. لأن العملية BizTalk العنوان الكبيرة على علم، BizTalk سوف تستفيد من رمز التبديل/3GB.

إذا كان يعمل مثيل مضيف BizTalk 32 بت على إصدار 64-بت من Windows (AMD64)، فوائد عملية BizTalk من ذاكرة سعة 4 غيغابايت مساحة العنوان أنه BizTalk العنوان الكبيرة على علم. لذلك، نقل تطبيقاتك ذاكرة عالية إلى ملقم 64 بت قد يكون أفضل حل.

لقد عملية BizTalk 64-بت على إصدار 64-بت من Windows (AMD64) 8 تيرابايت ذاكرة عنونة.

يجب عليك أيضا وحدات البايت الظاهرية "و" وحدات البايت الخاصة التي تستخدم بواسطة العملية. قد تظهر مثيل مضيف BizTalk (وتطبيق.NET Framework) خارج خطأ الذاكرة قبل أن تصل قيمة "البايت الظاهري" إلى 2 غيغابايت. قد يحدث هذا على الرغم من أن الحد الأقصى للذاكرة عنونة العملية المعنية بإصدار 32 بت من Windows (بدون رمز التبديل /3GB ) هو 2 غيغابايت. للحصول على شرح لماذا يمكن أن يحدث هذا، قم بزيارة مواقع شبكة مطوري Microsoft (MSDN) التالية على الويب:رمز التبديل /3GB أيضا زيادة الحد الأقصى وحدات البايت الخاصة عملية BizTalk من 800 ميغا بايت إلى 1800 ميغا بايت. لمزيد من المعلومات حول.NET Framework أداء التطبيق مع رمز التبديل /3GB ممكنة، قم بزيارة موقع شبكة مطوري Microsoft (MSDN) التالي على الويب:

الجدول التالي يلخص هذه المعلومات وتتضمن حدود عملية لوحدات البايت الظاهرية "و" وحدات البايت الخاصة.
عمليةWindowsذاكرة قابلة للتوجيه (مع عملية معرفة عنوان كبير)حد عملي لوحدات البايت الظاهريةحد عملي لوحدات البايت الخاصة
32-bit32-bit2 غيغا بايت1400 ميغابايت800 ميغا بايت
32-bit32-بت مع 3 غيغا بايت3 غيغا بايت2400 ميغا بايت1800 ميغا بايت
32-bit64-bit4 جيجابايت3400 ميغا بايت2800 ميغا بايت
64-bit64-bit8 تيرابايتغير قابل للتطبيقغير قابل للتطبيق
لمزيد من المعلومات حول الذاكرة عنونة ل 32 بت و 64-بت Windows، قم بزيارة موقع شبكة مطوري Microsoft (MSDN) التالي على الويب:يسرد الجدول التالي المحسنة PAE و 3 غيغابايت لإصدارات مختلفة من خادم BizTalk.
المنتجملحق العنوان الفعلي3GB
BizTalk Server 2004نعملا
BizTalk Server 2006نعمنعم
BizTalk Server 2006 R2نعمنعم
BizTalk Server 2009نعمنعم
إذا كان يجب تمكين رمز التبديل /3GB للوفاء بمتطلبات أداء الكمبيوتر الذي يقوم بتشغيل خادم BizTalk، قد تحتاج إلى إضافة ملقمات إلى مجموعة BizTalk. يتيح لك ذلك لقياس حالات المضيف تستهلك ذاكرة كبيرة.

مكونات BizTalk التي تعمل داخل عملية خدمات معلومات إنترنت (IIS) قد تفيد أيضا عند تمكين مفتاح التبديل /3GB .

رمز التبديل /3GB غير معتمد على أجهزة الكمبيوتر التي تستخدم Windows SharePoint Services 2.0 أو الإصدارات الأحدث أو SharePoint Portal Server 2003 SP2 أو الإصدارات الأحدث. للحصول على مزيد من المعلومات، انقر فوق رقم المقالة التالي لعرضها في "قاعدة المعارف ل Microsoft":

رمز التبديل/3GB 933560 Windows Server 2003 غير معتمد في Windows SharePoint Services 2.0 أو الإصدارات اللاحقة أو في SharePoint Portal Server 2003 Service Pack 2 أو الإصدارات اللاحقة

استخدام مكونات مخصصة

إذا كنت تستخدم مكونات مخصصة، مثل خطوط الأنابيب أو مكونات خدمة، يجب أن تعرف هذه المكونات. يجب عليك أيضا معرفة الأثر المحتمل لهذه المكونات على استخدام الذاكرة. مشكلة في ذاكرة مشتركة عند مكون هو تحويل مستند. عملية تحويل عملية تستهلك ذاكرة كبيرة. عند تحويل مستند، يمرر BizTalk Server دفق الرسالة إلى فئة Microsoft.NET Framework XslTransform داخل عملية BizTalk.

تحدث المشكلة الشائعة آخر عند معالجة سلسلة مكثفة. يمكن معالجة سلسلة مكثفة لاستهلاك مساحة كبيرة من الذاكرة. لمزيد من المعلومات حول طرق لتحسين الأداء، قم بزيارة موقع شبكة مطوري Microsoft (MSDN) التالي على الويب:

إصدار من برنامج.NET Framework

Microsoft.NET Framework 2.0.NET Framework 1.1 وسلوك ذاكرة مختلفة. ولذلك، فقد تشاهد نتائج مختلفة فيما بينها. إذا كنت تستخدم برنامج.NET Framework، تأكد من تثبيت أحدث.NET Framework Service Pack 1. معالجة حزم الخدمة هذه العديد من المشكلات المعروفة في الذاكرة. لمزيد من المعلومات، انقر فوق أرقام المقالات التالية:

945757 المشكلات التي تم إصلاحها في.NET Framework 2.0 Service Pack 1
867460 قائمة بالأخطاء التي تم إصلاحها في.NET Framework 1.1 Service Pack 1

عدد المعالجات

وقت تشغيل اللغة العامة (CLR) على جامعي القمامة (نشرة مصورة عمومية Gc) التالية:
  • محطة العمل (Mscorwks.dll)
  • ملقم (Mscorsvr.dll)
إذا كان الكمبيوتر الذي يقوم بتشغيل خادم BizTalk نظام متعدد المعالجات، يستخدم.NET Framework إصدار الخادم من محرك التنفيذ. هذا هو السلوك الافتراضي. جامع البيانات المهملة ملقم مصممة لأقصى قدر من الإنتاجية. بالإضافة إلى ذلك، يقيس جامع البيانات المهملة الخادم لتوفير أداء عالي جداً. هذا جامع البيانات المهملة بتخصيص الذاكرة وثم فيما بعد بتحرير الذاكرة لتوفير الأداء العالي على النظام. ولذلك، يبدو كمبيوتر الذي يقوم بتشغيل خادم BizTalk جنبا إلى جنب مع بعض المكونات.NET Framework يكون تسرب ذاكرة. ومع ذلك، في هذا السيناريو، استخدام الذاكرة العليا هو السلوك المتوقع. إذا كان الكمبيوتر نفدت ذاكرة النظام، أو العملية توقف عن العمل بسبب عدم كفاية الذاكرة عنونة، قد توجد حالة تسرب ذاكرة.

إذا كان الكمبيوتر الذي يقوم بتشغيل خادم BizTalk نظام معالج واحد، يستخدم.NET Framework إصدار محطة عمل محرك التنفيذ. هذا هو السلوك الافتراضي. خوارزمية تخصيص جامع البيانات المهملة محطة العمل غير مصمم لقياس أو لأقصى قدر من الإنتاجية. يستخدم هذا جامع البيانات المهملة أساليب جامع البيانات المهملة المتزامنة. تم تصميم هذه الأساليب للتطبيقات التي تحتوي على واجهات مستخدم معقدة. قد تتطلب هذه التطبيقات أكثر عدوانية المهملة.

هام: يحتوي هذا المقطع أو الأسلوب أو المهمة على الخطوات التي توضح كيفية تعديل التسجيل. ومع ذلك، قد تحدث مشكلات خطيرة إذا قمت بتعديل التسجيل بشكل غير صحيح. لذلك، تأكد من اتباع الخطوات التالية بعناية. للحماية الإضافية، قم بعمل نسخة احتياطية للسجل قبل تعديله. بعد ذلك، يمكنك استعادة السجل في حالة حدوث مشكلة. لمزيد من المعلومات حول كيفية عمل نسخة احتياطية من السجل واستعادته، انقر فوق رقم المقالة التالية لعرضها في "قاعدة معارف Microsoft":
322756 كيفية عمل نسخة احتياطية من السجل واستعادته في نظام التشغيل Windows
في بعض الأحيان، قد يكون من المناسب لتشغيل إصدار محطة عمل محرك التنفيذ على نظام متعدد المعالجات. يمكنك استخدام مفتاح التسجيل التالي للتبديل إلى إصدار محطة عمل محرك التنفيذ.

BizTalk 2006 والإصدارات الأحدث

إنشاء مفتاح التسجيل التالي سلسلة استضافة CRL بالقيم المطابقة:

استضافة HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$بيزتالخوستنامي\CLR

الاسم: الصفة
البيانات: wks

BizTalk 2004

إنشاء مفتاح التسجيل التالي سلسلة استضافة CRL بالقيم المطابقة:

المضيف \CLR HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc {GUID}

الاسم: الصفة
البيانات: wks

لمزيد من المعلومات، قم بزيارة مواقع شبكة مطوري Microsoft (MSDN) التالية على الويب:

الأسباب الشائعة والحلول

استخدام ذاكرة العملية وكبح عتبات استخدام الذاكرة الفعلية

يمكن تغيير استخدام ذاكرة العملية وكبح عتبات استخدام الذاكرة الفعلية في BizTalk Server 2006 والإصدارات الأحدث.
  • بشكل افتراضي، يتم تعيين التحكم عتبة استخدام ذاكرة العملية إلى 25. إذا تم تجاوز هذه القيمة واستخدام ذاكرة العملية BizTalk أكثر من 300 ميغا بايت، قد تحدث حالة التحكم. على ملقم 32 بت، يمكنك زيادة قيمة استخدام ذاكرة العملية إلى 50. على ملقم 64 بت، يمكنك زيادة هذه القيمة إلى 100. يسمح هذا لمزيد من استهلاك الذاكرة قبل عملية BizTalk قبل حدوث اختناق.
  • استخدام الذاكرة الفعلية عتبة التحكم بقيمة افتراضية 0. يقيس هذا العتبة ذاكرة النظام الإجمالي. ولذلك، إذا تم تكوين قيمة غير 0، يمكن أن يحدث شرط اختناق إذا عالية الذاكرة الذي تستخدمه إحدى العمليات غير BizTalk.
لمزيد من المعلومات حول حدود التحكم، قم بزيارة موقع شبكة مطوري Microsoft (MSDN) التالي على الويب:

كبح عتبات الجفاف

عتبات الجفاف الذاكرة الافتراضية قد يؤدي الجفاف كثيرا عند orchestrations على نظام التشغيل 64 بت مضيف. لمزيد من المعلومات حول هذه المشكلة، راجع الموضوع الجفاف الخصائص الافتراضية على موقع شبكة مطوري Microsoft (MSDN) التالي على الويب:المضيفين 64 بت الملاحظة معتمدة في BizTalk Server 2006 والإصدارات الأحدث.

على الأجهزة مكافئ في مثيل مضيف 32 بت، الجفاف ملاحظتها الأسمى عند تشغيل باستخدام الجفاف الذاكرة الافتراضية كبح عتبات التوزيعات الموسيقية نفس.

لأن بنية 64 بت يوفر مساحة عنوان الذاكرة الموسعة (16 تيرابايت بدلاً من 4 غيغا بايت)، يتم تخصيص مثيلات المضيف 64 بت إلى ذاكرة أكثر من مثيل للمضيف 32 بت. يمكن أن يسبب هذا عتبات التحكم الذاكرة الافتراضية إلى تجاوز.

لحل هذا السلوك، تغيير القيم فيرتوالميموريثروتلينجكريتيريا وبريفاتيميموريثروتلينجكريتيريا في الملف BTSNTSvc64.exe.config. استخدام وحدات البايت Process\Virtual وعدادات مراقبة الأداء بايت Process\Private لتحديد مقدار أكبر من الذاكرة التي تم تخصيصها بمثيل تزامن.
  • تعيين قيمة أوبتيمالوساجي لكلتا الخاصيتين على ما يلي:
    فيرتوالميموريثروتلينجكريتيريا: قيمة البايت \Process\Virtual + 10%
    بريفاتيميموريثروتلينجكريتيريا: قيمة البايت \Process\Private + 10%
  • تعيين ماكسيمالوساجي لكلتا الخاصيتين إلى القيمة أوبتيمالوساجي + 30%
على سبيل المثال، إذا كان \Process\Virtual قيمة عدادات "مراقبة الأداء بايت" لمثيل تزامن بايت 5,784,787,695 (5,517 ميغا بايت)، تعيين قيمة أوبتيمالوساجي فيرتوالميموريثروتلينجكريتيريا إلى 6,069 بايت (5,784,787,695 * 1.10 = 6,363,266,464.5 بايت). تعيين قيمة ماكسيمالوساجي فيرتوالميموريثروتلينجكريتيريا إلى 7,889 بايت (6,363,266,464.5 * 1.30 = 8,272,246,403.85 بايت).

إذا كان \Process\Private قيمة عدادات "مراقبة الأداء بايت" 435689400 بايت (415 MB)، بتعيين قيمة أوبتيمالوساجي بريفاتيميموريثروتلينجكريتيريا إلى 457 ميغا بايت (435689400 * 1.10 = 479258340 بايت). تعيين قيمة ماكسيمالوساجي بريفاتيميموريثروتلينجكريتيريا إلى 594 ميغا بايت (479258340 * 1.30 = 623035842).

على سبيل المثال، أن تحديد القيم التالية في الملف BTSNTSvc64.exe.config لتقليل التحكم.
عدادات مراقبة الأداءتخصيص الذاكرةأوبتيمالوساجيماكسيمالوساجي
\Process\Virtual بايت5784787695 بايت (5517 ميغا بايت)60697889
\Process\Private بايت435689400 بايت (415 ميغابايت)457594
هذه القيم ثم نجد في الملف BTSNTSvc64.exe.config كما يلي:
<xlangs>      <Configuration>
<Dehydration>
<VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
<PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
</Dehydration>
</Configuration>
</xlangs>
لتحديد مثيل المضيف الذي يقوم بتشغيل التزامن، يمكنك مطابقة معرف العملية من \BizTalk:Messaging\ID العملية وعدادات "مراقبة الأداء عملية" \Process\ID. ثم، تحقق متوسط القيمة المعروضة للمقابلة \Process\Virtual بايت وعدادات "مراقبة الأداء بايت" \Process\Private.

ملاحظة: يؤدي الجفاف ارتفاع حدوث انخفاض في الأداء عند تشغيل قاعدة البيانات بيزتالكمسجبوكسدب في SQL Server 2008.

خادم BizTalk حزم الخدمة والتحديثات التراكمية

خادم BizTalk حزم الخدمة والتحديثات التراكمية تتضمن أحدث الإصلاحات. وهي تتضمن تلك التي تؤثر على المشكلات المعروفة System.OutOfMemoryException.

قائمة 2281783 حزمة الخدمة والتحديثات التراكمية ل BizTalk Server 2006 R2

Microsoft BizTalk Server 2004 Service Pack 2

هيبديكوميتفريبلوكثريشولد

بشكل افتراضي، هو قيمة مفتاح التسجيل ثيهيبديكومميتفريبلوكثريشولد 0. قيمة 0 تعني أن إدارة كومة الذاكرة المؤقتة decommits كل صفحة 4 كيلوبايت (KB) تصبح متوفرة. إلغاء تتسبب عمليات تجزئة الذاكرة الظاهرية. يعتمد حجم الإعداد هيبديكوميتفريبلوكثريشولد في إدارة كومة الذاكرة المؤقتة على نوع العمل الذي يقوم به النظام. حجم 0x00040000 قيمة بداية الموصى بها.

خذ بعين الاعتبار المعلومات التالية قبل تغيير قيمة مفتاح التسجيل هيبديكوميتفريبلوكثريشولد :
  • ينطبق هذا التغيير فقط على مشاكل تجزئة الذاكرة.
  • يتم تغيير هذه المنظومة. ولذلك، سيتم استخدام معظم عمليات المزيد من الذاكرة عند بدء التشغيل.
  • أن تأخذ في الاعتبار هذا التغيير للأنظمة التي تحتوي على خادم BizTalk مهمتهم الأساسية.
للمساعدة في تقليل تجزئة الذاكرة الظاهرية، يمكنك زيادة حجم الإعداد هيبديكوميتفريبلوكثريشولد في إدارة كومة الذاكرة المؤقتة عن طريق تغيير قيمة مفتاح التسجيل التالي:
إدارة HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session

اسم القيمة: هيبديكوميتفريبلوكثريشولد
نوع القيمة: REG_DWORD
قيمة البيانات: 0x00040000 (هذا هو القيمة الابتدائية الموصى بها.)
القيمة الافتراضية: غير موجود
لمزيد من المعلومات حول مفتاح التسجيل هيبديكوميتفريبلوكثريشولد، انقر فوق رقم المقالة التالي لعرضها في "قاعدة المعارف ل Microsoft":

315407 "هيبديكوميتفريبلوكثريشولد" مفتاح التسجيل

عمليات التحويل

عند BizTalk Server بتنفيذ عمليات تحويل XML على رسائل إلى حد كبير في منفذ تلقي، في منفذ إرسال أو في XLANG، تحويل XSL تحميل الرسالة كاملة في الذاكرة...

لحل هذه المشكلة، استخدم إحدى الطرق التالية:
  • تقليل عدد الرسائل التي تعالج BizTalk Server في نفس الوقت.
  • تقليل حجم الرسالة XML الذي يتم تحويله.
الكائن System.Policy.Security.Evidence كثيرا ما يستخدم في التحويلات ويمكن أن تستهلك الكثير من الذاكرة. عندما يتضمن مخطط functoid برمجة يستخدم السطر C # (أو أي لغة أخرى مضمنة)، يتم إنشاء التجميع في الذاكرة. يستخدم الكائن System.Policy.Security.Evidence الكائن الفعلي التجميع المستدعي. ينشئ هذا الموقف كائن الجذور لن يتم حذفها حتى يتم إعادة تشغيل خدمة BizTalk.

وتنفذ معظم functoids BizTalk الافتراضي كالبرامج النصية المضمنة. يمكن أن يسبب هذه العناصر الكائنات [] System.Byte لتجميع في الذاكرة. لتقليل استهلاك الذاكرة، من المستحسن وضع أي مخطط يستخدم هذه functoids إلى تجميع صغيرة. وبعد ذلك، ترجع إلى هذا التجميع. استخدم الجدول التالي لتحديد functoids التي تستخدم البرامج النصية المضمنة و functoids التي لا تستخدم البرامج النصية المضمنة.

في العمود الثاني، "نعم" يعني هذا functoid وينفذ كبرنامج نصي مضمن، وسوف يؤدي الكائنات [] System.Byte لتجميع في الذاكرة. "لا" يعني أن هذا functoid لا ينفذ كبرنامج نصي مضمن، وأنه لن يسبب الكائنات [] System.Byte لتجميع في الذاكرة.
Functoidsالبرامج النصية المضمنة؟
كافة Functoids سلسلةنعم
كافة Functoids الرياضيةنعم
كافة Functoids منطقية فيما عدا IsNilنعم
IsNil Functoid المنطقيةلا
كافة Functoids التاريخ/الوقتنعم
Functoids تحويل كافةنعم
كافة Functoids العلميةنعم
كافة Functoids التراكمينعم
كافة قواعد البيانات Functoidsلا
Functoids المتقدمةالبرامج النصية المضمنة؟
حلقي Functoidلا
القيمة التي تم تعيين Functoid التسويةلا
تأكيد Functoidلا
جدول مستخرج Functoidلا
Functoid تكرار الجدوللا
Functoid البرمجة مع السطر # Cنعم
Functoid البرمجة مع JScript.NET المضمنةنعم
Functoid البرمجة مع.NET مضمنة Visual Basicنعم
Functoid البرمجة باستخدام XSLT مضمنةلا
Functoid البرمجة مع قالب XSLT مضمنة المكالمةلا
Functoid البرمجة استدعاء "تجميع خارجي"لا
Functoid قيمة الصفرلا
Functoid تعيين القيمةلا
Functoid نسخة الجماعيلا
Functoid تكرارلا
Functoid الفهرسلا
Functoid عدد السجلاتلا
BizTalk Server 2006 والإصدارات الأحدث إلى حد كبير تحسين إدارة الذاكرة للوثائق الكبيرة. خادم BizTalk للقيام بذلك، بتطبيق حد حجم رسائل القابلة لتكوين لتحميل المستندات إلى الذاكرة أثناء عمليات التحويل. حد حجم الرسائل الافتراضي هو 1 ميغابايت. لمزيد من المعلومات حول إعداد ترانسفورمثريشولد، قم بزيارة موقع شبكة مطوري Microsoft (MSDN) التالي على الويب:

قيم السمة كبيرة وقيم عنصر كبير

عندما ينفذ خادم BizTalk توجيه تلقي أو خط أنابيب إرسال على مستند XML، تتم معالجة الحمولة في الذاكرة إذا كان المستند يحتوي على واحد أو أكثر من الوحدات التالية:
  • قيم السمة كبيرة
  • قيم عنصر كبير
  • علامات سمة أو عنصر كبير
لحل هذه المشكلة، تحديد حجم هذه الكيانات. إذا كان هذا الأسلوب غير ممكن، تأكد من أن المثيل BizTalk المضيف الخاص بك غير معالجة مستندات متعددة كهذه في نفس الوقت.

مكونات التدفقات المخصصة

استخدام مكون تدفقات مخصص يحمل التدفق الكامل في الذاكرة. كافة المكونات التي تم تضمينها في BizTalk Server، ما عدا التحويلات، يعتمد الدفق. لا تستخدم هذه المكونات قدر الذاكرة أثناء الدفق. ومع ذلك، مكونات التدفقات المخصصة قد لا يدعم الدفق.

دفق تحت الضغط كثيف

إرسال المضيفين نفاد الذاكرة عندما تعمل تحت ضغط كثيف. خادم BizTalk إرسال خطوط الأنابيب وإرسال دفق دعم المحولات. في التدفق، يحمل كل مكون من مكونات جزء صغير من التدفق في الذاكرة. نظراً لأن كل رسالة تتضمن هياكل البيانات الأخرى، جنبا إلى جنب مع سياق رسالة التي يمكن أن تكون كبيرة أو صغيرة، يؤثر هذا السلوك على سلوك BizTalk Server تحت الضغط كثيف.

يتأثر سلوك خادم BizTalk لأن المحرك يحمل عدد الرسائل التي تم تكوينها مسبقاً. عدد الرسائل التي تقوم بتحميل المحرك استناداً إلى القيم التي تظهر في الحقل لوواتيرمارك وحقل هايواتيرمارك الجدول Adm_serviceClass. جدول Adm_serviceClass في قاعدة بيانات إدارة BizTalk. هذه القيم السيطرة على عدد الرسائل التي تعالج BizTalk Server أو يرسل في نفس الوقت.

القيمة هايواتيرمارك هي العدد الإجمالي للرسائل التي تعالج المحرك في نفس الوقت. القيمة الافتراضية 200 رسالة كل وحدة المعالجة المركزية. لذلك، على ملقم المعالج 8 المضيف إرسال سيحاول معالجة الرسائل 1600 (200 * 8) في نفس الوقت. وفي حالة افتراض أن كل رسالة هو 50 كيلو بايت، الرسائل يساوي 80 ميغا بايت (1، 600 * 50 = 80، 000 كب).

لحل هذه المشكلة، يمكنك تغيير قيمة هايواتيرمارك وقيمة لوواتيرمارك في قاعدة البيانات. تعتمد القيم التي تستخدمها على حجم الرسائل.

لمزيد من المعلومات حول الأسباب الشائعة لشرط خارج الذاكرة، راجع المقطع "الذاكرة النمو في BizTalk المراسلة" في موقع Microsoft التالي على الويب:BizTalk Server 2006 والإصدارات الأحدث، يمكنك تغيير إعدادات التحكم المضيف الافتراضي. لمزيد من المعلومات حول كيفية تغيير إعدادات التحكم المضيف الافتراضي، قم بزيارة موقع شبكة مطوري Microsoft (MSDN) التالي على الويب:

حاول تبسيط المشكلة

إذا قمت بتحديد تسرب ذاكرة، حاول تحديد السبب عن طريق إزالة مكونات مخصصة أو عن طريق تبسيط مخطط. كذلك، حاول إعادة إنشاء المشكلة باستخدام حل بسيط أو تزامن بسيطة. بشكل عام، يجب عليك إنشاء منفصلة تلقي تلقي المضيفين للمحولات. يجب أيضا إنشاء المضيفين إرسال منفصلة لإرسال المحولات. عند استخدام هذه الطريقة، يمكن تشغيل كل محول في عملية منفصلة. ولذلك، إذا واجه عملية خادم BizTalk شرط خارج الذاكرة، ستعرف المكونات المتضمنة.

خطوات استكشاف الأخطاء وإصلاحها

استكشاف أخطاء شرط خارج الذاكرة، استخدام أداة تشخيص Debug لمراقبة عمليات تخصيص الذاكرة مع مرور الوقت. يمكنك إنشاء أداة تشخيص Debug وتحليل ملف تفريغ تسرب ذاكرة (.dmp). عند استكشاف أخطاء عمليات تسرب للذاكرة، الهدف إرفاق Leaktrack.dll قبل يستنسخ شرط ذاكرة عالية لالتقاط نمو الذاكرة على مر الزمن. يتم تضمين أداة تشخيص Debug Leaktrack.dll.
  1. تثبيت أداة تشخيص التصحيح.

    يتوفر الملف التالي للتنزيل من مركز التنزيل ل Microsoft:

    Download قم بتنزيل حزمة "تصحيح أداة تشخيص" الآن.

    لمزيد من المعلومات حول كيفية تنزيل ملفات دعم Microsoft، انقر فوق رقم المقالة التالي عرضها في "قاعدة معارف Microsoft":
    119591 كيفية الحصول على ملفات دعم Microsoft من الخدمات عبر الإنترنت
    قامت Microsoft بفحص هذا الملف بحثًا عن الفيروسات. استخدمت Microsoft أحدث برامج الكشف عن الفيروسات التي كانت متوفرة في التاريخ الذي تم نشر الملف فيه. يتم تخزين الملف على خوادم محسنة الأمان تساعد على منع إجراء أية تغييرات غير مصرح بها على الملف.
  2. استخدام "مراقبة الأداء" لجمع البيانات حول أداء النظام. قد توفر هذه البيانات مؤشرات هامة حول كفاءة بيئة BizTalk Server الخاص بك. الهدف للحصول على أداء العملية مع مرور الوقت. وبالتالي، تمكين تسجيل "مراقبة الأداء" قبل حدوث التسرب في الذاكرة.

كيفية استخدام تسجيل "مراقبة الأداء"

تحديد البيانات لتسجيل
لتحديد البيانات لتسجيل الدخول، استخدم الأسلوب الذي يناسب نظام التشغيل الخاص بك:
  • لنظام التشغيل Windows Server 2008 و Windows Server 2008 R2
    1. في "أدوات إدارية", فتح مراقبة الثبات والأداء.
    2. زر الماوس الأيمن فوق مراقب الأداء، انقر فوق جديد وانقر فوق مجموعة جامع البيانات.
    3. في المربع الاسم ، اكتب اسماً وصفياً، ومن ثم انقر فوق التالي.
    4. لاحظ الدليل الجذر، ومن ثم انقر فوق التالي.
    5. انقر فوق ابدأ مجمعي البيانات هذه الآن، ومن ثم انقر فوق إنهاء.
    6. مجموعات مجمعات البياناتلتوسيع المعرفة من قبل المستخدم وثم حدد الملف.
    7. انقر نقراً مزدوجاً فوق سجل مراقب النظام، ومن ثم انقر فوق خصائص.
    8. انقر فوق إضافة في علامة التبويب عدادات الأداء تحديد الكائنات التالية ومن ثم انقر فوق إضافة بعد تحديد كل كائن:
      • استثناءات net CLR
      • الذاكرة ل.Net CLR
      • BizTalk:Messaging
      • BizTalk:TDDS
      • الذاكرة
      • عملية
      • المعالج
      • التوزيعات الموسيقية XLANG/ثانية
      إذا كان خادم SQL المحلي، أيضا إضافة الكائنات التالية:
      • SQLServer:Databases
      • إحصائيات SQLServer:General
      • إدارة SQLServer:Memory
    9. انقر فوق موافق.
    10. تغيير المربع قيمة "الفاصل الزمني للعينة" مدة 5 ثوان.

      ملاحظة: قيمة "الفاصل الزمني للعينة" والوقت لبدء مراقبة ذاتية. تعتمد هذه القيم على عندما يتم تكرار حدوث تسرب للذاكرة. لأنه يمكن أن يكون ملف السجل كبير، حدد الفترة زمنية التي يمكن الحصول على المعلومات التي يجب أن يكون لديك دون إرهاق الخادم.
    11. انقر فوق موافق.
    لإيقاف تجميع البيانات، انقر فوق إيقاف في القائمة إجراء .
  • لنظام التشغيل Windows Server 2003 أو نظام التشغيل Windows XP
    1. قم بتوسيع تنبيهات وسجلات الأداء.
    2. انقر نقراً مزدوجاً فوق سجلات العدادات، ومن ثم انقر فوق إعدادات سجل جديد. يظهر مربع الحوار إعدادات السجل الجديد .
    3. في المربع الاسم ، اكتب اسماً وصفياً، ومن ثم انقر فوق موافق.
    4. لاحظ موقع ملف السجل. (يمكنك أيضا النقر فوق
      ملفات سجل الجدولة، ومن ثم انقر فوق تكوين لتغيير موقع ملف السجل.)
    5. انقر فوق إضافة عدادات.
    6. حدد كافة العدادات و كافة المثيلات.
    7. في قائمة كائنات الأداء ، حدد الكائنات التالية. انقر فوق إضافة بعد تحديد كل كائن.

      • استثناءات net CLR
      • الذاكرة ل.Net CLR
      • BizTalk:Messaging
      • BizTalk:TDDS
      • الذاكرة
      • عملية
      • المعالج
      • التوزيعات الموسيقية XLANG/ثانية
      إذا كان خادم SQL المحلي، أيضا إضافة الكائنات التالية:

      • SQLServer:Databases
      • إحصائيات SQLServer:General
      • إدارة SQLServer:Memory
    8. انقر فوق إغلاق.
    9. تغيير القيمة الموجودة في البيانات في أخذ عينات الفاصل الزمني لمدة 5 ثوان.

      ملاحظة: أن قيمة "الفاصل الزمني العينة البيانات" والوقت لبدء مراقبة ذاتية. تعتمد هذه القيم على عندما يتم تكرار حدوث تسرب للذاكرة. لأنه يمكن أن يكون ملف السجل كبير، حدد الفترة زمنية التي يمكن الحصول على المعلومات التي يجب أن يكون لديك دون إرهاق الخادم.
    10. انقر فوق موافق.
    لإيقاف تجميع البيانات، انقر نقراً مزدوجاً فوق اسم سجل العداد ومن ثم انقر فوق إيقاف.
الحصول على ملف التفريغ
للحصول على ملف التفريغ، استخدم إحدى الطرق التالية:
  • الطريقة الأولى: تلقائي
    إنشاء قاعدة الذاكرة ومعالجة التسرب ب DebugDiag هو الأسلوب المستحسن لالتقاط ملف تفريغ ذاكرة. القاعدة الذاكرة ومعالجة التسرب وتولى Leaktrack.dll تلقائياً. يتم استخدام هذا لتعقب عمليات تخصيص الذاكرة. لإنشاء قاعدة معالجة التسرب والذاكرة، اتبع الخطوات التالية:
    1. بدء تشغيل أداة تشخيص التصحيح 1.1.
    2. حدد الذاكرة ومعالجة التسربومن ثم انقر فوق التالي.
    3. حدد عملية Btsntsvc.exe ، ومن ثم انقر فوق التالي.
    4. في الصفحة "تكوين قاعدة تسرب"، اتبع الخطوات التالية:
      1. انقر لتحديد خانة الاختيار بدء تعقب فورا عند تنشيط القاعدة الذاكرة . وإلا، يمكنك تحديد وقت احماء قبل أن يتم حقن LeakTrack.dll في عملية BTSNTSvc.exe.
      2. انقر فوق تكوين، وقم بما يلي:
        • التأكد من أن الإنشاء التلقائي لقاعدة تعطل محدداً. بتحديد هذا الخيار، تفريغ ذاكرة سيتم إنشاء تلقائياً في حالة توقف عملية BTSNTSvc.exe.
        • انقر لتحديد خانة الاختيار إنشاء userdump عندما تصل إلى البايت الظاهري ، والحفاظ على القيمة الافتراضية من 1024.
        • انقر لتحديد خانة الاختيار وكل إضافية والاحتفاظ بالافتراضي 200.
        عن طريق تحديد وحدات البايت الظاهرية الوصول إلى الخيار، تفريغ ذاكرة يتم إنشاء تلقائياً عندما تستخدم وحدات البايت الظاهري 1024 ميجابايت. إذا كانت تزداد البايت الظاهري من 200 ميغا بايت، سيتم تلقائياً إنشاء تفريغ الذاكرة آخر.
      3. انقر فوق حفظ وإغلاق.
      4. انقر فوق التالي.
    5. في الصفحة "تحديد تفريغ موقع واسم القاعدة"، انقر فوق التالي.

      ملاحظة: يمكنك أيضا تغيير مسار ملف التفريغ في المربع الموقع Userdump على هذه الصفحة.
    6. انقر فوق إنهاء لجعل القاعدة نشطة الآن.
    ملاحظة: يتم الآن تعقب حالة القاعدة. كل مرة يتم إنشاء ملف تفريغ ذاكرة، زيادة القيمة في العمود العدد Userdump ضمن علامة التبويب قواعد. تفريغ الذاكرة الافتراضي هو C:\Program Files\DebugDiag\Logs.
  • الطريقة الثانية: يدوي
    يمكنك إرفاق Leaktrack.dll يدوياً ويدويًا الحصول على ملف تفريغ ذاكرة النظام. يتيح لك ذلك للتحكم عندما يتم إنشاء تفريغ الذاكرة. للقيام بذلك، اتبع الخطوات التالية:
    1. بدء تشغيل أداة تشخيص التصحيح 1.1.
    2. انقر فوق علامة التبويب العمليات .
    3. انقر نقراً مزدوجاً فوق العملية Btsntsvc.exe ومن ثم انقر فوق
      مراقبة بحثاً عن الثقوب.
    4. في مربع الحوار أداة تشخيص التصحيح ، انقر فوق نعم، ومن ثم انقر فوق موافق.
    إنشاء قاعدة تعطل لمراقبة عملية Btsntsvc.exe نفسها في حالة إيقاف العملية قبل إنشاء تفريغ الذاكرة:
    1. بدء تشغيل أداة تشخيص التصحيح 1.1.
    2. حدد تعطلومن ثم انقر فوق التالي.
    3. حدد عملية محددة، ومن ثم انقر فوق التالي.
    4. حدد نفس العملية Btsntsvc.exe، ومن ثم انقر فوق التالي.
    5. على صفحة تكوين متقدم (اختياري) ، انقر فوق التالي.
    6. في مربع الحوار تحديد تفريغ موقع واسم القاعدة (اختياري) ، انقر فوق التالي.
    7. حدد تنشيط قاعدة الآنومن ثم انقر فوق "إنهاء".
    عندما تصل العملية إلى 60 في المائة إلى 80 في المائة من ذاكرة الوصول العشوائي، زر الماوس الأيمن فوق العملية Btsntsvc.exe ومن ثم انقر فوق إنشاء Userdump الكامل. إذا توقفت عملية BizTalk قبل إنشاء تفريغ المستخدم، يجب أن تسري القاعدة العطل وإنشاء تفريغ الذاكرة.
إيقاف تسجيل "مراقبة الأداء"
إذا كنت تقوم بالتقاط تفريغ الذاكرة وبيانات "مراقبة الأداء"، إيقاف التسجيل "مراقبة الأداء" حوالي دقيقتين بعد إنشاء تفريغ الذاكرة.
تحليل ملف التفريغ
للمساعدة في تحديد سبب تسرب الذاكرة، يمكنك استخدام أداة تشخيص Debug لتحليل ملف التفريغ. للقيام بذلك، اتبع الخطوات التالية:
  1. انقر فوق علامة التبويب تحليل متقدمة.
  2. انقر فوق إضافة ملفات البياناتومن ثم عين موقع الملف.dmp.
  3. تحديد برنامج نصي تحليل ضغط الذاكرةومن ثم انقر فوق بدء تحليل.
بشكل افتراضي، ملف تقرير تحليل (.mht) سيتم إنشاء في المجلد C:\Program Files\DebugDiag\Reports عند الانتهاء من التحليل. سيتم أيضا عرض ملف التقرير في المستعرض الخاص بك. يحتوي ملف التقرير على نتائج التحليل. بالإضافة إلى ذلك، قد تحتوي على ملف التقرير توصيات بشأن كيفية حل التسرب في الذاكرة.

إذا كنت تستخدم DLLs مخصصة، يمكنك إضافة مسار الرمز من ملفات.pdb المخصصة للتحليل. للقيام بذلك، اتبع الخطوات التالية:
  1. فتح أداة تشخيص Debug.
  2. من القائمة أدوات ، انقر فوق خيارات وإعدادات.
  3. في المربع رمز البحث مسار لتصحيح الأخطاء، اكتب مسار الرمز.
إذا كنت تريد تحليل ملف التفريغ التعليمات، اتصل بخدمات دعم العملاء في Microsoft. للحصول على قائمة كاملة من أرقام الهواتف "خدمات دعم العملاء" ومعلومات حول تكاليف الدعم، الرجاء زيارة موقع Microsoft التالي على الويب:قبل الاتصال "خدمات دعم العملاء"، ضغط ملف تفريغ سجل "مراقبة الأداء"، تحليل ملف التقرير وسجلات الأحداث المحدثة (ملفات.evt). قد تضطر لإرسال مهندس دعم هذه الملفات إلى خادم BizTalk.