Linux Cgroups v2 Pub Sub Architecture — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

Linux Cgroups v2 คืออะไร และทำงานอย่างไรในระบบปฏิบัติการ Linux

Cgroups หรือ Control Groups คือกลไกระดับเคอร์เนลของ Linux ที่ใช้จัดการ จำกัด และแบ่งทรัพยากรของระบบให้กับกลุ่มกระบวนการต่าง ๆ ทั้งหมด

ผมใช้งานมาหลายปีทั้งตอนบริหารเซิร์ฟเวอร์และตอนรันบอทเทรดที่ต้องแยกทรัพยากรชัดเจน โดยเนื้อหาชุดนี้เป็นอีกหนึ่งหัวข้อทางด้านไอทีที่เราพัฒนาต่อเนื่องในเว็บไซต์ siamcafe.net นำโดย อ.บอม ซึ่งมีประสบการณ์ด้านระบบและการเทรดมากว่าสิบสามปี

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

เมื่อพูดถึงสถาปัตยกรรมแบบ Pub/Sub หรือ Publish/Subscribe ในบริบทของ Cgroups v2 จะหมายถึงรูปแบบการรายงานเหตุการณ์ที่เคอร์เนลเผยแพร่สถานะและเหตุการณ์ที่เกี่ยวกับการใช้ทรัพยากรออกมา และโปรแกรมที่สนใจสามารถสมัครรับข้อมูลเหล่านั้นได้ผ่านกลไกของเซิร์ฟเวอร์การแจ้งเตือน โดยทั้งสองฝ่ายไม่จำเป็นต้องรู้จักกันโดยตรง ฝั่งผู้เผยแพร่คือเคอร์เนลและไฟล์ควบคุมต่าง ๆ ส่วนฝั่งผู้รับคือเดอมอนหรือเครื่องมือติดตามระบบที่เปิดฟังอยู่

หัวใจของการแจ้งเตือนใน Cgroups v2 อยู่ที่ไฟล์ชื่อ cgroup.events และ cgroup.type พร้อมกับกลไกการรอคอยเหตุการณ์ที่เรียกว่า inotify และการรอคอยผ่านวัตถุ epoll ทำให้โปรแกรมที่ต้องการติดตามการเปลี่ยนแปลง ไม่ต้องวนลูปถามเคอร์เนลซ้ำ ๆ แต่จะรับการแจ้งเตือนทันทีเมื่อเหตุการณ์เกิดขึ้นจริง ประหยัดทรัพยากรและได้ข้อมูลแบบเกือบเรียลไทม์

ตัวอย่างเหตุการณ์ที่ผู้ใช้สมัครรับได้มีเช่น การแจ้งว่ากระบวนการในกลุ่มถูกสังหารเพราะใช้หน่วยความจำเกินขีดจำกัด ซึ่งแสดงผ่านฟิลด์ populated และ frozen ในไฟล์ cgroup.events หรือการแจ้งเตือนเมื่อค่าของหน่วยความจำถึงจุดที่เคอร์เนลเริ่มกู้คืนทรัพยากรกลับ ทั้งหมดนี้ทำให้การบริหารเซิร์ฟเวอร์ในยุค 2026 ที่รันคอนเทนเนอร์จำนวนมาก สามารถรู้ทันปัญหาได้ก่อนที่ผู้ใช้ปลายทางจะรู้สึกได้เอง

ในทางปฏิบัติ Cgroups v2 คือรากฐานที่อยู่เบื้องหลังเทคโนโลยีที่เราใช้กันทุกวัน ไม่ว่าจะเป็น Docker, Podman หรือ Kubernetes ซึ่งต่างก็อาศัย Cgroups ในการจำกัดทรัพยากรของคอนเทนเนอร์แต่ละตัว เมื่อเข้าใจกลไก Pub/Sub ใน Cgroups v2 แล้ว เราจะวินิจฉัยปัญหาได้ลึกกว่าเครื่องมือสำเร็จรูปทั่วไปอยู่หลายขั้น

ก่อนจะลงมือใช้งานจริง เราต้องแยกแยะองค์ประกอบหลักของสถาปัตยกรรมนี้ให้ชัดก่อน เพราะหลายคนอ่านเจอคำว่า Pub/Sub แล้วนึกถึงระบบส่งข้อความแบบขนาดใหญ่อย่าง

