หาก ONLYOFFICE Document Server ขัดข้องหรือรีสตาร์ทเนื่องจาก VPS ของคุณหน่วยความจำไม่เพียงพอ ให้ตรวจสอบก่อนว่าเกิดเหตุการณ์หน่วยความจำไม่เพียงพอจริงหรือไม่ และตรวจสอบว่าขีดจำกัดหน่วยความจำของ Docker ต่ำเกินไปหรือไม่ จากนั้นให้เพิ่ม RAM ทางกายภาพให้เพียงพอสำหรับปริมาณงาน และเพิ่ม swap ไว้เป็นเพียงบัฟเฟอร์สำรองเท่านั้น การรีสตาร์ทโปรแกรมแก้ไขซ้ำๆ จะไม่สามารถแก้ไขปัญหาการขาดแคลนความจุอย่างต่อเนื่องได้
1. พิสูจน์ว่าแรงดันหน่วยความจำทำให้เกิดความล้มเหลว
เริ่มที่ VPS Linux ไม่ใช่ในการตั้งค่าการผสานรวม ONLYOFFICE ข้อความในเบราว์เซอร์ เช่น “ไม่สามารถโหลดเอกสารได้” อาจเกิดจากปัญหาเครือข่ายหรือการตรวจสอบสิทธิ์ ดังนั้นจึงเป็นสิ่งสำคัญที่จะต้องตรวจสอบว่าตัวจัดการหน่วยความจำไม่เพียงพอ (OOM killer) ของ Linux ได้ยุติกระบวนการนั้นจริงหรือไม่
เรียกใช้คำสั่งเหล่านี้ผ่าน SSH แทนที่onlyoffice-document-serverด้วยชื่อคอนเทนเนอร์ที่แสดงโดยdocker ps -a:
free -h
docker ps -a
docker stats --no-stream onlyoffice-document-server
docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}} {{.HostConfig.Memory}} {{.HostConfig.MemorySwap}}' onlyoffice-document-server
free -hแสดง RAM และ swap ที่ใช้งานได้บนโฮสต์ คำสั่ง ` docker docker statsrun` จะวัดหน่วยความจำของคอนเทนเนอร์ที่กำลังทำงานอยู่ ในขณะที่คำสั่ง `inspect` จะรายงานสถานะการถูกฆ่าเนื่องจากหน่วยความจำไม่เพียงพอ (OOM-killed state) รหัสการออกครั้งล่าสุด และขีดจำกัดทรัพยากรที่กำหนดค่าไว้เป็นไบต์HostConfig.Memoryค่าที่ไม่ใช่ศูนย์บ่งชี้ถึงขีดจำกัดหน่วยความจำที่ระบุไว้อย่างชัดเจน สถิติหน่วยความจำของ Docker อาจไม่รวมแคชไฟล์บางส่วน ดังนั้นจึงควรเปรียบเทียบกับค่าที่วัดได้จากโฮสต์แทนที่จะถือว่าเป็นภาพรวมทั้งหมด ดูข้อมูลอ้างอิงสถิติของ Docker
ตัวอย่างการตรวจสอบหน่วยความจำ: เปรียบเทียบ RAM ที่ใช้งานได้ของโฮสต์กับปริมาณการใช้งานและขีดจำกัดของคอนเทนเนอร์เซิร์ฟเวอร์เอกสาร ค่าที่แสดงเป็นเพียงตัวอย่างเท่านั้น
หากคอนเทนเนอร์หยุดทำงานแล้วdocker statsจะไม่สามารถแสดงค่าสูงสุดก่อนหน้าได้ โปรดตรวจสอบบันทึกเคอร์เนลและข้อความแอปพลิเคชันล่าสุดแทน:
sudo journalctl -k --since "-2 hours" | grep -Ei 'out of memory|killed process|oom'
docker logs --tail 100 onlyoffice-document-server
ข้อความจากเคอร์เนลที่กล่าวถึง “หน่วยความจำไม่เพียงพอ” หรือ “กระบวนการถูกฆ่า” ช่วยระบุถึงกระบวนการที่เกี่ยวข้องOOMKilled=trueเป็นหลักฐานที่ชัดเจนว่าเกิดเหตุการณ์หน่วยความจำไม่เพียงพอในคอนเทนเนอร์ แต่falseไม่ได้หมายความว่าเคอร์เนลของโฮสต์จะไม่ฆ่ากระบวนการลูกในขณะที่คอนเทนเนอร์ยังคงทำงานอยู่ เช่นเดียวกัน รหัสออก 137 ยืนยันเพียงการยุติด้วย SIGKILL เท่านั้น ไม่ใช่สาเหตุ หากไม่มีหลักฐานหน่วยความจำไม่เพียงพอ ให้ตรวจสอบบันทึกและข้อผิดพลาดในการเชื่อมต่อก่อนที่จะซื้อ RAM เพิ่ม
ตัวอย่างการตรวจสอบ OOM: ตรวจสอบสถานะของคอนเทนเนอร์และข้อความเคอร์เนล แทนที่จะวินิจฉัยความล้มเหลวของหน่วยความจำจากข้อผิดพลาดของเบราว์เซอร์เพียงอย่างเดียว
2. ควรจัดสรร RAM ให้ VPS เพียงพอ ก่อนที่จะปรับแต่งสิ่งอื่นใด
ณ เดือนตุลาคม 2026 เอกสาร README อย่างเป็นทางการของ ONLYOFFICE สำหรับ Docker Document Serverระบุว่าควรมี RAM 4 GB ขึ้นไป และ Swap อย่างน้อย 2 GB ส่วนเอกสารการติดตั้งแบบคลิกเดียวอย่างเป็นทางการระบุว่าควรใช้ RAM 4 GB สำหรับสภาพแวดล้อมการทดสอบของ Docker แนะนำ 8 GB ขึ้นไปสำหรับสภาพแวดล้อมการใช้งานจริง และระบุ Swap อย่างน้อย 4 GB ในข้อกำหนดการติดตั้ง เอกสารเหล่านี้อธิบายถึงบริบทการใช้งานที่แตกต่างกัน ดังนั้นอย่าตีความว่า 4 GB เป็นการรับประกันประสิทธิภาพการทำงานที่เชื่อถือได้ในสภาพแวดล้อมการใช้งานจริง
หาก VPS ของคุณมี RAM เพียง 1-2 GB การอัปเกรดแพ็กเกจเป็นวิธีแก้ปัญหาที่คุ้มค่าที่สุดสำหรับการติดตั้งแบบ Docker แต่ถ้ามีอยู่แล้ว 4 GB ให้ตรวจสอบว่าระบบปฏิบัติการ ฐานข้อมูล รีเวิร์สพร็อกซี Nextcloud และคอนเทนเนอร์อื่นๆ ใช้ RAM ไปเท่าไหร่ เซิร์ฟเวอร์ที่ดูเหมือนจะทำงานได้ราบรื่นในขณะที่ไม่ได้ใช้งาน อาจยังคงมีปัญหาหน่วยความจำไม่เพียงพอเมื่อมีหลายคนเปิดเอกสารหรือแปลงไฟล์สเปรดชีตขนาดใหญ่พร้อมกัน
ในเครื่องที่มีการใช้งานหนัก ให้ใช้เครื่องมือนี้ps aux --sort=-rss | headเพื่อระบุโปรเซสที่ใช้หน่วยความจำมาก และทำซ้ำdocker statsในระหว่างเซสชันการแก้ไขที่เป็นตัวอย่าง ควรสำรองพื้นที่ว่างไว้สำหรับส่วนที่เหลือของเครื่องแทนที่จะจัดสรร RAM ที่มีอยู่ทั้งหมดให้กับ ONLYOFFICE หากความต้องการใช้งานเกินความจุของเครื่อง ให้ย้ายบริการที่ใช้หน่วยความจำมากกว่า หรืออัปเกรด VPS การปรับแต่งในระดับแอปพลิเคชันไม่สามารถสร้างหน่วยความจำทางกายภาพที่ขาดหายไปได้
ตรวจสอบว่า Docker มีข้อจำกัดด้านหน่วยความจำโดยไม่ตั้งใจหรือไม่
โดยปกติแล้วคอนเทนเนอร์ Docker จะไม่มีการจำกัดหน่วยความจำอย่างตายตัว แต่การใช้งานอาจกำหนดข้อจำกัดนั้นได้ด้วย คำสั่ง `docker run` --memoryหรือ `compose up` ของ Compose mem_limitตัวอย่างเช่น การจำกัดหน่วยความจำไว้ที่ 2 GB อาจทำให้เกิดข้อผิดพลาด OOM kill แม้ว่าโฮสต์จะมี RAM เหลืออยู่ 8 GB ก็ตาม ตรวจสอบขีดจำกัดที่แท้จริงก่อนที่จะเปลี่ยนแปลง หากขีดจำกัดนั้นต่ำเกินไปโดยไม่จำเป็น ให้ปรับการตั้งค่า `docker run` หรือ `compose up` เดิมให้เป็นค่าที่เหมาะสมตามการวัดและกำลังการผลิตที่เหลืออยู่ของโฮสต์ ดูเอกสารประกอบเกี่ยวกับการจำกัดทรัพยากร ของ Docker และข้อกำหนดบริการของ Compose
อย่าตั้งค่าการจัดสรรหน่วยความจำแบบไม่จำกัดบน VPS ที่ใช้ร่วมกันโดยไม่คิดให้รอบคอบ เพราะอาจทำให้บริการอื่นๆ เสี่ยงต่อการถูกปิดการทำงานเนื่องจากหน่วยความจำไม่เพียงพอ (OOM kill) นอกจากนี้ ให้ตรวจสอบการ ตั้งค่าในไฟล์ --memory-swapCompose ด้วย memswap_limitเพราะ Docker จะนับรวม RAM และ Swap ในการตั้งค่านั้น การตั้งค่า RAM และ Swap ให้เท่ากันจะทำให้ Swap ถูกปิดใช้งานสำหรับคอนเทนเนอร์อย่างมีประสิทธิภาพ หากคุณจัดการ ONLYOFFICE ด้วย Compose ให้ทำการเปลี่ยนแปลงในไฟล์ Compose ของ ONLYOFFICE เพื่อให้การตั้งค่าคงอยู่แม้หลังจากสร้างคอนเทนเนอร์ใหม่แล้ว
3. หาก VPS ไม่มี ให้เพิ่ม swap buffer เข้าไป
ไฟล์สวอปสามารถรองรับการใช้งานหน่วยความจำที่เพิ่มขึ้นชั่วคราวได้ แต่จะถูกจัดเก็บไว้ในดิสก์และช้ากว่า RAM มาก ตรวจสอบให้swapon --showแน่ใจdf -h /ก่อน ตัวอย่างต่อไปนี้จะเพิ่มไฟล์สวอปขนาด 2 GiB ลงใน VPS ที่ใช้ระบบไฟล์ภายในเครื่องที่เข้ากันได้ เช่น ext4 เมื่อไฟล์สวอป/swapfileยังไม่มีอยู่และผู้ให้บริการอนุญาตให้ใช้สวอป:
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show
free -h
ทำการสร้างไฟล์สวอปใหม่แบบถาวรหลังจากswaponสำเร็จเท่านั้น ตรวจสอบว่ามีรายการอยู่แล้วgrep -F '/swapfile' /etc/fstabหรือไม่โดยใช้คำสั่ง `swap file` หากไม่มี ให้เพิ่มเข้าไปหนึ่งครั้ง:
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
การสร้างไฟล์สวอปบน Btrfs, ระบบไฟล์เครือข่าย และการกำหนดค่าอื่นๆ บางอย่าง ต้องใช้การจัดการที่แตกต่างกัน อย่าใช้คำสั่งเหล่านี้กับไฟล์สวอปที่มีอยู่แล้ว หรือคิดว่าfallocateมันจะใช้ได้ทุกที่คู่มือคำสั่ง swapon ของ Linuxอธิบายข้อจำกัดของระบบไฟล์ หาก VPS ใช้สวอปเป็นประจำภายใต้ภาระงานแก้ไขปกติ ควรให้ความสำคัญกับการเพิ่ม RAM มากกว่าการสร้างไฟล์สวอปขนาดใหญ่ขึ้น
ตัวอย่างการตรวจสอบพื้นที่สวอป: สามารถมองเห็นอุปกรณ์สวอปและพื้นที่สวอปทั้งหมดได้ แต่การมีพื้นที่สวอปเพียงอย่างเดียวไม่ได้พิสูจน์ว่าความจุ RAM เพียงพอ
4. ตรวจสอบเซิร์ฟเวอร์อีกครั้งภายใต้ภาระงานตัดต่อที่สมจริง
การเปลี่ยนแผน VPS หรือการเปิดใช้งานสวอปมักไม่จำเป็นต้องแก้ไขการตั้งค่า ONLYOFFICE หากคุณเปลี่ยนแปลงการตั้งค่าการปรับใช้ Docker ให้กำหนดเวลาการบำรุงรักษาและรักษาการเชื่อมต่อ ข้อมูลลับ เส้นทางใบรับรอง และการตั้งค่าการรวมระบบที่มีอยู่เมื่อทำการเปลี่ยนแปลง เอกสาร README ของ ONLYOFFICE Docker อธิบายdocumentserver-prepare4shutdown.shถึงการปิดระบบตามแผนและเตือนว่าการตัดการเชื่อมต่อผู้แก้ไขอาจใช้เวลาหลายนาที อย่าสร้างใหม่หรือรีสตาร์ทเซิร์ฟเวอร์เอกสารที่ใช้งานอยู่โดยพลการ เนื่องจากอาจส่งผลกระทบต่อการเปลี่ยนแปลงที่ยังไม่ได้บันทึก
เมื่อบริการพร้อมแล้ว ให้ตรวจสอบว่าคอนเทนเนอร์ทำงานอยู่หรือไม่ และตรวจสอบหน่วยความจำอีกครั้ง:
docker ps --filter name=onlyoffice-document-server
docker stats --no-stream onlyoffice-document-server
docker inspect --format '{{.State.OOMKilled}}' onlyoffice-document-server
docker exec onlyoffice-document-server curl -fsS http://localhost:8000/info/info.json
การตรวจสอบครั้งสุดท้ายใช้เอนด์พอยต์ข้อมูลภายในที่แสดงในรายงานการตรวจสอบสถานะ Docker Compose อย่างเป็นทางการของ ONLYOFFICEโปรดเรียกใช้ภายในคอนเทนเนอร์เนื่องจากพอร์ต 8000 อาจไม่ได้เผยแพร่บน VPS เอนด์พอยต์ที่ตอบสนองแสดงถึงความพร้อมใช้งานของบริการ ไม่ได้หมายความว่าการผสานรวมพื้นที่จัดเก็บข้อมูลหรือการเรียกกลับการบันทึกทุกอย่างจะทำงานได้เสมอไป
ภาพแสดงตัวอย่างการตรวจสอบ: ตรวจสอบว่าคอนเทนเนอร์ยังคงทำงานอยู่ การใช้งานหน่วยความจำต่ำกว่าขีดจำกัด และเอนด์พอยต์ข้อมูลภายในตอบสนอง
ตรวจสอบว่าปัญหาเกี่ยวกับหน่วยความจำได้รับการแก้ไขแล้ว
ลองเปิดเอกสารขนาดเล็กก่อน แล้วค่อยเปิดเอกสารขนาดใหญ่ที่เป็นตัวแทนผ่าน Nextcloud, ownCloud หรือระบบเชื่อมต่ออื่นๆ ของคุณ บันทึกการแก้ไขที่ไม่เป็นอันตราย และตรวจสอบว่าการแก้ไขนั้นปรากฏขึ้นหลังจากเปิดไฟล์อีกครั้ง คอยสังเกตบันทึกfree -h, docker stats, และ kernel OOM ในช่วงเวลาการใช้งานที่เคยทำให้เกิดความล้มเหลวก่อนหน้านี้
การแก้ไขที่สำเร็จหมายความว่าเอกสารยังคงเปิดและบันทึกได้ตามปกติ การใช้งานหน่วยความจำยังคงอยู่ในขีดจำกัดของ VPS และคอนเทนเนอร์ และไม่มีข้อความ OOM kill ใหม่ปรากฏขึ้น หากการขัดข้องหยุดลงเฉพาะเมื่อมีการใช้งานน้อย แสดงว่า VPS ยังมีพื้นที่ไม่เพียงพอสำหรับการใช้งานสูงสุด ควรเพิ่มขนาด RAM ให้เพียงพอสำหรับการใช้งานสูงสุดแทนที่จะพึ่งพาการสลับหน่วยความจำอย่างต่อเนื่อง หากยังมี RAM เหลืออยู่และไม่มีข้อความ OOM ใหม่เกิดขึ้น แต่เอกสารยังคงใช้งานไม่ได้ ให้เปลี่ยนการตรวจสอบไปที่บันทึก ONLYOFFICE, รีเวิร์สพร็อกซี หรือตัวเชื่อมต่อพื้นที่จัดเก็บข้อมูลของคุณแทนที่จะทำการเปลี่ยนแปลงหน่วยความจำเพิ่มเติม