การดำเนินการแบบไดนามิกเป็นฟีเจอร์ใน Bazel ที่จะเริ่มการดำเนินการในเครื่องและระยะไกลของ การดำเนินการเดียวกันแบบขนาน โดยใช้เอาต์พุตจาก Branch แรกที่ เสร็จสิ้นและยกเลิก Branch อื่นๆ โดยจะรวมความสามารถในการดำเนินการ และ/หรือแคชที่แชร์ขนาดใหญ่ของระบบบิลด์ระยะไกลเข้ากับเวลาในการตอบสนองที่ต่ำของการดำเนินการในเครื่อง ซึ่งจะมอบสิ่งที่ดีที่สุดจากทั้ง 2 อย่างสำหรับการบิลด์ที่สะอาดและแบบเพิ่มทีละรายการ
หน้านี้จะอธิบายวิธีเปิดใช้ ปรับแต่ง และแก้ไขข้อบกพร่องของการดำเนินการแบบไดนามิก หากคุณตั้งค่าการดำเนินการทั้งในเครื่องและระยะไกล และพยายามปรับการตั้งค่า Bazel เพื่อให้มีประสิทธิภาพดียิ่งขึ้น หน้านี้เหมาะสำหรับคุณ หากยังไม่ได้ตั้งค่าการดำเนินการจากระยะไกล ให้ไปที่ภาพรวมการดำเนินการจากระยะไกลของ Bazel ก่อน
เปิดใช้การดำเนินการแบบไดนามิกไหม
โมดูลการดำเนินการแบบไดนามิกเป็นส่วนหนึ่งของ Bazel แต่หากต้องการใช้การดำเนินการแบบไดนามิก คุณต้องคอมไพล์ทั้งในเครื่องและจากระยะไกลได้จากการตั้งค่า Bazel เดียวกัน
หากต้องการเปิดใช้โมดูลการดำเนินการแบบไดนามิก ให้ส่งแฟล็ก --internal_spawn_scheduler
ไปยัง Bazel ซึ่งจะเพิ่มกลยุทธ์การดำเนินการใหม่ที่เรียกว่า dynamic ตอนนี้คุณสามารถ
ใช้สิ่งนี้เป็นกลยุทธ์สำหรับมินิเกมที่คุณต้องการเรียกใช้แบบไดนามิกได้ เช่น
--strategy=Javac=dynamic ดูวิธีเลือกนิโมนิก
ที่จะเปิดใช้การดำเนินการแบบไดนามิกได้ในส่วนถัดไป
สำหรับ Mnemonic ที่ใช้กลยุทธ์แบบไดนามิก กลยุทธ์การดำเนินการระยะไกลจะ นำมาจากแฟล็ก --dynamic_remote_strategy และกลยุทธ์ในเครื่องจะนำมาจากแฟล็ก --dynamic_local_strategy การส่งผ่าน
--dynamic_local_strategy=worker,sandboxed จะตั้งค่าเริ่มต้นสำหรับ Branch ในเครื่อง
ของการดำเนินการแบบไดนามิกเพื่อลองใช้กับผู้ปฏิบัติงาน หรือการดำเนินการแบบแซนด์บ็อกซ์ตามลำดับ การส่ง --dynamic_local_strategy=Javac=worker จะลบล้างค่าเริ่มต้นสำหรับ
ตัวช่วยจำของ Javac เท่านั้น โดยเวอร์ชันระยะไกลจะทำงานในลักษณะเดียวกัน ทั้ง 2 แฟล็กสามารถ
ระบุได้หลายครั้ง หากดำเนินการในเครื่องไม่ได้ ระบบจะดำเนินการจากระยะไกลตามปกติ และในทางกลับกัน
หากระบบระยะไกลมีแคช แฟล็ก--dynamic_local_execution_delayจะเพิ่มการหน่วงเวลาเป็นมิลลิวินาทีในการดำเนินการในเครื่องหลังจากที่ระบบระยะไกลระบุว่าพบแคช ซึ่งจะช่วยหลีกเลี่ยงการเรียกใช้การดำเนินการในเครื่องเมื่อมีโอกาสที่แคชจะตรงกันมากขึ้น
ค่าเริ่มต้นคือ 1, 000 มิลลิวินาที แต่ควรปรับให้ยาวกว่าเวลาที่แคชฮิตใช้เล็กน้อย
เวลาจริงจะขึ้นอยู่กับทั้งระบบระยะไกล
และระยะเวลาที่ใช้ในการรับส่งข้อมูล โดยปกติ ค่าจะเหมือนกัน
สำหรับผู้ใช้ทั้งหมดของระบบระยะไกลที่กำหนด เว้นแต่ผู้ใช้บางรายจะอยู่ไกลพอ
ที่จะเพิ่มเวลาในการตอบสนองแบบไปกลับ คุณสามารถใช้ฟีเจอร์การทำโปรไฟล์ Bazel เพื่อดูระยะเวลาที่แคชฮิตทั่วไปใช้
การดำเนินการแบบไดนามิกสามารถใช้กับกลยุทธ์แซนด์บ็อกซ์ในเครื่องได้เช่นเดียวกับWorker แบบถาวร Worker แบบถาวรจะทำงานโดยอัตโนมัติ
ด้วยแซนด์บ็อกซ์เมื่อใช้กับการดำเนินการแบบไดนามิก และใช้ Worker แบบมัลติเพล็กซ์ไม่ได้ ในระบบ Darwin และ Windows กลยุทธ์ที่อยู่ในแซนด์บ็อกซ์อาจทำงานช้า คุณสามารถส่ง --reuse_sandbox_directories เพื่อลดค่าใช้จ่ายในการสร้างแซนด์บ็อกซ์ในระบบเหล่านี้ได้
การดำเนินการแบบไดนามิกยังสามารถเรียกใช้กับstandaloneได้ด้วย แม้ว่าstandaloneจะต้องล็อกเอาต์พุตเมื่อเริ่มดำเนินการ ซึ่งจะบล็อกไม่ให้กลยุทธ์ระยะไกลเสร็จสิ้นก่อน แฟล็ก
--experimental_local_lockfree_outputช่วยแก้ปัญหานี้ได้โดย
อนุญาตให้การดำเนินการในเครื่องเขียนไปยังเอาต์พุตได้โดยตรง แต่จะถูกยกเลิกโดย
การดำเนินการจากระยะไกลหากการดำเนินการนั้นเสร็จก่อน
หากสาขาใดสาขาหนึ่งของการดำเนินการแบบไดนามิกเสร็จสิ้นก่อน แต่ไม่สำเร็จ การดำเนินการทั้งหมดจะไม่สำเร็จ เราตั้งใจเลือกใช้การดำเนินการนี้เพื่อป้องกันไม่ให้ความแตกต่าง ระหว่างการดำเนินการในเครื่องและการดำเนินการจากระยะไกลถูกมองข้าม
ดูข้อมูลพื้นฐานเพิ่มเติมเกี่ยวกับวิธีที่การดำเนินการแบบไดนามิกและการล็อกทำงานได้ในบล็อก โพสต์ที่ยอดเยี่ยมของ Julio Merino
ฉันควรใช้การดำเนินการแบบไดนามิกเมื่อใด
การดำเนินการแบบไดนามิกต้องใช้ระบบการดำเนินการระยะไกลในรูปแบบใดรูปแบบหนึ่ง ขณะนี้คุณยังใช้ระบบระยะไกลที่แคชเท่านั้นไม่ได้ เนื่องจากไม่พบแคชจะถือว่าเป็นการดำเนินการที่ไม่สำเร็จ
การดำเนินการบางประเภทอาจไม่เหมาะกับการดำเนินการจากระยะไกล ตัวเลือกที่ดีที่สุดคือตัวเลือกที่ทำงานได้เร็วกว่าในเครื่อง เช่น ผ่านการใช้Worker แบบถาวร หรือตัวเลือกที่ทำงานได้เร็วพอที่ค่าใช้จ่ายในการดำเนินการจากระยะไกลจะครอบงำเวลาในการดำเนินการ เนื่องจาก การดำเนินการแต่ละอย่างที่ดำเนินการในเครื่องจะล็อกทรัพยากร CPU และหน่วยความจำจำนวนหนึ่ง การเรียกใช้การดำเนินการที่ไม่ได้อยู่ในหมวดหมู่เหล่านั้นจะเพียงทำให้การดำเนินการ สำหรับหมวดหมู่ที่อยู่ในนั้นล่าช้า
ตั้งแต่รุ่น
5.0.0-pre.20210708.4
การสร้างโปรไฟล์ประสิทธิภาพจะมีข้อมูล
เกี่ยวกับการดำเนินการของ Worker รวมถึงเวลาที่ใช้ในการคำของานหลังจาก
แพ้การแข่งขันการดำเนินการแบบไดนามิก หากเห็นว่าเธรดของ Worker การดำเนินการแบบไดนามิกใช้เวลามากในการรับทรัพยากร หรือใช้เวลามากในasync-worker-finish คุณอาจมีการกระทำเกี่ยวกับสถานที่ที่ช้าซึ่งทำให้เธรดของ Worker ล่าช้า
ในโปรไฟล์ด้านบนซึ่งใช้ Worker ของ Javac 8 ราย เราเห็น Worker ของ Javac หลายราย
แพ้การแข่งขันและทำงานเสร็จในasync-worker-finish
เธรด ปัญหานี้เกิดจากมnemonic ที่ไม่ใช่ Worker ใช้ทรัพยากรมากพอที่จะ
ทำให้ Worker ทำงานช้าลง
เมื่อเรียกใช้ Javac เท่านั้นด้วยการดำเนินการแบบไดนามิก มีเพียงครึ่งหนึ่งของ Worker ที่เริ่มต้น เท่านั้นที่แพ้การแข่งขันหลังจากเริ่มงาน
ระบบเลิกใช้งานฟีเจอร์--experimental_spawn_schedulerที่แนะนำก่อนหน้านี้แล้ว
ซึ่งจะเปิดการดำเนินการแบบไดนามิกและตั้งค่า dynamic เป็นกลยุทธ์เริ่มต้นสำหรับ
นิโมนิกทั้งหมด ซึ่งมักจะทำให้เกิดปัญหาในลักษณะนี้
ประสิทธิภาพ
แนวทางการดำเนินการแบบไดนามิกจะถือว่ามีทรัพยากรเพียงพอทั้งในเครื่องและระยะไกล จึงคุ้มค่าที่จะใช้ทรัพยากรเพิ่มเติมเพื่อปรับปรุง ประสิทธิภาพโดยรวม แต่การใช้ทรัพยากรมากเกินไปอาจทำให้ Bazel เองหรือเครื่องที่ Bazel ทำงานช้าลง หรือสร้างภาระที่ไม่คาดคิดให้กับระบบระยะไกล คุณมี ตัวเลือกหลายอย่างในการเปลี่ยนลักษณะการทำงานของการดำเนินการแบบไดนามิก ดังนี้
--dynamic_local_execution_delay จะหน่วงเวลาการเริ่มต้นของสาขาในเครื่องเป็นจำนวน มิลลิวินาทีหลังจากที่สาขาระยะไกลเริ่มต้นแล้ว แต่จะทำเช่นนี้ก็ต่อเมื่อมี การพบแคชระยะไกลในระหว่างการสร้างปัจจุบันเท่านั้น ซึ่งจะช่วยให้บิลด์ที่ได้รับประโยชน์
จากการแคชระยะไกลไม่สิ้นเปลืองทรัพยากรในเครื่องเมื่อมีแนวโน้มว่าเอาต์พุตส่วนใหญ่
จะอยู่ในแคช การลดขนาดแคชอาจช่วยเพิ่มความเร็วในการบิลด์ได้ แต่ต้องแลกมาด้วยการใช้ทรัพยากรในเครื่องมากขึ้น ทั้งนี้ขึ้นอยู่กับคุณภาพของแคช
--experimental_dynamic_local_load_factor เป็นตัวเลือกการจัดการทรัพยากรขั้นสูงเวอร์ชันทดลอง
โดยมีค่าตั้งแต่ 0 ถึง 1 และ 0 จะเป็นการปิดฟีเจอร์นี้
เมื่อตั้งค่าเป็นค่าที่มากกว่า 0 Bazel จะปรับจำนวนการดำเนินการที่กำหนดเวลาไว้ในเครื่องเมื่อมีการดำเนินการจำนวนมากที่รอการกำหนดเวลา การตั้งค่าเป็น 1 จะช่วยให้กำหนดเวลาการดำเนินการได้มากเท่าที่ CPU พร้อมใช้งาน (ตาม --local_cpu_resources) ส่วนค่าที่ต่ำกว่าจะกำหนดจำนวนการดำเนินการที่กำหนดเวลาไว้ให้ลดลงตามนั้นเมื่อมีการดำเนินการจำนวนมากขึ้นพร้อมให้เรียกใช้ แม้จะฟังดูขัดกับสัญชาตญาณ แต่หากมีระบบระยะไกลที่ดี การดำเนินการในเครื่องก็ไม่ได้ช่วยอะไรมากนักเมื่อมีการดำเนินการหลายอย่าง และควรใช้ CPU ในเครื่องเพื่อจัดการการดำเนินการระยะไกลจะดีกว่า
--experimental_dynamic_slow_remote_time ให้ความสำคัญกับการเริ่มต้น Branch ในเครื่อง
เมื่อ Branch ระยะไกลทำงานมาอย่างน้อยตามระยะเวลานี้ โดยปกติแล้ว การดำเนินการที่กำหนดเวลาล่าสุดจะมีลำดับความสำคัญ เนื่องจากมีโอกาสมากที่สุดที่จะ ชนะการแข่งขัน แต่หากระบบระยะไกลค้างหรือใช้เวลานานเป็นพิเศษในบางครั้ง การดำเนินการนี้จะช่วยให้การสร้างดำเนินต่อไปได้ ฟีเจอร์นี้ไม่ได้เปิดใช้โดยค่าเริ่มต้นเนื่องจากอาจซ่อนปัญหาเกี่ยวกับระบบระยะไกลที่ควรได้รับการแก้ไข โปรดตรวจสอบประสิทธิภาพของระบบระยะไกลหากเปิดใช้ตัวเลือกนี้
--experimental_dynamic_ignore_local_signals ใช้เพื่ออนุญาตให้สาขาที่อยู่ระยะไกลเข้าควบคุมเมื่อกระบวนการย่อยในเครื่องสิ้นสุดเนื่องจากสัญญาณที่กำหนด ซึ่งมีประโยชน์อย่างยิ่งเมื่อใช้ร่วมกับขีดจำกัดทรัพยากรของ Worker (ดู --experimental_worker_memory_limit_mb, --experimental_worker_sandbox_hardening และ --experimental_sandbox_memory_limit_mb) ซึ่งกระบวนการของ Worker อาจถูกปิดเมื่อใช้ทรัพยากรมากเกินไป
โปรไฟล์การติดตาม JSON มีกราฟที่เกี่ยวข้องกับประสิทธิภาพหลายรายการ ซึ่งจะช่วยระบุวิธีปรับปรุงการแลกเปลี่ยนประสิทธิภาพและการใช้ทรัพยากร
การแก้ปัญหา
ปัญหาเกี่ยวกับการดำเนินการแบบไดนามิกอาจสังเกตได้ยากและแก้ไขข้อบกพร่องได้ยาก เนื่องจากปัญหาอาจเกิดขึ้นภายใต้การผสมผสานการดำเนินการในเครื่องและการดำเนินการจากระยะไกลบางอย่างเท่านั้น
--debug_spawn_scheduler จะเพิ่มเอาต์พุตจากระบบการดำเนินการแบบไดนามิก
ซึ่งอาจช่วยแก้ไขปัญหาเหล่านี้ได้ นอกจากนี้ คุณยังปรับ
--dynamic_local_execution_delay แฟล็กและจำนวนงานระยะไกลเทียบกับงานในพื้นที่เพื่อ
ให้จำลองปัญหาได้ง่ายขึ้น
หากพบปัญหาเกี่ยวกับการดำเนินการแบบไดนามิกโดยใช้standalone
กลยุทธ์ ให้ลองเรียกใช้โดยไม่มี--experimental_local_lockfree_output หรือเรียกใช้
การกระทำเกี่ยวกับสถานที่ในแซนด์บ็อกซ์ ซึ่งอาจทำให้บิลด์ของคุณช้าลงเล็กน้อย (ดูด้านบนหากคุณใช้ Mac หรือ Windows) แต่จะช่วยขจัดสาเหตุบางอย่างที่อาจทำให้เกิดข้อผิดพลาด