Apache Kafka ทันที ซึ่งจริง ๆ แล้วแนวคิดเบื้องหลังคล้ายกัน แต่รูปธรรมใน Cgroups v2 เรียบง่ายกว่ามาก

ก่อนจะลงมือใช้งานจริง เราต้องแยกแยะองค์ประกอบหลักของสถาปัตยกรรมนี้ให้ชัดก่อน เพราะหลายคนอ่านเจอคำว่า Pub/Sub แล้วนึกถึงระบบส่งข้อความแบบขนาดใหญ่อย่าง Apache Kafka ทันที ซึ่งจริง ๆ แล้วแนวคิดเบื้องหลังคล้ายกัน แต่รูปธรรมใน Cgroups v2 เรียบง่ายกว่ามาก

องค์ประกอบแรกคือ Controller หรือตัวควบคุมทรัพยากร เป็นโมดูลภายในเคอร์เนลที่รับผิดชอบทรัพยากรหนึ่งประเภท เช่น cpu สำหรับเวลาการประมวลผล, memory สำหรับหน่วยความจำ, io สำหรับการเข้าถึงดิสก์ และ pids สำหรับจำกัดจำนวนกระบวนการ ใน Cgroups v2 ทุกกลุ่มจะเห็นตัวควบคุมทั้งหมดที่เปิดใช้งานในลำดับชั้นเดียวกัน ต่างจากเวอร์ชันแรกที่ต้องเลือกว่าจะผูกตัวควบคุมใดเข้ากับลำดับชั้นใด

องค์ประกอบที่สองคือไฟล์อินเทอร์เฟซภายใต้ไดเรกทอรี /sys/fs/cgroup ไฟล์แต่ละตัวทำหน้าที่ต่างกัน เช่น memory.max กำหนดเพดานหน่วยความจำ, memory.current รายงานการใช้งานปัจจุบัน และ memory.events ซึ่งเป็นหัวใจฝั่งผู้เผยแพร่เหตุการณ์ เพราะบันทึกตัวนับเหตุการณ์สำคัญเช่น oom, oom_kill และ max ที่บอกว่ามีกระบวนการพยายามใช้ทรัพยากรเกินเพดานมากี่ครั้ง

องค์ประกอบที่สามคือ Subscriber หรือผู้สมัครรับข้อมูล โดยทั่วไปคือเดอมอนหรือเครื่องมือตรวจสอบ เช่น systemd, kubelet, prometheus พร้อมตัวเก็บข้อมูล cgroups exporter หรือแม้แต่สคริปต์ที่เราเขียนเองด้วยไพธอน ผู้รับเหล่านี้จะเปิดดีสคริปเตอร์ชี้ไปที่ไฟล์เหตุการณ์ แล้วรอด้วยกลไก poll หรือ epoll เมื่อเคอร์เนลปรับปรุงค่าในไฟล์ ผู้รับจะได้รับสัญญาณให้อ่านค่าใหม่ทันที

องค์ประกอบสุดท้ายคือเหตุการณ์เอง เหตุการณ์ที่พบบ่อยในการใช้งานจริงได้แก่ populated เมื่อมีหรือไม่มีกระบวนการอยู่ในกลุ่ม, frozen เมื่อกลุ่มถูกหยุดชั่วคราวด้วยคำสั่ง freeze, oom_kill เมื่อตัวควบคุมหน่วยความจำสังหารกระบวนการเพราะใช้เกินขีดจำกัด และ pressured เมื่อระบบเริ่มกดดันทรัพยากรจนมีผลต่อประสิทธิภาพ

ตารางต่อไปนี้สรุปบทบาทของแต่ละองค์ประกอบเพื่อให้เห็นภาพรวมชัดเจน

องค์ประกอบ	ทำหน้าที่อะไร	ตัวอย่างที่พบจริง
Controller	ควบคุมทรัพยากรหนึ่งประเภทของกลุ่มกระบวนการ	cpu, memory, io, pids
ไฟล์อินเทอร์เฟซ	ช่องทางอ่านและตั้งค่า เป็นเหมือนช่องเผยแพร่ข้อมูล	memory.max, memory.events, cgroup.events
เหตุการณ์	การเปลี่ยนแปลงสถานะที่เคอร์เนลเผยแพร่ออกมา	oom_kill, populated, frozen, pressure
Subscriber	โปรแกรมที่สมัครรับและตอบสนองเหตุการณ์	systemd, kubelet, สคริปต์ไพธอนของเราเอง
กลไกแจ้งเตือน	วิธีที่เคอร์เนลปลุกผู้รับให้อ่านค่าใหม่	inotify, poll, epoll

