แก้ไขปัญหา BigBlueButton Kurento Media Server ขัดข้องขณะใช้งานหนัก

กระบวนการ Kurento Media Server (KMS) ที่หยุดทำงานระหว่างการประชุม BigBlueButton ที่มีผู้ใช้งานจำนวนมาก อาจขัดจังหวะการบันทึก หรือในเวอร์ชันเก่า อาจขัดจังหวะเสียงและวิดีโอสดได้ ผลลัพธ์เบื้องต้นที่สำคัญไม่ใช่แค่การเริ่มต้นบริการใหม่เท่านั้น แต่คือการทราบว่าส่วนใดของซอฟต์แวร์จัดการสื่อที่ได้รับผลกระทบ ทรัพยากรหรือความล้มเหลวใดที่นำไปสู่การหยุดทำงาน และการแก้ไขนั้นจะช่วยให้การประชุมครั้งต่อไปที่คล้ายคลึงกันมีความเสถียรหรือไม่

เริ่มต้นด้วยการตรวจสอบเวอร์ชันของ BigBlueButton และบทบาทของ Kurento บนเซิร์ฟเวอร์นี้ BigBlueButton เวอร์ชัน 2.5 และใหม่กว่าใช้ mediasoup เป็นค่าเริ่มต้นสำหรับสื่อ WebRTC สด Kurento อาจยังคงมีอยู่สำหรับการบันทึกหรือเนื่องจากผู้ดูแลระบบยังคงใช้การตั้งค่าแบบเก่า/กำหนดเอง ดังนั้น “Kurento ขัดข้อง” จึงไม่ได้พิสูจน์ว่า KMS เป็นสาเหตุของภาระงานของเว็บแคมที่มากเกินไป โปรดดูคู่มือการแก้ไขปัญหาอย่างเป็นทางการของ BigBlueButtonสำหรับความแตกต่างของเวอร์ชัน วิธีแก้ปัญหา KMS โดยละเอียดด้านล่างนี้ได้มาจากคู่มือการปรับแต่งเซิร์ฟเวอร์ BigBlueButton เวอร์ชัน 2.7โปรดตรวจสอบเอกสารที่ตรงกับเวอร์ชันที่ติดตั้งของคุณก่อนนำไปใช้

ขั้นแรกให้ตรวจสอบว่าอะไรล้มเหลว

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

บนโฮสต์ BigBlueButton ให้เริ่มต้นด้วยการตรวจสอบแบบอ่านอย่างเดียว:

sudo bbb-conf --check
sudo systemctl status kurento-media-server --no-pager
sudo journalctl -u kurento-media-server --since "1 hour ago" --no-pager
sudo ls -lt /var/log/kurento-media-server/ | head

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

ตรวจสอบว่าผู้ใช้ใช้ Kurento สำหรับการรับส่งข้อมูลที่ล้มเหลวหรือไม่ ใน Firefox about:webrtcสามารถแสดงรายละเอียดการเชื่อมต่อระหว่างผู้ใช้ได้ ส่วน Chrome ก็มีเช่นกันchrome://webrtc-internalsเอกสารการแก้ไขปัญหาของ BigBlueButton อธิบายถึงการตรวจสอบรายละเอียดเซสชันที่เจรจาต่อรองสำหรับ mediasoup นอกจากนี้ ให้ตรวจสอบบริการสื่อที่กำหนดค่าไว้และเวิร์กโฟลว์การบันทึกของคุณ หากสื่อสดอยู่ใน mediasoup และการบันทึกหยุดลงเมื่อ KMS ปิดตัวลงเท่านั้น ให้ปรับแต่งเส้นทางการบันทึก/Kurento แทนที่จะเปลี่ยนการตั้งค่าเว็บแคมสดโดยไม่ตรวจสอบให้ดี

หาแรงดันที่เกิดขึ้นก่อนทางออก

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

