การดำเนินการแบบไดนามิกเป็นฟีเจอร์ใน Bazel ที่มีการดำเนินการทั้งในเครื่องและระยะไกล การดำเนินการเดียวกันจะเริ่มต้นพร้อมกันโดยใช้เอาต์พุตจาก Branch แรก ที่เสร็จสิ้น โดยยกเลิกสาขาอื่น ด้วยการรวมพลังการดำเนินการ และ/หรือแคชขนาดใหญ่ที่ใช้ร่วมกันของระบบบิลด์ระยะไกลที่มีเวลาในการตอบสนองต่ำในเครื่อง การประยุกต์ใช้ เพื่อมอบสิ่งที่ดีที่สุดจากทั้ง 2 อย่างสำหรับบิลด์ที่สะอาดและค่อยๆ เพิ่มขึ้น
หน้านี้จะอธิบายวิธีเปิดใช้ ปรับแต่ง และแก้ไขข้อบกพร่องของการดำเนินการแบบไดนามิก หากคุณ มีการตั้งค่าการดำเนินการทั้งในเครื่องและระยะไกล และกำลังพยายามปรับ Bazel เพื่อประสิทธิภาพที่ดีขึ้น หน้านี้มีไว้สำหรับคุณ หากคุณยังไม่มี ตั้งค่าการดำเนินการระยะไกลแล้ว ให้ไปที่ การใช้งานระยะไกลของ Bazel ภาพรวมก่อน
เปิดใช้การดำเนินการแบบไดนามิกไหม
โมดูลการดำเนินการแบบไดนามิกเป็นส่วนหนึ่งของ Bazel แต่การใช้ประโยชน์จาก คุณจะต้องคอมไพล์ได้ทั้งในเครื่องและจากระยะไกลอยู่แล้ว การตั้งค่า Bazel เดียวกัน
หากต้องการเปิดใช้โมดูลการดำเนินการแบบไดนามิก ให้ส่งค่า --internal_spawn_scheduler
ไปยัง Bazel การดำเนินการนี้จะเพิ่มกลยุทธ์การดำเนินการใหม่ที่ชื่อว่า dynamic ตอนนี้คุณสามารถ
ให้ใช้กลยุทธ์นี้เป็นกลยุทธ์สำหรับช่วยจำที่คุณต้องการเรียกใช้แบบไดนามิก เช่น
--strategy=Javac=dynamic ดูวิธีเลือกการช่วยจำในส่วนถัดไป
เพื่อเปิดใช้การดำเนินการแบบไดนามิก
สำหรับความสามารถในการจำที่ใช้กลยุทธ์แบบไดนามิก กลยุทธ์การดำเนินการจากระยะไกลมีดังนี้
ที่ได้จาก Flag --dynamic_remote_strategy และกลยุทธ์ในพื้นที่จาก
การแจ้งว่าไม่เหมาะสม --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 เพิ่มเอาต์พุตเพิ่มเติมจากการดำเนินการแบบไดนามิก
ระบบที่ช่วยแก้ไขข้อบกพร่องของปัญหาเหล่านี้ได้ คุณยังสามารถปรับ
--dynamic_local_execution_delay แจ้งและจำนวนงานระยะไกลเทียบกับงานในท้องถิ่นให้
ทำให้ปัญหาเกิดซ้ำได้ง่ายขึ้น
หากพบปัญหาเกี่ยวกับการดำเนินการแบบไดนามิกโดยใช้ standalone
กลยุทธ์ ลองเรียกใช้โดยไม่ใช้ --experimental_local_lockfree_output หรือเรียกใช้
การกระทำเกี่ยวกับสถานที่อยู่ในแซนด์บ็อกซ์ ซึ่งอาจทำให้การสร้างของคุณช้าลงเล็กน้อย (โปรดดูข้อมูลด้านบนหาก
คุณใช้ Mac หรือ Windows) แต่นำสาเหตุที่อาจทำให้เกิดความล้มเหลวออก