หลายคนถามผมว่าจำเป็นไหมที่จะต้องย้ายไปใช้ Cgroups v2 ถ้าระบบเดิมยังทำงานบนเวอร์ชันแรกได้ปกติ คำตอบของผมคือจำเป็นอย่างยิ่งในปี 2026

เพราะระบบคอนเทนเนอร์สมัยใหม่รวมถึง Kubernetes รุ่นใหม่ ๆ และระบบปฏิบัติการส่วนใหญ่ในปัจจุบันต่างก็ยึดเวอร์ชันสองเป็นค่าเริ่มต้นไปแล้ว การต่อยอดสถาปัตยกรรม Pub/Sub ก็มีอยู่เฉพาะในเวอร์ชันสองด้วย

เปรียบเทียบ Cgroups v1 กับ Cgroups v2 ในสถานการณ์จริง

หลายคนถามผมว่าจำเป็นไหมที่จะต้องย้ายไปใช้ Cgroups v2 ถ้าระบบเดิมยังทำงานบนเวอร์ชันแรกได้ปกติ คำตอบของผมคือจำเป็นอย่างยิ่งในปี 2026 เพราะระบบคอนเทนเนอร์สมัยใหม่รวมถึง Kubernetes รุ่นใหม่ ๆ และระบบปฏิบัติการส่วนใหญ่ในปัจจุบันต่างก็ยึดเวอร์ชันสองเป็นค่าเริ่มต้นไปแล้ว การต่อยอดสถาปัตยกรรม Pub/Sub ก็มีอยู่เฉพาะในเวอร์ชันสองด้วย

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

ความต่างข้อที่สองคือกลไกเผยแพร่เหตุการณ์ เวอร์ชันแรกไม่มีอินเทอร์เฟซเหตุการณ์ที่เป็นทางการ ผู้ดูแลส่วนใหญ่ต้องเขียนสคริปต์สำรวจไฟล์ทุกช่วงเวลา ซึ่งเสียทรัพยากรและอาจพลาดเหตุการณ์ระหว่างช่วงสำรวจ เวอร์ชันสองมีไฟล์อย่าง cgroup.events และ memory.events ที่ออกแบบมาเพื่อให้รอรับการเปลี่ยนแปลงผ่าน inotify ได้โดยตรง ตรงกับแนวคิดสมัครรับข้อมูลอย่างเป๊ะ

ความต่างข้อที่สามคือคุณสมบัติที่มีเฉพาะในเวอร์ชันสอง ได้แก่ Pressure Stall Information ที่รายงานว่าระบบติดขัดเพราะทรัพยากรมากเพียงไหน, ตรรกะแบบ no internal process ที่ทำให้กลุ่มระดับกลางทำหน้าที่จัดสรรทรัพยากรล้วน ๆ ไม่มีกระบวนการปนอยู่ ทำให้การแบ่งสัดส่วนคาดการณ์ได้ และการตั้งค่าเพดานแบบรวมกันได้อย่างราบรื่นระหว่างกลุ่มแม่กับกลุ่มลูก

ตารางเปรียบเทียบต่อไปนี้ช่วยย้ำจุดต่างที่สำคัญที่สุด

หัวข้อเปรียบเทียบ	Cgroups v1	Cgroups v2
โครงสร้างลำดับชั้น	แยกตามตัวควบคุมแต่ละตัว	ลำดับชั้นเดียวทั้งระบบ
การแจ้งเตือนเหตุการณ์	ไม่มีมาตรฐาน ต้องสำรวจเอง	มีไฟล์เหตุการณ์รองรับ inotify
การกำหนดค่าระดับกลาง	กระบวนการปนกับการจัดสรรได้	บังคับแยกชัดเจน
Pressure Stall Information	ไม่มี	มีให้ใช้งาน
การรองรับในเครื่องมือสมัยใหม่	ถอยหลังลงเรื่อย ๆ	เป็นค่าเริ่มต้น

