แก้ไขปัญหา Matrix Synapse “Too Many Open Files” บน systemd

Matrix Synapse อาจเริ่มต้นทำงานได้ตามปกติแล้วหยุดรับการเชื่อมต่อ แสดงข้อความ “Too many open files” หรืออาจค้างอยู่ภายใต้ภาระงานหนัก ในการติดตั้งบน systemd สิ่งแรกที่ควรตรวจสอบคือขีดจำกัดของตัวจัดการไฟล์ (file-descriptor limit) ที่กระบวนการ Synapse กำลังทำงานอยู่ได้รับมา การเปลี่ยนค่าในเชลล์ulimitหรือการแก้ไขไฟล์ PAM limits มักจะไม่เปลี่ยนแปลงขีดจำกัดสำหรับบริการที่ systemd เริ่มทำงาน

ขั้นตอนด้านล่างนี้ใช้กับโฮสต์ Linux ที่ Synapse ทำงานเป็นบริการ systemd หน่วยอาจมีชื่อmatrix-synapse.service, matrix-synapse@.service, หรือชื่อเฉพาะของแพ็กเกจ โปรดตรวจสอบหน่วยที่ถูกต้องก่อนคัดลอกคำสั่ง หาก Synapse ทำงานใน Docker, Kubernetes หรือคอนเทนเนอร์อื่น โปรดดูส่วนแยกต่างหากด้านล่าง

“มีไฟล์เปิดอยู่มากเกินไป” หมายความว่าอย่างไร?

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

คำถามที่พบบ่อย (FAQ) อย่างเป็นทางการของ Synapse ระบุว่า การเชื่อมต่อและการใช้งาน Federation ที่สูงอาจใช้ File Handle จำนวนมาก และการใช้งานจนหมดอาจทำให้เซิร์ฟเวอร์หยุดรับการเชื่อมต่อ TCP ใหม่ คำแนะนำดังกล่าวระบุให้เพิ่มขีดจำกัดเป็นอย่างน้อย 4,096 เมื่อเทียบกับค่าเริ่มต้นเดิม เช่น 1,024 หรือ 256 ให้ถือว่านี่เป็นค่าต่ำสุดในการแก้ไขปัญหาสำหรับสถานการณ์ที่อธิบายไว้ ไม่ใช่คำแนะนำด้านความจุที่ครอบคลุมสำหรับโฮมเซิร์ฟเวอร์ทุกเครื่อง เริ่มต้นด้วยการตรวจสอบขีดจำกัดที่ใช้งานได้จริงและการใช้งานจริง

เอกสารประกอบการใช้งาน getrlimit และ prlimit ของ Linuxอธิบายถึงขีดจำกัดแบบอ่อนและแบบแข็งต่อกระบวนการทำงาน Synapse ก็มีsoft_file_limitการตั้งค่าเช่น กัน โดยเอกสาร อ้างอิงการกำหนดค่า Synapseระบุค่าเริ่มต้นเป็นศูนย์ ซึ่งบอกให้ Synapse ตั้งค่าขีดจำกัดแบบอ่อนให้เท่ากับขีดจำกัดแบบแข็งที่สามารถใช้งานได้

1. ตรวจสอบอุปกรณ์และวินิจฉัยสาเหตุของปัญหา

ก่อนอื่นให้ค้นหาชื่อบริการที่ถูกต้อง ในการติดตั้งแบบแพ็กเกจส่วนใหญ่ ชื่อบริการจะเป็น `service_name` matrix-synapse.serviceแต่ห้ามสันนิษฐานว่าชื่อนั้นเป็นชื่อบริการหากการติดตั้งของคุณใช้หน่วยหรือเวิร์กเกอร์แบบกำหนดเอง

systemctl list-units --type=service --all | grep -i synapse
systemctl status matrix-synapse.service --no-pager
journalctl -u matrix-synapse.service --since "30 minutes ago" --no-pager

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

systemctl show matrix-synapse.service -p LimitNOFILE -p MainPID

LimitNOFILEแสดงขีดจำกัดที่กำหนดค่าไว้ของตัวจัดการบริการ ไม่ใช่จำนวนตัวอธิบายที่เปิดอยู่ในปัจจุบัน คำสั่งเชลล์ เช่น `git log` ulimit -nรายงานเฉพาะขีดจำกัดของเชลล์ปัจจุบันเท่านั้น และไม่ใช่หลักฐานยืนยันขีดจำกัดของบริการ

2. เพิ่มขีดจำกัดการใช้งานบริการ systemd ด้วย drop-in

