عمال متعددون (ميزة تجريبية)

توضّح هذه الصفحة العاملين المتعددين، وكيفية كتابة قواعد متوافقة مع الإعلانات المتعددة، بالإضافة إلى حلول بديلة لبعض القيود.

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

نظرة عامة

هناك طبقتان بين خادم Bazel وعملية العاملين. بالنسبة إلى بعض تقنيات الذاكرة التي يمكنها تشغيل العمليات بشكل متوازٍ، يحصل Bazel على WorkerProxy من مساحة التخزين المجمّعة. يعمل WorkerProxy على إعادة توجيه الطلبات إلى عملية العامل بشكل تسلسلي مع request_id، ويعالج عامل التشغيل الطلب ويرسل الردود إلى WorkerMultiplexer. عندما يتلقّى WorkerMultiplexer استجابة، يحلّل request_id ثم يعيد توجيه الردود إلى WorkerProxy الصحيحة. وكما هو الحال مع العمّال غير المتعددين، يتم إجراء جميع الاتصالات العادية للداخل/الخارج، ولكن لا يمكن للأداة استخدام stderr للحصول على الإخراج المرئي للمستخدم (انظر أدناه).

ويكون لكل عامل مفتاح. يستخدم Bazel رمز التجزئة (المتغيّر في البيئة، وجذر التنفيذ، والتذكار) (الذي يتضمّن متغيّرات بيئة العمل)، لتحديد WorkerMultiplexer التي سيتم استخدامها. ويتواصل WorkerProxy مع WorkerMultiplexer نفسه إذا كان لديه رمز التجزئة نفسه. وبالتالي، مع افتراض أنّ متغيّرات البيئة وجذر التنفيذ واحدَين في استدعاء Bazel واحد، يمكن لكل عملية ترميز فريدة أن تكون لها عملية WorkerMultiplexer واحدة وعملية واحدة. لا يزال إجمالي عدد العمّال، بما في ذلك العمّال العاديين وWorkerProxy، محدودًا بمقدار --worker_max_instances.

كتابة قواعد متوافقة مع إشارات متعددة

يجب أن تكون عملية العامل في سلسلة سلاسل محادثات متعددة للاستفادة من العاملين المتعددين. يسمح نموذج Protobuf لمجموعة قواعد بتحليل طلب واحد على الرغم من أنه قد تكون هناك طلبات متعددة عالقة في ساحة المشاركات. وعندما يعالج العامل طلبًا من البث، يجب أن يعالج الطلب في سلسلة محادثات جديدة. وبما أنّ سلاسل المحادثات المختلفة قد تظهر دُفعة واحدة وتكمِلها إلى البث في الوقت نفسه، على المستخدم التأكّد من أنّ الردود مكتوبة بالكامل على نحو درامي (لا تتداخل الرسائل). يجب أن تحتوي الردود على request_id من الطلب الذي يعالجونه.

معالجة النتائج المتعددة

يحتاج العاملون المتعددون إلى توخي الحذر أكثر في التعامل مع نتائجهم أكثر من العاملين الفرديين. سيتم إرسال أي ملف يتم إرساله إلى stderr في ملف سجلّ واحد تتم مشاركته بين جميع WorkerProxy من النوع نفسه، بشكل متداخل بين الطلبات المتزامنة. في حين أنّ إعادة توجيه stdout إلى stderr فكرة جيدة، لا تجمع هذا الإخراج في الحقل output في WorkResponse، حيث يمكن أن يعرض ذلك مخرجات المستخدم المشوّهة. إذا كانت الأداة تُرسل نتائج موجّهة للمستخدمين فقط إلى stdout أو stderr، عليك تغيير هذا السلوك قبل أن تتمكّن من تفعيل خدمات الإعلانات المتعددة.

تمكين العاملين المتعددين

ولا يتم تفعيل العاملين المتعددين بشكل تلقائي. ويمكن أن تُفعّل مجموعة قواعد العاملين المتعددين باستخدام العلامة supports-multiplex-workers في execution_requirements من الإجراء (تمامًا كما تتيح العلامة supports-workers العاملين المعتادين). كما هو الحال عند استخدام العاملين العاديين، يجب تحديد استراتيجية العامل، إما على مستوى القواعد (على سبيل المثال، --strategy=[some_mnemonic]=worker) أو بشكل عام على مستوى الاستراتيجية (على سبيل المثال، --dynamic_local_strategy=worker,standalone). ولا يلزم استخدام علامات أخرى، وتكون الأولوية supports-multiplex-workers على supports-workers، في حال ضبط كليهما. يمكن إيقاف العاملين المتعددين على مستوى العالم من خلال تمرير --noexperimental_worker_multiplex.

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

وضع الحماية متعدد

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

لإتاحة وضع الحماية المتعدد، يجب أن يستخدم العامل الحقل sandbox_dir من WorkRequest واستخدامه كبادئة لجميع عمليات قراءة الملفات وكتابتها. على الرغم من أن الحقلين arguments وinputs لا يتغيّران من طلب بدون وضع الحماية، إلا أنّ المدخلات الفعلية ذات صلة بالنطاق sandbox_dir. على العامل ترجمة مسارات الملفات المتوفّرة في arguments وinputs لقراءتها من هذا المسار المعدَّل، ويجب أيضًا كتابة جميع النتائج بالاستناد إلى sandbox_dir. ويتضمّن ذلك مسارات مثل ''، بالإضافة إلى المسارات المتوفّرة في الملفات المحدّدة في الوسيطات (مثل "argfile").

وعندما يدعم العامل وضع الحماية المتعدد، يمكن للمجموعة الإعلان عن هذا الدعم عن طريق إضافة supports-multiplex-sandboxing إلى execution_requirementsمن الإجراء. سيستخدم Bazel بعد ذلك وضع الحماية المتعدد في حال اجتياز العلامة --experimental_worker_multiplex_sandboxing، أو في حال استخدام العامل مع التنفيذ الديناميكي.

لا تزال ملفات العامل للعاملين المتعددين في وضع الحماية مرتبطة بدليل العمل للعملة. وبالتالي، إذا تم استخدام ملف لتشغيل عامل التشغيل وكإدخال، يجب تحديده على أنّه إدخال في وسيطة علامة الملف وكذلك في tools أو executable أو runfiles.