التنازع على الموارد متعددة مؤشرات الترابط

Question

أقوم بإعداد ملف تعريف لبرنامج متعدد مؤشرات الترابط يعمل بأعداد مختلفة من سلاسل الرسائل المسموح بها. فيما يلي نتائج الأداء لثلاثة أشواط لنفس عمل الإدخال. Genacodicetagpre

نظرًا لأن الخيوط تستغرق وقتًا أطول للقيام بنفس العمل ، أشعر أن سلاسل الرسائل يجب أن تتنافس على الموارد.

لقد قمت بالفعل بفحص الركائز الأربعة (وحدة المعالجة المركزية ، والذاكرة ، و diskIO ، والشبكة) على كل من جهاز التطبيق وخادم قاعدة البيانات. كانت الذاكرة هي المورد الأصلي المتنازع عليه ، ولكن تم إصلاح ذلك الآن (أكثر من 1G مجانًا في جميع الأوقات). تتأرجح وحدة المعالجة المركزية بين 30٪ و 70٪ في اختبار 20 مؤشر ترابط ، لذا يوجد الكثير هناك. diskIO عمليًا لا يوجد على جهاز التطبيق ، وهو ضئيل على خادم قاعدة البيانات. الشبكة رائعة حقًا.

لقد قمت أيضًا بإنشاء ملف تعريف برمجي باستخدام redgate ولا أرى أي طرق تنتظر على الأقفال. من المفيد أن الخيوط لا تشارك الحالات. الآن أتحقق من المزيد من العناصر الدقيقة مثل إنشاء / تجميع اتصال قاعدة البيانات (إذا حاول 20 مؤشر ترابط الاتصال بنفس قاعدة البيانات ، فهل يتعين عليهم الانتظار لبعضهم البعض؟).

أحاول تحديد التنازع على المورد ومعالجته ، بحيث يبدو تشغيل 20 مؤشر ترابط على النحو التالي: Genacodicetagpre

ما هي المصادر الأكثر احتمالًا (بخلاف المصادر الأربعة الكبيرة) التي يجب أن أبحث عنها للعثور على هذا الخلاف؟

---

الرمز الذي يؤديه كل مؤشر ترابط هو تقريبًا: Genacodicetagpre

تعمل خدمات WCF على نفس الجهاز وهي عديمة الحالة وقادرة على التعامل مع طلبات متعددة في وقت واحد.

---

الجهاز به 8 وحدات المعالجة المركزية.

Answer 1

ما تصفه هو أنك تريد قابلية توسعة بنسبة 100٪ أي علاقة 1: 1 بين الزيادة في مؤشرات الترابط وانخفاض وقت Wallcklock ... هذا هدف عادي ولكن يصعب الوصول إليه ...

على سبيل المثال ، تكتب أنه لا يوجد خلاف على الذاكرة نظرًا لوجود مساحة خالية تبلغ 1 غيغابايت ... هذا افتراض خاطئ من IMHO ... التنازع على الذاكرة يعني أيضًا أنه إذا حاول خيطان تخصيص ذاكرة ، فقد يحدث أن انتظر الآخر ... ponint آخر لتأخذ في الاعتبار الانقطاعات التي تحدث بواسطة GC والتي تجمد جميع سلاسل العمليات مؤقتًا ... يمكن تخصيص GC قليلاً عبر التكوين (gcServer) - راجع http://blogs.msdn.com/b/clyon/archive/2004/09/08 /226981.aspx

نقطة أخرى هي خدمة WCF المسماة ... إذا لم تتمكن من توسيع نطاقها - على سبيل المثال عرض PDF - فهذا أيضًا شكل من أشكال الخلاف على سبيل المثال ...

قائمة الخلاف المحتمل "لا نهاية لها" ... وبالكاد تكون دائمًا في المجالات الواضحة التي ذكرتها ...

تعديل - حسب التعليقات:

يجب التحقق من بعض النقاط:

• تجميع الاتصالات
  ما المزود الذي تستخدمه؟ كيف يتم تكوينه؟