• free -hและvmstat 1สำหรับหน่วยความจำที่ใช้งานได้ การสลับข้อมูล และแรงดันคิวการทำงาน
• mpstat -P ALL 1สำหรับการทดสอบความเต็มประสิทธิภาพของ CPU แบบต่อคอร์ หากsysstatติดตั้งเครื่องมือที่จำเป็นแล้ว
• df -hและiostat -xz 1สำหรับระบบไฟล์หรือความหน่วงแฝงในการจัดเก็บข้อมูลแบบเต็มรูปแบบ หากมีให้บริการ
• journalctl -k --since "1 hour ago"สำหรับข้อความจากเคอร์เนล รวมถึงข้อความแจ้งการหยุดทำงานเนื่องจากหน่วยความจำไม่เพียงพอ
• ตรวจสอบสถานะ systemd และบันทึก KMS เพื่อดูการออกจากระบบซ้ำๆ ความล้มเหลวของไปป์ไลน์ และการดำเนินการสื่อใดที่กำลังทำงานอยู่

อย่าพึ่งพาค่าเฉลี่ย CPU ของเซิร์ฟเวอร์เพียงอย่างเดียว กระบวนการสื่ออาจถูกจำกัดด้วยคอร์ที่ทำงานหนักเพียงคอร์เดียว ในขณะที่คอร์อื่นๆ ดูเหมือนจะว่าง หรือแรงดันหน่วยความจำอาจทำให้กระบวนการหยุดทำงานโดยไม่ต้องมีการใช้งาน CPU สูงเป็นเวลานาน ในทางกลับกัน รายงาน "กล้องค้าง" ของผู้ใช้อาจเกิดขึ้นในขณะที่ KMS ยังคงทำงานได้ปกติ เนื่องจาก UDP ถูกบล็อก หรือเบราว์เซอร์ไม่สามารถสร้างเส้นทาง WebRTC ได้ เอกสารของ BigBlueButton ระบุว่า TURN เป็นวิธีแก้ไขสำหรับเครือข่ายที่มีข้อจำกัด TURN อาจช่วยปรับปรุงการเชื่อมต่อ แต่ไม่ได้เพิ่มความสามารถในการประมวลผลของ KMS หากบริการยังคงทำงานอยู่และบันทึกไม่แสดงเหตุการณ์เกี่ยวกับทรัพยากร ให้ตรวจสอบ ICE ไฟร์วอลล์ และการเชื่อมต่อของไคลเอ็นต์ก่อนที่จะเพิ่มขีดจำกัดสื่อ

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

เลือกวิธีการรักษาที่สอดคล้องกับหลักฐานที่มีอยู่

สำหรับการใช้งาน KMS รุ่นเก่า จำเป็นต้องแยกเวิร์กโหลดสื่อออกจากกัน

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

การแยกส่วนนี้เป็นมาตรการในการควบคุมและกระจาย ไม่ใช่สิ่งทดแทน CPU หน่วยความจำ หรือพื้นที่จัดเก็บข้อมูลที่เพียงพอ นอกจากนี้ยังอาจเพิ่มการใช้ทรัพยากรพื้นฐานเนื่องจากมีกระบวนการเพิ่มเติมทำงาน กำหนดช่วงเวลาการบำรุงรักษา: sudo bbb-conf --restartจะขัดจังหวะเซสชันที่ใช้งานอยู่ อย่าแก้ไขไฟล์บริการที่สร้างขึ้นด้วยตนเอง หรือสันนิษฐานว่าคำสั่งที่ระบุไว้ในเอกสารสำหรับเวอร์ชัน 2.7 สามารถนำไปใช้กับเวอร์ชันใหม่กว่าหรือการติดตั้งที่ผู้จำหน่ายแก้ไขได้โดยไม่เปลี่ยนแปลง

ตั้งค่าเกณฑ์สื่อเมื่อเซิร์ฟเวอร์ต้องการจำกัดการเข้าถึง

สำหรับเวอร์ชันที่ใช้ KMS ซึ่งรองรับตัวเลือกที่ระบุไว้ในเอกสาร BigBlueButton อนุญาตให้mediaThresholdsกำหนดค่าสำหรับglobal, perRoom, และperUserคู่มือเวอร์ชัน 2.7 แสดงค่าเหล่านี้ใน/etc/bigbluebutton/bbb-webrtc-sfu/production.ymlไฟล์ override ซึ่งมีจุดประสงค์เพื่อให้คงอยู่หลังจากการอัปเกรดแพ็กเกจ ค่าศูนย์หมายถึงไม่มีการจำกัดในตัวอย่างที่ระบุไว้ การถึงขีดจำกัดที่กำหนดไว้สามารถทำให้เกิดข้อผิดพลาด “ทรัพยากรสื่อไม่พร้อมใช้งาน (2002)” เมื่อผู้เข้าร่วมพยายามแชร์เว็บแคม

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