ใช้ systemd drop-in เพื่อให้การอัปเดตแพ็กเกจไม่จำเป็นต้องแก้ไขไฟล์ vendor unit ค่าต่อไปนี้เป็นเพียงตัวอย่าง ไม่ใช่ค่าที่เหมาะสมที่สุดสำหรับทุกเซิร์ฟเวอร์ เลือกค่าจำกัดที่มีพื้นที่เหลือมากกว่าการใช้งานสูงสุดที่สังเกตได้ และตรวจสอบความเข้ากันได้ของแอปพลิเคชันและส่วนประกอบต่างๆ ก่อนที่จะตั้งค่าที่สูงผิดปกติ

sudo systemctl edit matrix-synapse.service

เพิ่มข้อความนี้ลงในส่วนเพิ่มเติมใหม่ของบรรณาธิการ:

[Service]
LimitNOFILE=65536

บันทึกและออกจากโปรแกรม จากนั้นโหลด systemd ใหม่ และรีสตาร์ท Synapse ในช่วงเวลาการบำรุงรักษาที่เหมาะสม:

sudo systemctl daemon-reload
sudo systemctl restart matrix-synapse.service
systemctl show matrix-synapse.service -p LimitNOFILE

ค่า เดียวLimitNOFILEสามารถกำหนดทั้งขีดจำกัดแบบอ่อนและแบบแข็งสำหรับบริการใน systemd ได้ คู่มือ systemd ยังอนุญาตให้soft:hardใช้ค่าคู่ได้ด้วย ขีดจำกัดแบบอ่อนต้องไม่เกินขีดจำกัดแบบแข็ง ก่อนที่จะเลือกค่าที่สูงมาก โปรดตรวจสอบเอกสาร systemd.execซึ่งระบุถึงข้อกังวลด้านความเข้ากันได้สำหรับโปรแกรมที่ใช้select(2)อินเทอร์เฟซแบบเก่าที่มีตัวอธิบายมากกว่า 1,023 อย่าคิดว่าทุกไลบรารีหรือปลั๊กอินในการใช้งานของคุณรองรับขีดจำกัดใดๆ ก็ตาม

3. ตรวจสอบการตั้งค่าและบริการของตัวประมวลผล (Worker Services) ของ Synapse เอง

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

สำหรับการใช้งานแบบมัลติโปรเซส แต่ละเวิร์กเกอร์ถือเป็นโปรเซสแยกต่างหาก และอาจเริ่มต้นโดยยูนิตหรืออินสแตนซ์เทมเพลตที่แยกต่างหาก การเพิ่มขีดจำกัดของบริการหลักไม่ได้หมายความว่าเวิร์กเกอร์ทุกตัวจะมีขีดจำกัดตามที่ต้องการโดยอัตโนมัติ ตรวจสอบชื่อยูนิตเวิร์กเกอร์จริงด้วยคำสั่ง `sudo apt install` systemctl list-unitsจากนั้นใช้และตรวจสอบ drop-in ที่เหมาะสมสำหรับแต่ละบริการที่ต้องการ

ในทำนองเดียวกัน การตั้งค่าใน/etc/security/limits.confเชลล์ล็อกอินulimitโดยทั่วไปจะไม่ควบคุมบริการระบบที่เริ่มต้นโดยตรงโดย systemd สำหรับการตั้งค่านี้ ให้เปลี่ยนขีดจำกัดทรัพยากรของหน่วย และตรวจสอบในกระบวนการที่ systemd เริ่มต้นจริง

4. หาก Synapse ทำงานในคอนเทนเนอร์

การตั้งค่า systemd ระดับโฮสต์เพื่อแทนที่บริการอื่นจะไม่เปลี่ยนแปลงขีดจำกัดตัวระบุไฟล์ของคอนเทนเนอร์โดยอัตโนมัติ ให้กำหนดค่าเลเยอร์รันไทม์หรือเลเยอร์การจัดการคอนเทนเนอร์ สำหรับ Docker Compose คำจำกัดความของบริการรองรับการตั้งค่าต่อคอนเทนเนอร์ulimitsตัวอย่างเช่น:

services:
  synapse:
    ulimits:
      nofile:
        soft: 65536
        hard: 65536

ตัวเลขนี้เป็นเพียงตัวอย่างเท่านั้น ขนาดควรขึ้นอยู่กับการใช้งานและข้อจำกัดของโฮสต์ เอกสารอ้างอิงบริการ Docker Composeอธิบายulimitsการตั้งค่านี้ไว้ สำหรับ Docker Engine 29 นั้น บันทึกการเผยแพร่ของ Docker ระบุว่ามีการเปลี่ยนแปลงค่าเริ่มต้นของขีดจำกัด nofile ที่เกี่ยวข้องกับ containerd 2.1.5: คอนเทนเนอร์อาจได้รับ 1,024 แทนที่จะเป็นค่าเริ่มต้น 1,048,576 ก่อนหน้านี้ หากปัญหานี้เกิดขึ้นหลังจากอัปเกรด Engine ให้ตรวจสอบขีดจำกัดคอนเทนเนอร์ที่มีผลและตั้งค่า ulimit ที่ต้องการอย่างชัดเจนในการกำหนดค่าการปรับใช้ ดูบันทึกการเผยแพร่ Docker Engine 29และเอกสารอ้างอิง docker run

