اجرای پویا

اجرای پویا یک ویژگی در Bazel از نسخه 0.21 است که در آن اجرای محلی و از راه دور یک عمل به صورت موازی شروع می شود و با استفاده از خروجی اولین شاخه ای که به پایان می رسد، شاخه دیگر لغو می شود. این قدرت اجرا و/یا حافظه پنهان مشترک بزرگ یک سیستم ساخت راه دور را با تأخیر کم اجرای محلی ترکیب می‌کند و بهترین‌ها را برای ساخت‌های تمیز و افزایشی به طور یکسان ارائه می‌کند.

این صفحه نحوه فعال کردن، تنظیم و اشکال زدایی اجرای پویا را شرح می دهد. اگر هم اجرای محلی و هم از راه دور را تنظیم کرده اید و سعی می کنید تنظیمات Bazel را برای عملکرد بهتر تنظیم کنید، این صفحه برای شما مناسب است. اگر قبلاً اجرای از راه دور را تنظیم نکرده‌اید، ابتدا به نمای کلی اجرای از راه دور Bazel بروید.

اجرای پویا را فعال می کنید؟

ماژول اجرای پویا بخشی از Bazel است، اما برای استفاده از اجرای پویا، باید بتوانید هم به صورت محلی و هم از راه دور از همان تنظیمات Bazel کامپایل کنید.

برای فعال کردن ماژول اجرای پویا، پرچم --internal_spawn_scheduler را به Bazel ارسال کنید. این یک استراتژی اجرایی جدید به نام dynamic اضافه می کند. اکنون می‌توانید از این به‌عنوان استراتژی خود برای حافظه‌هایی که می‌خواهید به صورت پویا اجرا شوند، مانند --strategy=Javac=dynamic کنید. بخش بعدی را ببینید که چگونه یادداشتی را برای فعال کردن اجرای پویا انتخاب کنید.

برای هر یادداشتی که از استراتژی پویا استفاده می کند، استراتژی های اجرای از راه دور از پرچم --dynamic_remote_strategy و استراتژی های محلی از پرچم --dynamic_local_strategy است. عبور --dynamic_local_strategy=worker,sandboxed پیش‌فرض را برای شاخه محلی اجرای پویا تنظیم می‌کند تا با کارگران یا اجرای sandboxed به ترتیب آن را امتحان کند. عبور --dynamic_local_strategy=Javac=worker پیش‌فرض را فقط برای یادداشت Javac لغو می‌کند. نسخه از راه دور به همین ترتیب کار می کند. هر دو پرچم را می توان چندین بار مشخص کرد. اگر عملی را نتوان به صورت محلی اجرا کرد، به صورت عادی از راه دور اجرا می شود و بالعکس.

اگر سیستم راه دور شما یک حافظه پنهان دارد، پرچم --local_execution_delay یک تاخیر بر حسب میلی ثانیه به اجرای محلی اضافه می کند، پس از اینکه سیستم راه دور نشان می دهد ضربه حافظه پنهان شده است. با این کار از اجرای محلی در زمانی که احتمال بازدید حافظه پنهان بیشتر وجود دارد جلوگیری می شود. مقدار پیش‌فرض 1000 میلی‌ثانیه است، اما باید به گونه‌ای تنظیم شود که فقط کمی طولانی‌تر از بازدیدهای حافظه پنهان باشد. زمان واقعی هم به سیستم راه دور بستگی دارد و هم به مدت زمان یک رفت و برگشت. معمولاً، مقدار برای همه کاربران یک سیستم راه دور مشخص یکسان خواهد بود، مگر اینکه برخی از آنها به اندازه کافی دور باشند تا تاخیر رفت و برگشت را اضافه کنند. می‌توانید از ویژگی‌های نمایه‌سازی Bazel برای بررسی مدت زمان بازدید از حافظه پنهان استفاده کنید.

اجرای پویا را می توان با استراتژی محلی سندباکس و همچنین با کارگران مداوم استفاده کرد. کارگران دائمی هنگام استفاده با اجرای پویا به طور خودکار با sandboxing اجرا می شوند و نمی توانند از کارگران مالتی پلکس استفاده کنند. در سیستم‌های داروین و ویندوز، استراتژی سندباکس می‌تواند کند باشد. شما می توانید --reuse_sandbox_directories را برای کاهش هزینه های اضافی ایجاد جعبه های sandbox در این سیستم ها ارسال کنید.

