حجم مجموعة الخيوط الأمثل

خطوات الاستخدام

الخطوة 1: أدخل عدد نوى وحدة المعالجة المركزية (CPU Cores) المتاحة. هذا الرقم يمثل الحد الأقصى من العمليات المتوازية التي يمكن تشغيلها في وقت واحد دون حدوث تعارض في الموارد. للحصول على أفضل أداء، يجب أن يكون عدد النوى الفعلية (وليس الخيوط المنطقية) لأن الخيوط الفائقة (Hyper-Threading) قد لا توفر ضعف الأداء الحقيقي في المهام الحسابية المكثفة.

الخطوة 2: أدخل نسبة الانتظار للإدخال/الإخراج (I/O Wait Ratio) كنسبة مئوية أو عشرية. تمثل هذه النسبة الوقت الذي تنتظر فيه الخيوط حدوث عمليات الإدخال/الإخراج مثل قراءة الملفات أو الشبكة. على سبيل المثال، إذا كان الخيط ينتظر 50% من الوقت، فالقيمة تكون 0.5. يمكن قياس هذه النسبة باستخدام أدوات مراقبة النظام مثل 'top' أو 'perf'.

الخطوة 3: حساب حجم مجموعة الخيوط الأمثل باستخدام الصيغة: `الخيوط المثلى = عدد النوى × (1 + نسبة الانتظار)`. هذه الصيغة مشتقة من نموذج قائمة الانتظار (Queueing Model) حيث تسمح الخيوط الإضافية بتغطية وقت الانتظار دون إغراق المعالج. على سبيل المثال، إذا كان لديك 4 نوى ونسبة انتظار 0.75، فسيكون الحجم الأمثل = 4 × (1 + 0.75) = 7 خيوط.

الأسئلة الشائعة

