หน้านี้จะกล่าวถึงวิธีใช้คนทำงานถาวร ประโยชน์ ข้อกำหนด และผลกระทบที่คนทำงานมีต่อการทำแซนด์บ็อกซ์
ผู้ปฏิบัติงานถาวรเป็นกระบวนการที่ใช้เวลานานซึ่งเริ่มต้นโดยเซิร์ฟเวอร์ Bazel ซึ่งทำหน้าที่เป็น Wrapper รอบๆ เครื่องมือจริง (โดยปกติคือคอมไพเลอร์) หรือก็คือเครื่องมือเอง เพื่อรับประโยชน์จากผู้ปฏิบัติงานอย่างต่อเนื่อง เครื่องมือนี้ต้องรองรับการคอมไพล์ตามลำดับ และ Wrapper จะต้องแปลระหว่าง API ของเครื่องมือกับรูปแบบคำขอ/คำตอบที่อธิบายไว้ด้านล่าง อาจมีเรียกใช้ Worker เดียวกันโดยใส่หรือไม่ใส่ Flag --persistent_worker
ในบิลด์เดียวกัน และมีหน้าที่รับผิดชอบในการเริ่มต้นและพูดคุยกับเครื่องมืออย่างเหมาะสม รวมถึงปิด Worker เมื่อออก ระบบจะกำหนดอินสแตนซ์ของ W worker แต่ละรายการ (แต่ไม่ได้เปลี่ยนเส้นทางไปยัง) ไดเรกทอรีการทำงานแยกต่างหากภายใต้ <outputBase>/bazel-workers
การใช้ผู้ปฏิบัติงานถาวรเป็นกลยุทธ์การดำเนินการที่ลดโอเวอร์เฮดเริ่มต้น ทำให้มีการคอมไพล์ JIT มากขึ้น และเปิดใช้การแคช เช่น ต้นไม้ไวยากรณ์นามธรรมในการดำเนินการเพื่อดำเนินการ กลยุทธ์นี้ช่วยปรับปรุงประสิทธิภาพโดยการส่งคำขอหลายรายการไปยังกระบวนการที่ทำงานต่อเนื่อง
มีการใช้งานผู้ปฏิบัติงานถาวรสำหรับหลายภาษา ซึ่งรวมถึง Java, Scala, Kotlin และอื่นๆ
โปรแกรมที่ใช้รันไทม์ NodeJS สามารถใช้ไลบรารีตัวช่วย @bazel/worker เพื่อติดตั้งใช้งานโปรโตคอลสำหรับแรงงาน
การใช้ผู้ปฏิบัติงานถาวร
Bazel 0.27 ขึ้นไปใช้ผู้ปฏิบัติงานถาวรโดยค่าเริ่มต้นเมื่อเรียกใช้บิลด์ แต่การดำเนินการระยะไกลจะมีความสำคัญเหนือกว่า สำหรับการดำเนินการที่ไม่รองรับคนทำงานถาวร Bazel จะกลับไปเริ่มอินสแตนซ์เครื่องมือสำหรับแต่ละการดำเนินการ คุณตั้งค่าบิลด์ให้ใช้ผู้ปฏิบัติงานถาวรอย่างชัดแจ้งได้โดยตั้งค่ากลยุทธ์ worker
สำหรับบันทึกของเครื่องมือที่เกี่ยวข้อง แนวทางปฏิบัติแนะนำคือให้ระบุ local
เป็นกลยุทธ์สำรองสำหรับกลยุทธ์ worker
ดังตัวอย่างต่อไปนี้
bazel build //my:target --strategy=Javac=worker,local
การใช้กลยุทธ์สำหรับโหนดทำงานแทนกลยุทธ์ในเครื่องสามารถเพิ่มความเร็วในการคอมไพล์ได้อย่างมาก ทั้งนี้ขึ้นอยู่กับการใช้งาน สำหรับ Java บิลด์อาจทำงานเร็วขึ้น 2-4 เท่า และบางครั้งอาจใช้เวลานานกว่าสำหรับการคอมไพล์ที่เพิ่มขึ้น การคอมไพล์ Bazel นั้น รวดเร็วกว่าประมาณ 2.5 เท่าสำหรับพนักงาน ดูรายละเอียดเพิ่มเติมได้ที่ส่วน "การเลือกจํานวนคนงาน"
หากมีสภาพแวดล้อมบิลด์ระยะไกลที่ตรงกับสภาพแวดล้อมบิลด์ในเครื่อง คุณจะใช้กลยุทธ์ dynamic เวอร์ชันทดลอง ซึ่งจะแข่งกับการดำเนินการระยะไกลและการดำเนินการของผู้ปฏิบัติงานได้ หากต้องการเปิดใช้กลยุทธ์แบบไดนามิก ให้ส่งค่าสถานะ --experimental_spawn_scheduler
กลยุทธ์นี้จะเปิดใช้แรงงานโดยอัตโนมัติ คุณจึงไม่ต้องระบุกลยุทธ์ worker
แต่ยังคงใช้ local
หรือ sandboxed
เป็นกลยุทธ์สำรองได้
การเลือกจำนวนผู้ปฏิบัติงาน
จำนวนอินสแตนซ์ผู้ปฏิบัติงานเริ่มต้นต่อคีย์สั้นคือ 4 แต่สามารถปรับได้ด้วยตัวเลือกworker_max_instances
การใช้ CPU ที่มีอยู่อย่างคุ้มค่าและจำนวนการคอมไพล์ JIT และการตีคู่แคชที่คุณได้รับนั้นมีความเกี่ยวข้องกัน เมื่อมีผู้ปฏิบัติงานมากขึ้น เป้าหมายมากขึ้นก็จะจ่ายต้นทุนในการเริ่มต้นใช้งานโค้ดที่ไม่ใช่ JITT และการพบ Cold Cache หากมีเป้าหมายจำนวนไม่มากนัก การใช้ผู้ปฏิบัติงานเพียงรายเดียวอาจให้ผลลัพธ์ที่ดีที่สุดระหว่างความเร็วในการคอมไพล์กับการใช้ทรัพยากร (เช่น ดูปัญหา #8586)
Flag worker_max_instances
จะตั้งค่าจํานวนอินสแตนซ์ที่ทำงานสูงสุดต่อชุดคําช่วยจําและ Flag (ดูด้านล่าง) ดังนั้นในระบบแบบผสม คุณอาจต้องใช้หน่วยความจําค่อนข้างมากหากใช้ค่าเริ่มต้น สำหรับบิลด์ที่เพิ่มขึ้น ประโยชน์ของอินสแตนซ์ผู้ปฏิบัติงานหลายรายการจะน้อยลงกว่าเดิม
กราฟนี้แสดงเวลาคอมไพล์จากรอยขีดข่วนสำหรับ Bazel (เป้าหมาย //src:bazel
) บนเวิร์กสเตชัน Intel Xeon 3.5 GHz Linux แบบ 6 คอร์ พร้อม RAM 64 GB สําหรับการกําหนดค่าผู้ปฏิบัติงานแต่ละรายการ ระบบจะเรียกใช้บิลด์ที่สะอาด 5 ครั้งและนําค่าเฉลี่ยของ 4 ครั้งล่าสุด
รูปที่ 1 กราฟการปรับปรุงประสิทธิภาพของบิลด์ที่สะอาด
สําหรับการกําหนดค่านี้ 2 เวิร์กเกอร์จะคอมไพล์ได้เร็วที่สุด แต่มีประสิทธิภาพเพิ่มขึ้นเพียง 14% เมื่อเทียบกับ 1 เวิร์กเกอร์ ตัวเลือกที่ดีหากต้องการใช้หน่วยความจำน้อยลงคือใช้เวิร์กเกอร์ 1 คน
โดยทั่วไปแล้ว การรวบรวมเนื้อหาที่เพิ่มขึ้นเรื่อยๆ จะให้ประโยชน์มากกว่า บิลด์ที่สะอาดนั้นค่อนข้างเกิดขึ้นไม่บ่อยนัก แต่การเปลี่ยนแปลงไฟล์เดียวระหว่างการคอมไพล์นั้นเกิดขึ้นได้บ่อยครั้ง โดยเฉพาะในการพัฒนาแบบทดสอบเป็นแนวทาง ตัวอย่างข้างต้นยังมีการดำเนินการบางอย่างที่ไม่ใช่การจัดแพ็กเกจที่ไม่ใช่ Java ซึ่งอาจบดบังเวลาคอมไพล์ที่เพิ่มขึ้นได้
การคอมไพล์ซอร์สโค้ด Java อีกครั้งเท่านั้น (//src/main/java/com/google/devtools/build/lib/bazel:BazelServer_deploy.jar
) หลังจากที่เปลี่ยนค่าคงที่สตริงภายในใน AbstractContainerizingSandboxedSpawn.java จะช่วยเพิ่มความเร็วขึ้น 3 เท่า (โดยเฉลี่ย 20 บิลด์แบบเพิ่มที่มี 1 บิลด์อุ่นเครื่องถูกทิ้ง)
รูปที่ 2 กราฟการปรับปรุงประสิทธิภาพของบิลด์ที่เพิ่มขึ้น
การเร่งความเร็วจะขึ้นอยู่กับการเปลี่ยนแปลงที่เกิดขึ้น ความเร็วที่เพิ่มขึ้น 6 เท่าจะวัดได้ในสถานการณ์ข้างต้นเมื่อมีการเปลี่ยนแปลงค่าคงที่ที่ใช้กันโดยทั่วไป
การแก้ไขผู้ปฏิบัติงานถาวร
คุณส่ง Flag --worker_extra_flag
เพื่อระบุแฟล็กการเริ่มต้นไปยังผู้ปฏิบัติงานได้ ซึ่งคีย์ตามความสามารถในการจำ ตัวอย่างเช่น การส่ง --worker_extra_flag=javac=--debug
จะเปิดการแก้ไขข้อบกพร่องสำหรับ Javac เท่านั้น
คุณตั้งค่า Flag ของ WOrker ได้เพียง 1 รายการต่อการใช้ Flag นี้ และสำหรับคําช่วยจํารายการเดียวเท่านั้น
ผู้ปฏิบัติงานไม่ได้สร้างขึ้นแยกกันสำหรับ Mnemonic แต่ละรายการ แต่รวมถึงตัวแปรต่างๆ ใน Flag เริ่มต้นใช้งานด้วย ระบบจะรวมการแจ้งเตือนหน่วยความจำและการเริ่มต้นใช้งานแต่ละรายการเข้าด้วยกันเป็น WorkerKey
และอาจสร้างผู้ปฏิบัติงาน WorkerKey
ได้สูงสุด worker_max_instances
ราย โปรดดูส่วนถัดไปเกี่ยวกับวิธีที่การกำหนดค่าการดำเนินการสามารถระบุแฟล็กการตั้งค่า
คุณสามารถใช้ Flag --high_priority_workers
เพื่อระบุคําช่วยจําที่ควรเรียกใช้แทนคําช่วยจําที่มีลําดับความสําคัญเป็นปกติ ซึ่งจะช่วยจัดลําดับความสําคัญของการดำเนินการที่อยู่ในเส้นทางสําคัญเสมอ หากมีผู้ปฏิบัติงานที่มีลําดับความสําคัญสูงดําเนินการตามคําขอ 2 คนขึ้นไป ระบบจะป้องกันไม่ให้ผู้ปฏิบัติงานคนอื่นๆ ทํางาน แฟล็กนี้สามารถใช้ได้หลายครั้ง
การส่งผ่าน Flag --worker_sandboxing
จะทำให้คำขอของเวิร์กเกอร์แต่ละรายการใช้ไดเรกทอรีแซนด์บ็อกซ์แยกต่างหากสำหรับอินพุตทั้งหมด การตั้งค่า Sandbox จะใช้เวลาเพิ่มเติมอีกสักหน่อย โดยเฉพาะใน macOS แต่จะให้การรับประกันความถูกต้องที่ดีขึ้น
Flag --worker_quit_after_build
มีประโยชน์สําหรับการแก้ไขข้อบกพร่องและการสร้างโปรไฟล์เป็นหลัก ธงนี้จะบังคับให้ผู้ปฏิบัติงานทั้งหมด
ปิดการทำงานเมื่อบิลด์เสร็จแล้ว และคุณยังส่ง --worker_verbose
เพื่อรับข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่พนักงานกำลังทำอยู่ได้อีกด้วย แฟล็กนี้แสดงอยู่ในช่อง verbosity
ใน WorkRequest
ซึ่งช่วยให้การติดตั้งใช้งานผู้ปฏิบัติงานมีรายละเอียดมากขึ้น
ผู้ปฏิบัติงานเก็บบันทึกในไดเรกทอรี <outputBase>/bazel-workers
ตัวอย่างเช่น /tmp/_bazel_larsrc/191013354bebe14fdddae77f2679c3ef/bazel-workers/worker-1-Javac.log
ชื่อไฟล์จะประกอบด้วยรหัสผู้ปฏิบัติงานและเทคนิคช่วยจำ เนื่องจากอาจมี WorkerKey
มากกว่า 1 ครั้งต่อการช่วยจำ คุณอาจเห็นไฟล์บันทึกมากกว่า worker_max_instances
ไฟล์สำหรับช่วยจำหนึ่งๆ
สำหรับบิลด์ของ Android โปรดดูรายละเอียดที่หน้าประสิทธิภาพของบิลด์ของ Android
การนำผู้ปฏิบัติงานอย่างต่อเนื่องไปใช้
ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีสร้างผู้ปฏิบัติงานในหน้าการสร้างผู้ปฏิบัติงานถาวร
ตัวอย่างนี้แสดงการกำหนดค่า Starlark สำหรับเวิร์กเกอร์ที่ใช้ JSON
args_file = ctx.actions.declare_file(ctx.label.name + "_args_file")
ctx.actions.write(
output = args_file,
content = "\n".join(["-g", "-source", "1.5"] + ctx.files.srcs),
)
ctx.actions.run(
mnemonic = "SomeCompiler",
executable = "bin/some_compiler_wrapper",
inputs = inputs,
outputs = outputs,
arguments = [ "-max_mem=4G", "@%s" % args_file.path],
execution_requirements = {
"supports-workers" : "1", "requires-worker-protocol" : "json" }
)
เมื่อใช้คําจํากัดความนี้ การใช้งานครั้งแรกของการดำเนินการนี้จะเริ่มต้นด้วยการดำเนินการบรรทัดคำสั่ง /bin/some_compiler -max_mem=4G --persistent_worker
คําขอรวบรวม Foo.java
จะมีลักษณะดังนี้
หมายเหตุ: แม้ว่าข้อกำหนดของบัฟเฟอร์โปรโตคอลจะใช้ "รูปแบบ Snake Case" (request_id
) แต่โปรโตคอล JSON จะใช้ "รูปแบบ Camel Case" (requestId
) ในเอกสารนี้ เราจะใช้รูปแบบ Camel Case ในตัวอย่าง JSON แต่จะใช้รูปแบบ Snake Case เมื่อพูดถึงช่อง ไม่ว่าจะใช้โปรโตคอลใดก็ตาม
{
"arguments": [ "-g", "-source", "1.5", "Foo.java" ]
"inputs": [
{ "path": "symlinkfarm/input1", "digest": "d49a..." },
{ "path": "symlinkfarm/input2", "digest": "093d..." },
],
}
แรงงานจะรับข้อมูลนี้ใน stdin
ในรูปแบบ JSON คั่นด้วยการขึ้นบรรทัดใหม่ (เนื่องจากมีการตั้งค่า requires-worker-protocol
เป็น JSON) จากนั้นเวิร์กเกอร์จะดำเนินการและส่ง WorkResponse
ในรูปแบบ JSON ไปยัง Bazel บน stdout จากนั้น Bazel จะแยกวิเคราะห์การตอบกลับนี้และแปลงเป็น WorkResponse
proto ด้วยตนเอง หากต้องการสื่อสารกับผู้ปฏิบัติงานที่เกี่ยวข้องโดยใช้ Protobuf ที่เข้ารหัสแบบไบนารีแทน JSON ให้ตั้งค่า requires-worker-protocol
เป็น proto
ดังนี้
execution_requirements = {
"supports-workers" : "1" ,
"requires-worker-protocol" : "proto"
}
หากไม่รวม requires-worker-protocol
ไว้ในข้อกำหนดการดำเนินการ Bazel จะกำหนดค่าเริ่มต้นการสื่อสารสำหรับผู้ปฏิบัติงานให้ใช้ Protocolbuf
Bazel ดึงข้อมูล WorkerKey
มาจากเทคนิคการจำและแฟล็กที่แชร์ ดังนั้นหากการกำหนดค่านี้อนุญาตให้เปลี่ยนพารามิเตอร์ max_mem
ระบบจะสร้างผู้ปฏิบัติงานแยกกันสำหรับแต่ละค่าที่ใช้ ซึ่งอาจทำให้เกิดการใช้หน่วยความจำมากเกินไป
หากใช้หลายรูปแบบเกินไป
ปัจจุบันผู้ปฏิบัติงานแต่ละคนประมวลผลคำขอได้ทีละ 1 คำขอเท่านั้น ฟีเจอร์ผู้ทํางานแบบมัลติเพล็กซ์เวอร์ชันทดลองอนุญาตให้ใช้หลายเธรดได้ หากเครื่องมือพื้นฐานเป็นแบบมัลติเธรดและมีการตั้งค่า Wrapper ให้เข้าใจเรื่องนี้
ในที่เก็บ GitHub นี้ คุณสามารถดูตัวอย่าง Wrapper ของผู้ปฏิบัติงานที่เขียนด้วย Java และใน Python หากใช้งาน JavaScript หรือ TypeScript อยู่ แพ็กเกจ@bazel/worker และตัวอย่างผู้ปฏิบัติงาน Nodejs อาจเป็นประโยชน์
ผู้ปฏิบัติงานส่งผลต่อแซนด์บ็อกซ์อย่างไร
การใช้กลยุทธ์ worker
โดยค่าเริ่มต้นจะไม่เรียกใช้การดําเนินการในแซนด์บ็อกซ์ ซึ่งคล้ายกับกลยุทธ์ local
คุณสามารถตั้งค่า Flag --worker_sandboxing
เพื่อเรียกใช้เวิร์กเกอร์ทั้งหมดภายในแซนด์บ็อกซ์ เพื่อให้แน่ใจว่าการเรียกใช้เครื่องมือแต่ละครั้งจะเห็นเฉพาะไฟล์อินพุตที่ควรจะเห็น เครื่องมือนี้อาจยังทำให้ข้อมูลระหว่างคำขอรั่วไหลภายใน เช่น ผ่านแคช การใช้กลยุทธ์ dynamic
กำหนดให้ต้องแยกพื้นที่ทํางานของผู้ใช้
ระบบจะส่งข้อมูลสรุปไปพร้อมกับไฟล์อินพุตแต่ละไฟล์เพื่อให้ใช้แคชคอมไพเลอร์กับเวิร์กเกอร์ได้อย่างถูกต้อง ดังนั้นคอมไพเลอร์หรือ Wrapper จะตรวจสอบได้ว่าอินพุตยังคงถูกต้องหรือไม่โดยไม่ต้องอ่านไฟล์
แม้จะใช้ข้อมูลสรุปอินพุตเพื่อป้องกันการแคชที่ไม่ต้องการ แต่เวิร์กเกอร์ที่อยู่ในแซนด์บ็อกซ์จะให้บริการแซนด์บ็อกซ์ที่เข้มงวดน้อยกว่าแซนด์บ็อกซ์แบบสมบูรณ์ เนื่องจากเครื่องมืออาจเก็บสถานะภายในอื่นๆ ที่ได้รับผลกระทบจากคําขอก่อนหน้าไว้
คุณจะใช้แซนด์บ็อกซ์ของผู้ปฏิบัติงาน Multiplex ได้ก็ต่อเมื่อผู้ปฏิบัติงานรองรับเท่านั้น และต้องเปิดใช้แซนด์บ็อกซ์นี้แยกต่างหากด้วยแฟล็ก --experimental_worker_multiplex_sandboxing
ดูรายละเอียดเพิ่มเติมได้ในเอกสารการออกแบบ)
อ่านเพิ่มเติม
ดูข้อมูลเพิ่มเติมเกี่ยวกับผู้ปฏิบัติงานถาวรได้ที่
- บล็อกโพสต์เดิมของพนักงานถาวร
- คำอธิบายการใช้งาน Haskell {: .external}
- บล็อกโพสต์โดย Mike Morearty {: .external}
- การพัฒนาส่วนหน้าด้วย Bazel: Angular/TypeScript และ Persistent Workers w/ Asana {: .external}
- คำอธิบายกลยุทธ์บาเซล {: .external}
- การสนทนาเกี่ยวกับกลยุทธ์สำหรับแรงงานที่ให้ข้อมูลในรายชื่ออีเมล bazel-discuss {: .external}