5. ตรวจสอบขีดจำกัดของกระบวนการ Synapse ที่กำลังทำงานอยู่

หลังจากรีสตาร์ทแล้ว ให้ตรวจสอบขีดจำกัดระดับกระบวนการ ไม่ใช่แค่การตั้งค่าของ systemd เท่านั้น หา PID หลักและตรวจสอบขีดจำกัดที่เคอร์เนลรายงาน:

PID=$(systemctl show --property=MainPID --value matrix-synapse.service)
grep "Max open files" "/proc/$PID/limits"
find "/proc/$PID/fd" -mindepth 1 -maxdepth 1 | wc -l

หาก PID หลักเป็นศูนย์หรือเป็นของโปรแกรมห่อหุ้ม (wrapper) แทนที่จะเป็น Synapse ให้ระบุโปรเซส Synapse ใน cgroup ของบริการและตรวจสอบ PID นั้นแทน จำนวนตัวอธิบาย (descriptor count) เป็นภาพรวม ณ ขณะนั้น ให้ทำซ้ำในระหว่างการโหลดที่เหมาะสม ตรวจสอบให้แน่ใจว่า “จำนวนไฟล์ที่เปิดได้สูงสุด” สะท้อนถึงขีดจำกัดแบบอ่อนและแบบแข็งที่คุณตั้งใจไว้ จำนวนไฟล์ยังคงต่ำกว่าขีดจำกัดแบบอ่อนอย่างเห็นได้ชัด และบันทึก (journal) ไม่รายงานข้อผิดพลาดอีกต่อไป

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

เมื่อการเพิ่มวงเงินต่อบริการไม่เพียงพอ

หากบันทึกรายงานข้อผิดพลาดเกี่ยวกับการหมดพื้นที่ตารางไฟล์ทั่วทั้งระบบ เช่นENFILEให้ตรวจสอบการใช้งานทั่วทั้งโฮสต์และบริการอื่นๆ การเปลี่ยนแปลงเฉพาะบริการLimitNOFILEจะไม่เพิ่มความจุของเคอร์เนลทั่วทั้งระบบ หลีกเลี่ยงการเปลี่ยนแปลงขีดจำกัดเคอร์เนลโดยรวมโดยไม่ยืนยันข้อผิดพลาดและทำความเข้าใจผลกระทบต่อโฮสต์ทั้งหมด หากขีดจำกัดที่รายงานของบริการยังคงต่ำหลังจากติดตั้ง drop-in แล้ว ให้เรียกใช้คำสั่งsystemctl cat matrix-synapse.serviceเพื่อยืนยันว่า drop-in โหลดแล้ว ตรวจสอบชื่อหน่วย โหลด systemd ใหม่ และรีสตาร์ทหน่วยที่ถูกต้อง

ตรวจสอบตัวเองอย่างรวดเร็ว

• คุณระบุหน่วยหรือคอนเทนเนอร์ Synapse ที่บันทึกข้อผิดพลาดได้อย่างแน่ชัดหรือไม่?
• systemctl showรายงานระบุขีดจำกัดที่ตั้งไว้สำหรับหน่วยนั้นหรือไม่?
• /proc/<Synapse-PID>/limitsหลังจากรีสตาร์ทแล้ว แสดงค่าขีดจำกัดแบบอ่อนและแบบแข็งตามที่ต้องการหรือไม่ ?
• จำนวนตัวบ่งชี้ต่ำกว่าขีดจำกัดที่ยอมรับได้ภายใต้ภาระสูงสุดปกติหรือไม่?
• มีการตรวจสอบหน่วยงานผู้ปฏิบัติงานและการตั้งค่าคอนเทนเนอร์แยกกันหรือไม่ ในกรณีที่สามารถทำได้?
• ปัญหาดังกล่าวหายไปแล้วหรือไม่ หรือปริมาณการใช้งานยังคงเพิ่มขึ้นเรื่อยๆ จนเข้าใกล้ระดับสูงสุดใหม่?

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

แหล่งที่มา

• คำถามที่พบบ่อยเกี่ยวกับการจัดการ Synapse: ปัญหาไฟล์แฮนเดิลหมด
• ข้อมูลอ้างอิงการตั้งค่า Synapse: soft_file_limit
• คู่มือ systemd.exec: ข้อจำกัดของทรัพยากรบริการ
• คู่มือ Linux: getrlimit และ prlimit
• บันทึกการเปลี่ยนแปลงของ Docker Engine 29