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

การดำเนินการแบบไดนามิกเป็นฟีเจอร์ใน Bazel ที่จะเริ่มการดำเนินการในเครื่องและระยะไกลของ การดำเนินการเดียวกันแบบขนาน โดยใช้เอาต์พุตจากกิ่งแรก ที่เสร็จสิ้นและยกเลิกกิ่งอื่นๆ โดยจะรวมความสามารถในการดำเนินการ และ/หรือแคชที่แชร์ขนาดใหญ่ของระบบการสร้างระยะไกลเข้ากับเวลาในการตอบสนองที่ต่ำของการดำเนินการในเครื่อง เพื่อให้คุณได้รับประโยชน์จากทั้ง 2 อย่างสำหรับการสร้างที่สะอาดและแบบเพิ่มทีละรายการ

หน้านี้จะอธิบายวิธีเปิดใช้ ปรับแต่ง และแก้ไขข้อบกพร่องของการดำเนินการแบบไดนามิก หากคุณตั้งค่าการดำเนินการทั้งในเครื่องและระยะไกล และพยายามปรับการตั้งค่า Bazel เพื่อประสิทธิภาพที่ดีขึ้น หน้านี้เหมาะสำหรับคุณ หากยังไม่ได้ตั้งค่า การดำเนินการจากระยะไกล ให้ไปที่ภาพรวมการดำเนินการจากระยะไกลของ Bazel ก่อน

เปิดใช้การดำเนินการแบบไดนามิกไหม

โมดูลการดำเนินการแบบไดนามิกเป็นส่วนหนึ่งของ Bazel แต่หากต้องการใช้การดำเนินการแบบไดนามิก คุณต้องคอมไพล์ทั้งในเครื่องและจากระยะไกลจากการตั้งค่า Bazel เดียวกันได้อยู่แล้ว

หากต้องการเปิดใช้โมดูลการดำเนินการแบบไดนามิก ให้ส่งแฟล็ก --internal_spawn_scheduler ไปยัง Bazel ซึ่งจะเพิ่มกลยุทธ์การดำเนินการใหม่ที่เรียกว่า dynamic ตอนนี้คุณสามารถ ใช้สิ่งนี้เป็นกลยุทธ์สำหรับมินิโมเดลที่คุณต้องการเรียกใช้แบบไดนามิกได้ เช่น --strategy=Javac=dynamic ดูวิธีเลือกนิโมนิก ที่จะเปิดใช้การดำเนินการแบบไดนามิกได้ในส่วนถัดไป

สำหรับตัวช่วยจำที่ใช้กลยุทธ์แบบไดนามิก กลยุทธ์การดำเนินการระยะไกลจะมาจากแฟล็ก --dynamic_remote_strategy และกลยุทธ์ในเครื่องจะมาจากแฟล็ก --dynamic_local_strategy การส่ง --dynamic_local_strategy=worker,sandboxed จะตั้งค่าเริ่มต้นสำหรับสาขาในเครื่อง ของการดำเนินการแบบไดนามิกเพื่อลองใช้กับ Worker หรือการดำเนินการแบบแซนด์บ็อกซ์ตามลำดับ การส่ง --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 ให้ความสำคัญกับการเปิดสาขาท้องถิ่น เมื่อสาขาที่อยู่ระยะไกลเปิดดำเนินการมาอย่างน้อยเท่านี้ โดยปกติแล้ว การดำเนินการที่กำหนดเวลาล่าสุดจะมีลำดับความสำคัญสูงสุด เนื่องจากมีโอกาสมากที่สุดที่จะ ชนะการแข่งขัน แต่หากระบบระยะไกลค้างหรือใช้เวลานานเป็นพิเศษในบางครั้ง การดำเนินการนี้จะช่วยให้การสร้างดำเนินต่อไปได้ ฟีเจอร์นี้ไม่ได้เปิดใช้โดยค่าเริ่มต้นเนื่องจากอาจซ่อนปัญหาเกี่ยวกับระบบระยะไกลที่ควรได้รับการแก้ไข โปรดตรวจสอบประสิทธิภาพของระบบระยะไกลหากเปิดใช้ตัวเลือกนี้

--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) แต่จะช่วยขจัดสาเหตุบางอย่างที่อาจทำให้เกิดข้อผิดพลาด