الصيغة المستخدمة (`الخيوط المثلى = عدد النوى × (1 + نسبة الانتظار)`) تستند إلى نموذج رياضي مبسط لتحليل قوائم الانتظار، وتحديدًا نظرية ليتل (Little's Law) وتطبيقاتها على أنظمة متعددة الخيوط. تنص نظرية ليتل على أن متوسط عدد العناصر في النظام (L) يساوي متوسط معدل الوصول (λ) مضروبًا في متوسط وقت الاستجابة (W). في سياق الخيوط، يمكن اعتبار الخيوط نفسها كعناصر. نسبة الانتظار (W) تمثل الكسر من الوقت الذي يكون فيه الخيط في حالة انتظار I/O. إذا كان الخيط مشغولًا بالمعالجة لمدة زمنية C، وينتظر لمدة W (حيث W = نسبة الانتظار × الوقت الإجمالي)، فإن الوقت الإجمالي للخيط هو C + W. لكي تكون وحدة المعالجة المركزية مشغولة باستمرار، يجب أن يكون عدد الخيوط كافيًا لتغطية وقت الانتظار. لذا، إذا كان لدينا n من النوى، نحتاج إلى n من الخيوط لتغطية وقت المعالجة، بالإضافة إلى خيوط إضافية لتغطية وقت الانتظار. عدد الخيوط الإضافية يساوي n × (W/C). لكن غالبًا ما يتم التعبير عن نسبة الانتظار ككسر من الوقت الإجمالي (P = W / (C+W))، وبعد بعض الاشتقاقات، نحصل على الصيغة n × (1 + P) عندما يكون C وW متساويين في الحجم؟ في الواقع، الصيغة الشائعة في المجتمع هي `الخيوط المثلى = عدد النوى × (1 + (وقت الانتظار ÷ وقت المعالجة))`. حيث R = وقت الانتظار / وقت المعالجة. إذا كان وقت الانتظار يساوي وقت المعالجة، فإن R = 1، وبالتالي الخيوط = 2n. إذا كان وقت الانتظار صفرًا (R=0)، فالخيوط = n. إذا كان وقت الانتظار كبيرًا جدًا، فإن الخيوط تزداد خطيًا. لكن الصيغة التي نستخدمها في الآلة الحاسبة تفترض أن `نسبة الانتظار` هي P = وقت الانتظار / (وقت الانتظار + وقت المعالجة). في هذه الحالة، يمكن اشتقاق R = P/(1-P)، وبالتالي الخيوط = n × (1 + P/(1-P)) = n / (1-P). هذا مختلف عن الصيغة السابقة. يجب توخي الحذر: الإدخال المطلوب هنا هو `ioWaitRatio` وهو النسبة المئوية للوقت الذي ينتظر فيه الخيط I/O (أي P). لذا الصيغة الصحيحة قد تكون `الخيوط = عدد النوى / (1 - P)`. لكن العديد من المصادر تستخدم الصيغة n*(1+P) كتقريب مبسط عندما يكون P صغيرًا. لتكون دقيقة، سنستخدم الصيغة الأكثر دقة: `الخيوط المثلى = عدد النوى / (1 - نسبة الانتظار)` حيث نسبة الانتظار بين 0 و 1. لذلك، في الآلة الحاسبة، يجب توضيح أن الإدخال هو النسبة المئوية (0-1) أو النسبة المئوية (0-100%). سنستخدم الصيغة الصحيحة: `optimalThreads = cpuCores / (1 - ioWaitRatio)`. لضمان الدقة، تتمثل النظرية الأساسية في أن كل خيط يستغرق وقتًا معينًا للتنفيذ (C) ووقت انتظار (W). لتعظيم الإنتاجية، يجب أن يكون إجمالي وقت وحدة المعالجة المركزية المشغول مساويًا لعدد النوى مضروبًا في الوقت المنقضي. يؤدي هذا إلى معادلة توازن تنشئ العلاقة المذكورة أعلاه.

التبديل الزائد للسياق (Context Switching) هو عملية حفظ واستعادة حالة الخيط الحالية عند التبديل بين خيوط مختلفة. كلما زاد عدد الخيوط عن العدد الأمثل، زادت هذه العملية مما يؤدي إلى إضاعة وقت المعالج في التبديل بدلاً من تنفيذ المهام الفعلية. التبديل له تكلفة: عادةً ما يستغرق بضع ميكروثوانٍ، وإذا حدث آلاف المرات في الثانية، يمكن أن يستهلك قدرًا كبيرًا من وحدة المعالجة المركزية. علاوة على ذلك، يؤدي التبديل إلى تعطيل ذاكرة التخزين المؤقت (Cache)، مما يسبب اختفاء (Cache Miss) وإعادة تحميل البيانات، مما يقلل الأداء بشكل أكبر. لتجنب ذلك، يجب حساب الحجم الأمثل لمجموعة الخيوط باستخدام الصيغ المناسبة بناءً على طبيعة عبء العمل. بالإضافة إلى ذلك، يمكن استخدام تقنيات مثل تجميع الخيوط (Thread Pooling) مع حجم ثابت، أو استخدام خوارزميات ضبط ديناميكية تراقب استخدام وحدة المعالجة المركزية ومعدل التبديل. من الممارسات الجيدة أيضًا استخدام مآخذ (Sockets) غير محظورة (Non-blocking) لتقليل وقت الانتظار، وبالتالي تقليل الحاجة إلى خيوط إضافية.

قانون أمدال هو مبدأ أساسي في الحوسبة المتوازية ينص على أن التَسريع (Speedup) الناتج عن التوازي محدود بالجزء التسلسلي من البرنامج. إذا كان الكسر S من البرنامج تسلسليًا ولا يمكن تنفيذه بالتوازي، والكسر P متوازي، فإن أقصى تسريع يمكن تحقيقه باستخدام N معالجًا هو `1 / (S + P/N)`، وعندما يؤول N إلى ما لا نهاية، فإن أقصى تسريع هو `1/S`. في سياق حجم مجموعة الخيوط، يذكرنا قانون أمدال بعدم جدوى إضافة عدد كبير جدًا من الخيوط إذا كان هناك جزء كبير تسلسلي. على سبيل المثال، إذا كان 10% من البرنامج تسلسليًا، فإن أقصى تسريع هو 10 أضعاف بغض النظر عن عدد الخيوط. لذلك، حساب حجم مجموعة الخيوط لا يعتمد فقط على نسبة انتظار I/O، بل أيضًا على درجة التوازي. ومع ذلك، في الممارسة العملية، غالبًا ما يتم نمذجة تطبيقات الخادم باستخدام نموذج الإدخال/الإخراج حيث يكون التوازي مرتفعًا. لذا، فإن الصيغة الأساسية (الخيوط = النوى / (1 - ioWait)) تأخذ في الاعتبار الجزء المتوازي ضمنيًا من خلال قياس وقت الانتظار. لكن إذا كان هناك جزء تسلسلي كبير، فقد تكون الخيوط المثلى أقل مما تقترحه الصيغة. يمكن تحسين النموذج عن طريق دمج عامل التوازي: `الخيوط المثلى = عدد النوى × (1 / (1 - ioWait × (1 - serialFraction)))`? في الواقع، هناك تعقيدات إضافية. كقاعدة عامة، يجب أن يكون عدد الخيوط في حدود معقولة (لا يتجاوز عدة أضعاف عدد النوى) لتجنب التبديل الزائد، وقانون أمدال يحدد السقف الأعلى للاستفادة.

هذه الصيغة مناسبة بشكل أساسي للتطبيقات التي تكون فيها الخيوط متجانسة (Homogeneous) وتؤدي نفس النوع من المهام، مثل خوادم الويب وخوادم قواعد البيانات. كما تفترض الصيغة أن الخيوط لا تشارك الموارد بشكل كبير أو تتنافس على أقفال (Locks). في حالة وجود تنافس على الموارد المشتركة، قد يؤدي زيادة عدد الخيوط إلى تفاقم الاختناقات (Bottlenecks) بسبب انتظار الأقفال، مما يقلل الأداء بدلاً من تحسينه. بالإضافة إلى ذلك، إذا كانت الخيوط تؤدي مهامًا ذات أوقات تنفيذ مختلفة جدًا (غير متجانسة)، فقد لا تكون الصيغة دقيقة. أيضًا، في الأنظمة ذات الذاكرة المحدودة، قد يتسبب عدد كبير من الخيوط في زيادة استخدام الذاكرة بشكل كبير (كل خيط له مكدس Stack خاص به)، مما يؤدي إلى نقص الذاكرة وزيادة استخدام المبادلة (Swapping). أخيرًا، إذا كانت نسبة انتظار I/O قريبة جدًا من 1 (مثل 0.99)، فستعطي الصيغة عددًا كبيرًا جدًا من الخيوط (على سبيل المثال، 100 خيط لنوى 4)، وهو أمر غير عملي في الواقع بسبب تبديل السياق. في مثل هذه الحالات، يجب استخدام نماذج غير متزامنة (Asynchronous) مثل الإدخال/الإخراج غير المحظور (Non-blocking I/O) أو coroutines لتقليل عدد الخيوط.

حجم مجموعة الخيوط الأمثل

أدخل القيم

خطوات الاستخدام

أمثلة محلولة

أمثلة محسوبة

الأسئلة الشائعة

أدخل القيم

خطوات الاستخدام

حاسبات ذات صلة

1مثال 1: لدينا خادم ويب به 8 نوى CPU، ونسبة انتظار I/O تساوي 80% (0.8) بسبب عمليات قاعدة البيانات البطيئة. ما هو حجم مجموعة الخيوط الأمثل؟

2مثال 2: تطبيق لعرض الصور يحتوي على 4 نوى CPU، ونسبة انتظار I/O منخفضة جدًا تبلغ 10% (0.1) لأن العمليات الحسابية هي المهيمنة. احسب حجم مجموعة الخيوط واشرح التأثير.

أمثلة محسوبة

الأسئلة الشائعة