- jemalloc ซึ่งเป็นตัวจัดสรรหน่วยความจำประสิทธิภาพสูง เป็นคอมโพเนนต์พื้นฐานที่ทำหน้าที่เป็นโครงสร้างพื้นฐานหลักในซอฟต์แวร์สแต็กของ Meta ควบคู่กับ Linux kernel และคอมไพเลอร์
- ในช่วงไม่กี่ปีที่ผ่านมา มีการค่อยๆ เบี่ยงเบนออกจากหลักการวิศวกรรมหลักที่เคยขับเคลื่อนการพัฒนา jemalloc ส่งผลให้เกิด หนี้ทางเทคนิค สะสมและทำให้ความคืบหน้าช้าลง
- หลังรับฟังฟีดแบ็กจากชุมชนและหารือกับสมาชิกต่างๆ รวมถึง Jason Evans ผู้ก่อตั้งโครงการ ก็ได้มีการ เปิดใช้งานอีกครั้ง (unarchived) ของรีโพซิทอรีโอเพนซอร์สดั้งเดิม
- ต่อจากนี้มีแผนจะมุ่งเน้นไปที่การจัดการหนี้ทางเทคนิค, การปรับปรุง ตัวจัดสรร Huge-Page, การเพิ่มประสิทธิภาพการใช้หน่วยความจำ และการปรับแต่ง AArch64
- Meta ยืนยันอีกครั้งถึง การดูแลระยะยาว ของ jemalloc และเปลี่ยนทิศทางไปสู่การพัฒนาโครงการร่วมกับชุมชน
ตำแหน่งและความสำคัญของ jemalloc
- jemalloc เป็น ตัวจัดสรรหน่วยความจำประสิทธิภาพสูง ที่มอบผลลัพธ์เชิงประสิทธิภาพอย่างสม่ำเสมอในซอฟต์แวร์สแต็กของ Meta
- มันปรับตัวอย่างต่อเนื่องให้เข้ากับการเปลี่ยนแปลงของฮาร์ดแวร์และซอฟต์แวร์ในเลเยอร์บน และมีส่วนช่วยด้านเสถียรภาพและประสิทธิภาพของโครงสร้างพื้นฐาน Meta ควบคู่กับ Linux kernel และคอมไพเลอร์
การเบี่ยงเบนจากหลักการและการทบทวนตนเอง
- คอมโพเนนต์ซอฟต์แวร์พื้นฐานต้องการ ความเข้มงวดในระดับสูงสุด ระหว่างการรักษาสมดุลระหว่างความเป็นจริงเชิงปฏิบัติกับหลักการ
- เนื่องจาก jemalloc สร้างผลกระทบเชิงประสิทธิภาพได้สูง จึงมีแรงจูงใจให้ไล่ตามผลลัพธ์ระยะสั้น และการปฏิเสธสิ่งนั้นต้องอาศัย วินัยในระดับองค์กร ที่เข้มแข็ง
- ในช่วงไม่กี่ปีที่ผ่านมา ได้เกิด การเบี่ยงเบนอย่างค่อยเป็นค่อยไป จากหลักการวิศวกรรมหลักที่เคยกำกับการพัฒนา jemalloc
- แม้บางการตัดสินใจจะให้ประโยชน์ทันที แต่ หนี้ทางเทคนิคที่ตามมาได้ขัดขวางความคืบหน้า
- มีการรับฟังฟีดแบ็กจากชุมชนอย่างจริงจัง และเข้าพบสมาชิกชุมชนรวมถึง Jason Evans ผู้ก่อตั้งโครงการ
- มีการทบทวนอย่างลึกซึ้งว่าการทำหน้าที่ดูแลโครงการส่งผลต่อสุขภาพระยะยาวของ jemalloc อย่างไร และได้แบ่งปันแนวทางที่เปลี่ยนไป
- เริ่มดำเนินการเพื่อลดหนี้ทางเทคนิคและ สร้างโรดแมประยะยาวของ jemalloc ขึ้นใหม่
บทใหม่: การยกเลิกการเก็บถาวรรีโพซิทอรีและแผนต่อจากนี้
- จากการพูดคุยกับชุมชน รีโพซิทอรีโอเพนซอร์ส jemalloc ดั้งเดิมจึงถูก เปิดใช้งานอีกครั้ง (unarchived)
- ทำให้ Meta สามารถทำหน้าที่ผู้ดูแลโครงการต่อไปได้ พร้อมมุ่งเน้นไปที่การลดภาระการบำรุงรักษาและการทำให้โค้ดเบสทันสมัย
- การจัดการหนี้ทางเทคนิค: รักษาให้มีประสิทธิภาพ เชื่อถือได้ และใช้งานง่ายสำหรับผู้ใช้ทุกคนผ่านการรีแฟกเตอร์และการปรับปรุง
- ตัวจัดสรร Huge-Page (HPA): ใช้ Transparent Hugepages (THP) ได้ดีขึ้นเพื่อ เพิ่มประสิทธิภาพ CPU
- ประสิทธิภาพการใช้หน่วยความจำ: ปรับให้เหมาะสมด้านประสิทธิภาพหน่วยความจำ ผ่านการปรับปรุงกลไกการแพ็ก การแคช และการทำเพอร์จ
- การปรับแต่ง AArch64: รับประกันประสิทธิภาพที่ดีเป็นค่าเริ่มต้นบนแพลตฟอร์ม ARM64
เสริมความร่วมมือกับชุมชน
- Meta เน้นย้ำการ สร้างความไว้วางใจผ่านการลงมือทำ และมุ่งเป้าให้ jemalloc เติบโตอย่างแข็งแรง
- ยินดีรับ ฟีดแบ็กและการมีส่วนร่วม จากชุมชน และคาดหวังที่จะร่วมกันสร้างอนาคตของ jemalloc
- จะผลักดัน ความร่วมมือและการพัฒนาที่ยั่งยืน ภายในระบบนิเวศโอเพนซอร์สต่อไป
1 ความคิดเห็น
ความเห็นจาก Hacker News
ตอนที่ทำงานอยู่ที่ Facebook เคยดูแล kernel patch เพื่อปรับปรุง กลไก purging ของ jemalloc
มันไม่ค่อยได้รับความนิยมในชุมชนเคอร์เนลหรือชุมชนความปลอดภัย แต่ผล benchmark ออกมามีประสิทธิภาพดี
ปัญหาคือเมื่อจัดสรรหน่วยความจำไปยังเธรดอื่นใหม่ จะเกิด zeroing ซึ่งกระทบต่อ cache locality และประสิทธิภาพ
ถ้าเป็นการนำหน่วยความจำกลับมาใช้ใหม่ภายใน security domain เดียวกัน มันก็เป็นการทำงานที่ไม่จำเป็น แต่การจะนิยามว่า ‘security domain’ ครอบคลุมถึงไหนนั้นตกลงกันได้ยาก
มีการถกเถียงที่เกี่ยวข้องอยู่ใน Linux Kernel mailing list
มีการทำ benchmark อย่างกว้างขวาง กับ HHVM ทั้งก่อนและหลังใช้ patch ดังกล่าว แต่ในระดับระบบกลับไม่พบความแตกต่างที่มีนัยสำคัญทางสถิติ
อาจมีการปรับปรุงใน microbenchmark บางตัว แต่เพราะไม่ส่งผลต่อประสิทธิภาพของระบบโดยรวม จึงถูกตัดออกจากเคอร์เนล
ไม่นานมานี้ได้ใช้ mimalloc ของ Microsoft ผ่าน LD_PRELOAD เพื่อใช้ประโยชน์จาก huge page ขนาด 1GB
ได้ประสิทธิภาพดีขึ้นราว 20% ในโปรแกรมที่ใช้หน่วยความจำหนัก
รู้สึกแปลกดีที่ใช้ไลบรารีโอเพนซอร์สจาก MS บน Linux เพื่อรีดประสิทธิภาพ
รู้สึกว่าพื้นที่ของ malloc ควรมีการแข่งขันมากกว่านี้
แอปเขียนด้วย Rust และส่วนใหญ่ลิงก์แบบ static
ตัวอย่างเช่นใน app1, tcmalloc ลด RSS ได้ 35% และลดเวลาในการประมวลผลได้ 30% เมื่อเทียบกับ glibc
ผลทดสอบทั้งหมดอ้างอิงจาก repository ของ tcmalloc
แม้แต่ Turbo Pascal ก็ยังมี API ให้กำหนด memory allocator เองได้
สุดท้ายแล้วแนวทางแบบ “one size fits all” ก็มีข้อจำกัดมาตั้งนานแล้ว
คือสร้างพูลใหม่ในแต่ละคำขอ แล้วพอคำขอนั้นจบก็ปล่อยทั้งก้อนทีเดียว
คิดว่า malloc เองก็ยังมีพื้นที่ให้พัฒนาไปในทิศทางนี้ได้อีกมาก
ถ้าแพตเทิร์นการจัดสรรเรียบง่าย ก็อาจให้ผลดีกว่า malloc ของ third-party ด้วยซ้ำ
คนมักมอง malloc เป็นกล่องดำมหัศจรรย์ แต่จริง ๆ แล้วมันไม่ได้วิเศษขนาดนั้น
ทีมของเราได้ย้ายจาก glibc malloc ไปเป็น jemalloc เมื่อ 2 ปีก่อน
การใช้หน่วยความจำของบริการ Python ลดลง 15~20%
แต่ในสภาพแวดล้อมแบบคอนเทนเนอร์ การปรับ oversize_threshold สำคัญมาก — ถ้าตั้งผิดอาจเกิด OOM ได้
อยากรู้ว่ามี benchmark ที่เปรียบเทียบ jemalloc กับ mimalloc บนบริการที่รันระยะยาวหรือไม่
สำหรับข้อมูลอ้างอิงที่เกี่ยวข้อง ขอแนะนำ Jemalloc Postmortem และ
Jemalloc Repositories Are Archived
สงสัยว่าการเปลี่ยนแปลงครั้งนี้เกี่ยวกับ ภาวะหน่วยความจำขาดแคลนทั่วโลก หรือไม่
อาจคำนวณออกมาได้ประมาณว่า “เปลี่ยน memory allocator แล้วประหยัดเงินได้หลายล้านดอลลาร์ต่อปี”
แค่เพิ่มประสิทธิภาพได้ 0.1% ก็ประหยัดได้เดือนละ 100,000 ดอลลาร์
ปัจจัยหลักที่ช่วยประหยัดคือต้นทุนระบบทำความเย็น (HVAC) และการซื้อเซิร์ฟเวอร์ที่ลดลง
ตอนนี้การประหยัดหน่วยความจำเป็นประเด็นใหญ่ แต่ตอนนั้นยังไม่ใช่
ถ้าส่งผลกับเซิร์ฟเวอร์หลายพันเครื่อง การปรับปรุงเล็กน้อยก็กลายเป็นตัวเลขใหญ่ได้
มีวัฒนธรรมของ การปรับปรุงเชิงปริมาณ แบบนี้ฝังรากอยู่
แค่เร็วขึ้น 10% ก็อาจได้เปรียบในการแข่งขันด้าน LLM
แรงจูงใจ ในการปรับปรุงประสิทธิภาพมีสูงมาก
ตอนทำงานเขียนโปรแกรมระดับล่างในออสเตรเลีย ผมโดน เลย์ออฟ
ผมชอบแก้ปัญหาแบบนี้มากจริง ๆ แต่ตลาดแถวนี้ส่วนใหญ่เป็นงาน React CRUD เลยค่อนข้างเสียดาย
ในโปรเจกต์สตาร์ตอัปที่ได้รับทุนจาก World Bank เคย deploy Ruby + jemalloc ขึ้น production
ทั้งความเร็วและประสิทธิภาพการใช้หน่วยความจำดีขึ้นอย่างเห็นได้ชัด จนลดค่าใช้จ่าย AWS ได้มาก
เรื่องนี้เกิดขึ้นเมื่อ 8 ปีก่อน เลยสงสัยว่าทำไมจนถึงตอนนี้ jemalloc ยังไม่กลายเป็นมาตรฐาน
การเปลี่ยนระบบที่รันอยู่แล้วไม่ใช่เรื่องง่าย แม้ประโยชน์จะชัดเจนก็ตาม
มีกรณีใช้ jemalloc เพื่อตามหา ต้นตอของ memory leak ด้วย
ดูได้จาก บทความใน GOV.UK tech blog
Meta ได้ merge งานที่เคยทำอยู่ใน fork ภายในของตัวเองกลับเข้ามาครั้งใหญ่
ดูได้ใน PR #2863
สงสัยว่ามีข้อมูลสรุป ไทม์ไลน์หรือประวัติ ของ jemalloc หรือไม่
เป็นโปรเจกต์โอเพนซอร์ส แต่ทำไม Meta ถึงถือบทบาทนำอยู่
ดูได้ที่ บล็อก Jemalloc Postmortem
อีก 2 คนที่เหลือก็อาจสังกัด Meta แบบไม่เปิดเผยก็ได้