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