اشکال زدایی بازدیدهای حافظه پنهان از راه دور برای اجرای از راه دور

در این صفحه نحوه بررسی میزان ضربه حافظه پنهان و نحوه بررسی عدم دسترسی به حافظه پنهان در زمینه اجرای از راه دور توضیح داده شده است.

این صفحه فرض می کند که شما یک ساخت و/یا آزمایشی دارید که با موفقیت از اجرای از راه دور استفاده می کند، و می خواهید مطمئن شوید که به طور موثر از حافظه پنهان از راه دور استفاده می کنید.

بررسی نرخ ضربه حافظه پنهان

در خروجی استاندارد اجرای Bazel خود، به خط INFO نگاه کنید که فرآیندها را فهرست می کند، که تقریباً با اقدامات Bazel مطابقت دارد. آن خط جزئیات محل اجرای اکشن را نشان می دهد. به دنبال برچسب remote بگردید، که یک عمل اجرا شده از راه دور، linux-sandbox را برای اقدامات اجرا شده در جعبه ایمنی محلی، و مقادیر دیگر را برای سایر استراتژی‌های اجرایی نشان می‌دهد. عملی که نتیجه آن از یک حافظه پنهان از راه دور حاصل شده است به عنوان remote cache hit نمایش داده می شود.

مثلا:

INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.

در این مثال 6 ضربه کش از راه دور وجود داشت و 2 اکشن بازدید از حافظه پنهان نداشتند و از راه دور اجرا شدند. 3 قسمت داخلی را می توان نادیده گرفت. این معمولاً اقدامات داخلی کوچکی است، مانند ایجاد پیوندهای نمادین. بازدیدهای حافظه پنهان محلی در این خلاصه گنجانده نشده است. اگر 0 فرآیند دریافت می کنید (یا تعداد کمتر از حد انتظار)، bazel clean و سپس دستور ساخت/تست خود را اجرا کنید.

عیب یابی بازدیدهای حافظه پنهان

اگر نرخ ضربه کش مورد انتظار را دریافت نمی کنید، موارد زیر را انجام دهید:

اطمینان حاصل کنید که اجرای مجدد همان دستور ساخت/تست باعث ایجاد بازدید در حافظه پنهان می شود

1. ساخت(ها) و/یا تست(هایی) را که انتظار دارید کش را پر کند اجرا کنید. اولین باری که یک بیلد جدید روی یک پشته خاص اجرا می‌شود، نمی‌توانید انتظار داشته باشید که کش از راه دور مورد بازدید قرار نگیرد. به عنوان بخشی از اجرای از راه دور، نتایج عملیات در حافظه پنهان ذخیره می‌شوند و اجرای بعدی باید آنها را انتخاب کند.

2. bazel clean اجرا کنید. این دستور کش محلی شما را پاک می کند، که به شما امکان می دهد تا بازدیدهای حافظه پنهان از راه دور را بدون اینکه نتایج توسط بازدیدهای حافظه پنهان محلی پوشانده شود، بررسی کنید.

3. ساخت(های) و تست(هایی) که در حال بررسی آن هستید را مجددا اجرا کنید (روی همان ماشین).

4. خط INFO را برای نرخ ضربه حافظه پنهان بررسی کنید. اگر هیچ پردازشی به جز remote cache hit و internal نمی بینید، کش شما به درستی پر شده و به آن دسترسی پیدا می کند. در این صورت به بخش بعدی بروید.

5. یک منبع احتمالی ناسازگاری، چیزی غیرهرماتیک در ساخت است که باعث می‌شود اکشن‌ها کلیدهای عمل متفاوتی را در دو اجرا دریافت کنند. برای یافتن این اقدامات، موارد زیر را انجام دهید:

   آ. برای به دست آوردن گزارش های اجرایی، ساخت(ها) یا تست(های) مورد نظر را مجددا اجرا کنید:

     bazel clean
     bazel --optional-flags build //your:target --execution_log_binary_file=/tmp/exec1.log
   

   ب گزارش های اجرا را بین دو اجرا مقایسه کنید. اطمینان حاصل کنید که اقدامات در دو فایل گزارش یکسان هستند. اختلافات سرنخی در مورد تغییراتی که بین اجراها رخ داده است ارائه می دهد. برای از بین بردن این اختلافات، ساخت خود را به روز کنید.

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

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

   اگر نیازی به تفاوت لاگ های اجرا ندارید، می توانید به جای آن از پرچم --execution_log_json_file قابل خواندن توسط انسان استفاده کنید. نمی توان از آن برای تغییر پایدار استفاده کرد زیرا دارای زمان اجرا است و سفارش را تضمین نمی کند.