หลักการเผยแพร่สมัครรับใน Cgroups v2 ไม่ใช่แค่ศัพท์เทคนิคสวย ๆ แต่ให้ประโยชน์ที่จับต้องได้ในงานดูแลระบบประจำวัน ประโยชน์ข้อแรกคือความแม่นยำในการติดตาม

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

อีกจุดที่มักถูกมองข้ามคือเรื่องความเสถียรในระยะยาว ระบบที่ยังค้างใช้เวอร์ชันแรกจะเจอปัญหาว่าเครื่องมือใหม่ ๆ ไม่รองรับ หรือต้องเปิดโหมดรองรับทั้งสองเวอร์ชันซึ่งเพิ่มภาระเคอร์เนล การวางแผนย้ายให้เสร็จภายใน 2026 จึงเป็นเรื่องที่เราควรลงมือจริงจัง โดยเริ่มจากเครื่องทดสอบก่อนแล้วค่อยขยายไปยังเซิร์ฟเวอร์งานผลิต

ประโยชน์ที่ได้จริงจากกลไกเผยแพร่สมัครรับใน Cgroups v2

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

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

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

ทฤษฎีพูดมามากพอแล้ว ต่อไปเป็นขั้นตอนการลงมือจริงที่ผมใช้เป็นเส้นทางมาตรฐานเวลาตั้งระบบใหม่ ขั้นแรกคือตรวจสอบว่าระบบของเราเปิดใช้ Cgroups v2 แล้ว

ด้วยคำสั่งตรวจสอบระบบไฟล์ที่จุดติดตั้ง /sys/fs/cgroup ถ้าเห

ประโยชน์ข้อสุดท้ายและสำคัญที่สุดในสายตาผมคือการเชื่อมต่อกับระบบอื่นได้อย่างเป็นธรรมชาติ ข้อมูลเหตุการณ์ที่ได้เป็นข้อความง่าย ๆ ที่เอาไปป้อนเข้าระบบรวบรวมสถิติ ระบบแจ้งเตือน หรือแม้แต่โมเดลปัญญาประดิษฐ์ที่ช่วยพยากรณ์ปัญหาล่วงหน้าได้ ผมเองเคยต่อข้อมูล Pressure Stall Information เข้ากับแดชบอร์ดตรวจสอบ ทำให้เห็นแนวโน้มการติดขัดของหน่วยความจำหลายวันก่อนที่ระบบจะพังจริง ช่วยวางแผนขยายทรัพยากรได้ทันเวลา ไม่ต้องรอจนวิกฤตแล้วค่อยแก้แบบเหน็ดเหนื่อยตอนดึก

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

วิธีตั้งค่าและใช้งานกลไกเหตุการณ์ของ Cgroups v2 ทีละขั้น

ทฤษฎีพูดมามากพอแล้ว ต่อไปเป็นขั้นตอนการลงมือจริงที่ผมใช้เป็นเส้นทางมาตรฐานเวลาตั้งระบบใหม่ ขั้นแรกคือตรวจสอบว่าระบบของเราเปิดใช้ Cgroups v2 แล้ว ด้วยคำสั่งตรวจสอบระบบไฟล์ที่จุดติดตั้ง /sys/fs/cgroup ถ้าเห

คำถามที่พบบ่อย

Cgroups v2 แตกต่างจาก Cgroups v1 อย่างไร และทำไมจึงควรใช้เวอร์ชันสอง?

ความแตกต่างที่สำคัญที่สุดคือโครงสร้างแบบลำดับชั้นเดียว (single hierarchy) ใน Cgroups v2 กระบวนการหนึ่งจะอยู่ในกลุ่มเดียวเท่านั้น และตัวควบคุมทรัพยากรทั้งหมดจะเห็นในลำดับชั้นเดียวกัน ต่างจากเวอร์ชันแรกที่แต่ละตัวควบคุมสามารถมีโครงสร้างลำดับชั้นแยกกันได้ ซึ่งทำให้เกิดความสับสนและการตั้งค่าที่ขัดแย้งกันเองได้บ่อยครั้ง เคอร์เนล Linux ตั้งแต่รุ่น 5.1 เป็นต้นมารองรับ Cgroups v2 อย่างเต็มรูปแบบ การใช้ v2 ช่วยให้การจัดการทรัพยากรชัดเจนและคาดเดาได้มากขึ้น โดยเฉพาะเมื่อรันคอนเทนเนอร์จำนวนมากผ่าน Docker, Podman หรือ Kubernetes ซึ่งทั้งหมดนี้อาศัย Cgroups เป็นรากฐานในการจำกัดทรัพยากรของคอนเทนเนอร์แต่ละตัว