اجرای پویا همچنین می‌تواند با استراتژی standalone اجرا شود، اگرچه از آنجایی که استراتژی standalone باید قفل خروجی را هنگام شروع اجرا بگیرد، به طور موثری مانع از اتمام استراتژی راه دور می‌شود. پرچم --experimental_local_lockfree_output راه حلی برای حل این مشکل با اجازه دادن به اجرای محلی برای نوشتن مستقیم در خروجی را امکان پذیر می کند، اما در صورتی که ابتدا اجرای از راه دور متوقف شود.

اگر یکی از شاخه‌های اجرای پویا اول تمام شود، اما با شکست مواجه شود، کل عمل با شکست مواجه می‌شود. این یک انتخاب عمدی برای جلوگیری از بی توجهی به تفاوت بین اجرای محلی و از راه دور است.

برای پیشینه بیشتر در مورد نحوه اجرای پویا و قفل کردن آن، به پست های وبلاگ عالی جولیو مرینو مراجعه کنید.

چه زمانی باید از اجرای پویا استفاده کنم؟

اجرای پویا به نوعی از سیستم اجرای از راه دور نیاز دارد. در حال حاضر امکان استفاده از یک سیستم راه دور فقط حافظه پنهان وجود ندارد، زیرا از دست دادن حافظه پنهان یک اقدام ناموفق در نظر گرفته می شود.

همه انواع عملکردها برای اجرای از راه دور مناسب نیستند. بهترین کاندیداها آنهایی هستند که ذاتاً در سطح محلی سریعتر هستند، به عنوان مثال از طریق استفاده از کارگران مداوم ، یا آنهایی که به اندازه کافی سریع اجرا می شوند که سربار اجرای از راه دور بر زمان اجرا غالب شود. از آنجایی که هر اقدامی که به صورت محلی اجرا می‌شود مقداری از CPU و منابع حافظه را قفل می‌کند، اجرای اقداماتی که در آن دسته‌بندی‌ها قرار نمی‌گیرند، فقط اجرای آن‌هایی را که انجام می‌دهند به تاخیر می‌اندازد.

از نسخه 5.0.0-pre.20210708.4 ، نمایه عملکرد حاوی داده‌هایی درباره اجرای کارگر است، از جمله زمان صرف شده برای تکمیل درخواست کاری پس از از دست دادن مسابقه اجرای پویا. اگر می‌بینید که رشته‌های execution worker پویا زمان قابل‌توجهی را صرف به‌دست آوردن منابع می‌کنند، یا زمان زیادی را در async-worker-finish ، ممکن است برخی اقدامات محلی کند داشته باشید که رشته‌های کارگر را به تأخیر می‌اندازد.

در نمایه بالا، که از 8 کارگر جاواک استفاده می‌کند، بسیاری از کارگران جاواک را می‌بینیم که مسابقات را از دست داده‌اند و کار خود را روی رشته‌های async-worker-finish کرده‌اند. این ناشی از یک یادداشت غیر کارگری بود که منابع کافی برای به تاخیر انداختن کارگران را مصرف می کرد.

هنگامی که فقط Javac با اجرای پویا اجرا می شود، تنها حدود نیمی از کارگران شروع شده پس از شروع کار خود رقابت را از دست می دهند.

پرچم --experimental_spawn_scheduler که قبلاً توصیه شده بود منسوخ شده است. اجرای پویا را روشن می‌کند و dynamic را به عنوان استراتژی پیش‌فرض برای تمام حافظه‌ها تنظیم می‌کند، که اغلب منجر به این نوع مشکلات می‌شود.

عیب یابی

مشکلات مربوط به اجرای پویا می‌توانند ظریف و اشکال‌زدایی آن‌ها سخت باشد، زیرا می‌توانند تنها تحت برخی ترکیب‌های خاص از اجرای محلی و از راه دور ظاهر شوند. --debug_spawn_scheduler خروجی اضافی از سیستم اجرای پویا اضافه می کند که می تواند به رفع اشکال این مشکلات کمک کند. همچنین می‌توانید پرچم --local_execution_delay و تعداد کارهای راه دور در مقابل کارهای محلی را تنظیم کنید تا بازتولید مشکلات آسان‌تر شود.

اگر در اجرای پویا با استفاده از استراتژی standalone با مشکل مواجه هستید، بدون --experimental_local_lockfree_output اجرا کنید، یا اقدامات محلی خود را به صورت جعبه ایمنی اجرا کنید. این ممکن است ساخت شما را کمی کند کند (اگر در مک یا ویندوز هستید به بالا مراجعه کنید)، اما برخی از دلایل احتمالی خرابی را حذف می کند.