ลดความต้องการสื่อก่อนที่จะเพิ่มสมมติฐานด้านกำลังการผลิต

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

พิจารณาการอัปเกรดหรือเปลี่ยนแปลงสถาปัตยกรรมเมื่อข้อจำกัดกลับมาอีกครั้ง

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

ตรวจสอบความถูกต้องของการเปลี่ยนแปลงภายใต้การประชุมที่เทียบเคียงได้

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

• ตรวจสอบให้แน่ใจว่าหน่วย KMS ที่เกี่ยวข้องยังคงทำงานอยู่และไม่เข้าสู่ลูปการเริ่มต้นใหม่
• เปรียบเทียบการใช้งาน CPU ต่อคอร์ หน่วยความจำที่ใช้งานได้และพื้นที่สวอป การทำงานของดิสก์ และบันทึกต่างๆ ก่อนและระหว่างการทดสอบ
• ตรวจสอบเสียง เว็บแคม การแชร์หน้าจอ และการบันทึกแยกกัน ตามบทบาทที่ Kurento ปฏิบัติจริง
• ตรวจสอบว่าข้อผิดพลาด 2002, การตั้งค่าสื่อล้มเหลว หรือรายงานจากผู้ใช้มีการเปลี่ยนแปลงหรือไม่ ไม่มีตัวชี้วัดใดเพียงตัวเดียวที่พิสูจน์ได้ว่าการแก้ไขปัญหาได้ผล
• ทำซ้ำในช่วงเวลาที่คาดว่าจะมีการใช้งานหนาแน่น ก่อนที่จะประกาศว่าการเปลี่ยนแปลงกำลังการผลิตสำเร็จแล้ว

หากบริการยังคงล่ม ให้บันทึกบันทึก KMS และหน้าต่างบันทึกเหตุการณ์ ข้อความเคอร์เนล เวอร์ชัน BigBlueButton/Kurento ที่ติดตั้ง และการตั้งค่าการใช้งานสำหรับผู้ดูแลระบบหรือทีมสนับสนุน หากบริการยังคงทำงานได้ปกติ แต่ผู้ใช้ยังคงไม่สามารถเชื่อมต่อได้ ให้เปลี่ยนการตรวจสอบไปที่ ICE candidates กฎไฟร์วอลล์ ความพร้อมใช้งานของ TURN และการวินิจฉัย WebRTC ฝั่งเบราว์เซอร์ ผลลัพธ์ที่ถูกต้องคือเวิร์กโหลดสื่อที่เสถียรพร้อมข้อจำกัดที่เข้าใจได้ ไม่ใช่จำนวนสตรีมที่ไม่จำกัดหรือการรับประกันว่าการกำหนดค่าเดียวจะเหมาะกับทุกเซิร์ฟเวอร์

แหล่งที่มาและหมายเหตุเกี่ยวกับเวอร์ชัน

• BigBlueButton 2.7: การปรับแต่งเซิร์ฟเวอร์ — กระบวนการ Kurento หลายรายการ เกณฑ์สื่อ และการกำหนดค่าที่เกี่ยวข้อง
• BigBlueButton: คู่มือการแก้ไขปัญหา — การระบุ media-stack ปัจจุบัน ค่าเริ่มต้นของ mediasoup หมายเหตุของ Kurento และการแก้ไขปัญหาเครือข่าย
• BigBlueButton: ไฟล์การกำหนดค่า — คำแนะนำเกี่ยวกับไฟล์การกำหนดค่าและไฟล์การแก้ไขเพิ่มเติม

เอกสารนี้ได้รับการตรวจสอบเมื่อวันที่ 5 ตุลาคม 2026 ตัวอย่างปริมาณงานและเกณฑ์ของ Kurento ที่แสดงไว้ข้างต้นนั้นเชื่อมโยงกับเอกสาร BigBlueButton 2.7 โดยเฉพาะ โปรดตรวจสอบบันทึกการเผยแพร่และคู่มือผู้ดูแลระบบที่เกี่ยวข้องก่อนนำการตั้งค่าไปใช้ที่อื่น