สถาปัตยกรรม Pub/Sub ใน Cgroups v2 ทำงานอย่างไร?

ในบริบทของ Cgroups v2 รูปแบบ Publish/Subscribe หมายถึงวิธีการรายงานเหตุการณ์ที่เคอร์เนลทำหน้าที่เป็นผู้เผยแพร่ (Publisher) คอยเผยแพร่สถานะและเหตุการณ์ที่เกี่ยวข้องกับการใช้ทรัพยากรออกมา ส่วนฝั่งผู้รับ (Subscriber) คือเดอมอนหรือเครื่องมือติดตามระบบ เช่น systemd, kubelet หรือ prometheus ที่เปิดฟังอยู่ โดยทั้งสองฝ่ายไม่จำเป็นต้องรู้จักกันโดยตรง ผู้รับจะเปิดดีสคริปเตอร์ชี้ไปที่ไฟล์เหตุการณ์แล้วรอด้วยกลไก poll หรือ epoll เมื่อเคอร์เนลปรับปรุงค่าในไฟล์ ผู้รับจะได้รับสัญญาณให้อ่านค่าใหม่ทันที ทำให้ไม่ต้องวนลูปถามเคอร์เนลซ้ำ ๆ ประหยัดทรัพยากรและได้ข้อมูลแบบเกือบเรียลไทม์

ไฟล์ใดบ้างที่ใช้ในการรับเหตุการณ์จาก Cgroups v2 และมีเหตุการณ์อะไรให้ติดตาม?

หัวใจของการแจ้งเตือนอยู่ที่ไฟล์ cgroup.events และ cgroup.type พร้อมกลไก inotify และ epoll ในการรอคอยเหตุการณ์ เหตุการณ์ที่พบบ่อยในการใช้งานจริงได้แก่ populated ซึ่งบอกว่ามีหรือไม่มีกระบวนการอยู่ในกลุ่ม, frozen เมื่อกลุ่มถูกหยุดชั่วคราวด้วยคำสั่ง freeze, oomkill เมื่อตัวควบคุมหน่วยความจำสังหารกระบวนการเพราะใช้เกินขีดจำกัด และ pressured เมื่อระบบเริ่มกดดันทรัพยากรจนมีผลต่อประสิทธิภาพ นอกจากนี้ไฟล์ memory.events ยังบันทึกตัวนับเหตุการณ์สำคัญเช่น oom, oomkill และ max ที่บอกว่ามีกระบวนการพยายามใช้ทรัพยากรเกินเพดานมากี่ครั้ง ทำให้วินิจฉัยปัญหาได้ก่อนผู้ใช้ปลายทางจะรู้สึกได้เอง

Cgroups v2 เกี่ยวข้องกับ Docker, Kubernetes และเครื่องมือคอนเทนเนอร์อื่นอย่างไร?

Cgroups v2 คือรากฐานที่อยู่เบื้องหลังเทคโนโลยีคอนเทนเนอร์ที่เราใช้กันทุกวัน ไม่ว่าจะเป็น Docker, Podman หรือ Kubernetes ซึ่งต่างก็อาศัย Cgroups ในการจำกัดทรัพยากรของคอนเทนเนอร์แต่ละตัว ทั้งด้าน CPU หน่วยความจำ การเข้าถึงดิสก์ และจำนวนกระบวนการ เมื่อเข้าใจกลไก Pub/Sub ใน Cgroups v2 แล้ว เราจะสามารถวินิจฉัยปัญหาได้ลึกกว่าเครื่องมือสำเร็จรูปทั่วไปอยู่หลายขั้น เช่น การรู้ทันว่าคอนเทนเนอร์ถูก OOM Kill เพราะใช้หน่วยความจำเกินขีดจำกัด หรือติดตามค่าผ่านไฟล์อินเทอร์เฟซภายใต้ /sys/fs/cgroup เช่น memory.max และ memory.current ได้โดยตรง

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6