• عرض PDF
  يمكن قياس الخلاف المحتمل في مكان ما داخل المكتبة التي تستخدمها ...
• Linq2SQL
  تحقق من خطط التنفيذ لجميع هذه الاستعلامات ... يمكن أن يأخذ البعض أي نوع من القفل ، وبالتالي من المحتمل إنشاء تنازع على جانب خادم DB ...

تعديل 2:

الخيوط
هل هذه المواضيع من ThreadPool؟ إذا كان الأمر كذلك ، فلن تتمكن من القياس :-(

تعديل 3:

تعد سلاسل ThreadPool سيئة بالنسبة للمهام طويلة المدى وهذا هو الحال في السيناريو الخاص بك ... لمزيد من التفاصيل ، راجع

• http:// theburningmonk.com/2010/03/threading-using-the-threadpool-vs-creating-your-own-threads/
• متى تستخدم مجموعة سلاسل المحادثات في C #؟
• http://support.microsoft.com/kb/2538826
• http://msdn.microsoft.com/en-us/magazine /dd252943.aspx

من http://www.yoda.arachsys.com/csharp/ المواضيع / printable.shtml

يجب أن تستخدم العمليات طويلة المدى سلاسل الرسائل المنشأة حديثًا ؛ يمكن للعمليات قصيرة المدى الاستفادة من تجمع مؤشرات الترابط.

إذا كنت تريد أداءً فائقًا ، فقد يكون من المفيد التحقق من CQRS و real- المثال العالمي الموصوف كـ LMAX .

Answer 2

بدلاً من قياس إجمالي وقت سلسلة المحادثات ، قم بقياس الوقت لكل عملية من العمليات التي تقوم بها والتي تؤدي إلى إدخال / إخراج من نوع ما (قاعدة بيانات ، قرص ، شبكة ، إلخ.).

أظن أنك ستجد أن هذه العمليات هي التي تستغرق وقتًا أطول عندما يكون لديك المزيد من سلاسل الرسائل ، وذلك لأن الخلاف على الطرف الآخر من I / O.على سبيل المثال ، قد تقوم قاعدة بياناتك بترتيب طلبات تناسق البيانات بشكل تسلسلي.

Answer 3

نعم ، هناك خلاف حول الموارد. يجب على جميع الخيوط قراءة / كتابة البيانات إلى نفس ناقل الذاكرة ، موجهًا إلى نفس وحدات ذاكرة الوصول العشوائي ، على سبيل المثال. لا يهم مقدار ذاكرة الوصول العشوائي المجانية ، فمن المهم أن يتم تنفيذ عمليات القراءة / الكتابة بواسطة نفس وحدة التحكم في الذاكرة على نفس وحدات ذاكرة الوصول العشوائي ، وأن البيانات يتم نقلها عبر نفس الناقل.

إذا كان هناك أي نوع من المزامنة في أي مكان ، فهذا أيضًا مورد متنازع عليه. إذا كان هناك أي I / O ، فهذا مورد تمت مناقشته.

لن ترى تسريع N x أبدًا عند الانتقال من 1 إلى N. هذا غير ممكن لأنه في النهاية ، كل شيء في وحدة المعالجة المركزية هو مورد مشترك سيكون هناك درجة من الخلاف حوله.

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

كلمتين: الحلم على.

يجب أن تؤدي كل من هذه الاختناقات إلى إبطائك بنسبة قليلة فقط ، ومن ثم ستكون النتيجة الإجمالية شيئًا مثل ما تراه

أنا متأكد من أنه يمكنك تعديله ليتوسع قليلاً ، لكن لا تتوقع المعجزات.

ولكن هناك شيء واحد قد تبحث عنه وهو مشاركة سطر ذاكرة التخزين المؤقت. هل تصل الخيوط إلى بيانات قريبة جدًا من البيانات المستخدمة من قبل سلاسل الرسائل الأخرى؟ كم مرة يمكنك تجنب حدوث ذلك؟