การดำเนินการแบบไดนามิก

วันที่ รายงานปัญหา ดูแหล่งที่มา ตอนกลางคืน · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

การดำเนินการแบบไดนามิกเป็นฟีเจอร์ใน 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) แต่นำสาเหตุที่อาจทำให้เกิดความล้มเหลวออก