6. بررسی کنید که تمام اقدامات در گزارش اجرا دارای قابلیت ذخیره سازی روی cacheable باشد. اگر cacheable در گزارش اجرا برای یک اکشن داده نمی‌شود، به این معنی است که قانون مربوطه ممکن است یک برچسب no-cache در فایل BUILD داشته باشد. به فیلد progress_message قابل خواندن توسط انسان در گزارش اجرا نگاه کنید تا تعیین کنید که این عمل از کجا انجام می شود.

7. اگر اکشن‌ها یکسان و cacheable ذخیره‌سازی هستند، اما هیچ بازدیدی از حافظه پنهان وجود ندارد، ممکن است خط فرمان شما شامل --noremote_accept_cached که جستجوهای کش را برای یک ساخت غیرفعال می‌کند.

   اگر تشخیص خط فرمان واقعی دشوار است، از خط فرمان متعارف از پروتکل Build Event به صورت زیر استفاده کنید:

   آ. --build_event_text_file=/tmp/bep.txt را به دستور Bazel خود اضافه کنید تا نسخه متنی گزارش را دریافت کنید.

   ب نسخه متنی گزارش را باز کنید و پیام structured_command_line را با command_line_label: "canonical" جستجو کنید. تمام گزینه ها را پس از گسترش فهرست می کند.

   ج remote_accept_cached را جستجو کنید و بررسی کنید که آیا روی false تنظیم شده است یا خیر.

   د اگر remote_accept_cached false است، تعیین کنید که کجا روی false تنظیم شده است: در خط فرمان یا در فایل bazelrc .

از ذخیره سازی در دستگاه ها اطمینان حاصل کنید

پس از اینکه بازدیدهای حافظه نهان همانطور که انتظار می رود در یک دستگاه اتفاق افتاد، همان ساخت(ها)/تست(ها) را در دستگاه دیگری اجرا کنید. اگر مشکوک هستید که کش کردن در دستگاه‌ها انجام نمی‌شود، موارد زیر را انجام دهید:

1. برای جلوگیری از ضربه زدن به حافظه پنهان موجود، یک اصلاح کوچک در ساخت خود ایجاد کنید.

2. بیلد را روی اولین ماشین اجرا کنید:

    bazel clean
    bazel ... build ... --execution_log_binary_file=/tmp/exec1.log
   

3. ساخت را بر روی ماشین دوم اجرا کنید، مطمئن شوید که اصلاحات مرحله 1 گنجانده شده است:

    bazel clean
    bazel ... build ... --execution_log_binary_file=/tmp/exec2.log
   

4. گزارش های اجرا را برای دو اجرا مقایسه کنید. اگر گزارش‌ها یکسان نیستند، پیکربندی‌های ساخت خود را از نظر مغایرت‌ها و همچنین ویژگی‌های محیط میزبان که به هر یک از ساخت‌ها نشت می‌کند، بررسی کنید.

مقایسه لاگ های اجرایی

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

برای مقایسه گزارش‌ها برای دو بیلد که طبق انتظار، بازدیدهای کش را به اشتراک نمی‌گذارند، موارد زیر را انجام دهید:

1. گزارش های اجرایی را از هر بیلد دریافت کنید و آنها را به صورت /tmp/exec1.log و /tmp/exec2.log کنید.

2. کد منبع Bazel را دانلود کرده و با استفاده از دستور زیر به پوشه Bazel بروید. برای تجزیه لاگ های اجرا با تجزیه کننده execlog به کد منبع نیاز دارید.

   git clone https://github.com/bazelbuild/bazel.git
   cd bazel
   

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

   bazel build src/tools/execlog:parser
   bazel-bin/src/tools/execlog/parser \
     --log_path=/tmp/exec1.log \
     --log_path=/tmp/exec2.log \
     --output_path=/tmp/exec1.log.txt \
     --output_path=/tmp/exec2.log.txt
   

4. از متن دلخواه خود برای تفاوت /tmp/exec1.log.txt و /tmp/exec2.log.txt استفاده کنید.