ป้องกันไม่ให้ ONLYOFFICE Document Server ใช้หน่วยความจำ VPS จนหมด

หาก 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

ตัวอย่างเทอร์มินัล Ubuntu ที่แสดงคำสั่ง free -h และ docker stats สำหรับคอนเทนเนอร์ ONLYOFFICE
ตัวอย่างการตรวจสอบหน่วยความจำ: เปรียบเทียบ 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 เพิ่ม

ตัวอย่างเทอร์มินัลที่แสดงแฟล็ก OOMKilled ของ Docker และข้อความหน่วยความจำไม่เพียงพอของเคอร์เนล Linux
ตัวอย่างการตรวจสอบ 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 มากกว่าการสร้างไฟล์สวอปขนาดใหญ่ขึ้น

ตัวอย่างการแสดงรายการไฟล์สวอปขนาด 2 กิกะไบต์ในเทอร์มินัล Ubuntu โดยใช้คำสั่ง swapon --show และ free -h
ตัวอย่างการตรวจสอบพื้นที่สวอป: สามารถมองเห็นอุปกรณ์สวอปและพื้นที่สวอปทั้งหมดได้ แต่การมีพื้นที่สวอปเพียงอย่างเดียวไม่ได้พิสูจน์ว่าความจุ 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 เอนด์พอยต์ที่ตอบสนองแสดงถึงความพร้อมใช้งานของบริการ ไม่ได้หมายความว่าการผสานรวมพื้นที่จัดเก็บข้อมูลหรือการเรียกกลับการบันทึกทุกอย่างจะทำงานได้เสมอไป

ตัวอย่างเทอร์มินัลที่แสดงคำสั่ง docker ps, docker stats และการตอบสนองจากเอนด์พอยต์ localhost ONLYOFFICE info
ภาพแสดงตัวอย่างการตรวจสอบ: ตรวจสอบว่าคอนเทนเนอร์ยังคงทำงานอยู่ การใช้งานหน่วยความจำต่ำกว่าขีดจำกัด และเอนด์พอยต์ข้อมูลภายในตอบสนอง

ตรวจสอบว่าปัญหาเกี่ยวกับหน่วยความจำได้รับการแก้ไขแล้ว

ลองเปิดเอกสารขนาดเล็กก่อน แล้วค่อยเปิดเอกสารขนาดใหญ่ที่เป็นตัวแทนผ่าน Nextcloud, ownCloud หรือระบบเชื่อมต่ออื่นๆ ของคุณ บันทึกการแก้ไขที่ไม่เป็นอันตราย และตรวจสอบว่าการแก้ไขนั้นปรากฏขึ้นหลังจากเปิดไฟล์อีกครั้ง คอยสังเกตบันทึกfree -h, docker stats, และ kernel OOM ในช่วงเวลาการใช้งานที่เคยทำให้เกิดความล้มเหลวก่อนหน้านี้

การแก้ไขที่สำเร็จหมายความว่าเอกสารยังคงเปิดและบันทึกได้ตามปกติ การใช้งานหน่วยความจำยังคงอยู่ในขีดจำกัดของ VPS และคอนเทนเนอร์ และไม่มีข้อความ OOM kill ใหม่ปรากฏขึ้น หากการขัดข้องหยุดลงเฉพาะเมื่อมีการใช้งานน้อย แสดงว่า VPS ยังมีพื้นที่ไม่เพียงพอสำหรับการใช้งานสูงสุด ควรเพิ่มขนาด RAM ให้เพียงพอสำหรับการใช้งานสูงสุดแทนที่จะพึ่งพาการสลับหน่วยความจำอย่างต่อเนื่อง หากยังมี RAM เหลืออยู่และไม่มีข้อความ OOM ใหม่เกิดขึ้น แต่เอกสารยังคงใช้งานไม่ได้ ให้เปลี่ยนการตรวจสอบไปที่บันทึก ONLYOFFICE, รีเวิร์สพร็อกซี หรือตัวเชื่อมต่อพื้นที่จัดเก็บข้อมูลของคุณแทนที่จะทำการเปลี่ยนแปลงหน่วยความจำเพิ่มเติม

ฝากความเห็น

ป้องกันไม่ให้ ONLYOFFICE Document Server ใช้หน่วยความจำ VPS จนหมด

ป้องกันไม่ให้ ONLYOFFICE Document Server ใช้หน่วยความจำ VPS จนหมด

ค้นหาสาเหตุของปัญหาหน่วยความจำไม่เพียงพอของ ONLYOFFICE ตรวจสอบข้อจำกัดของ Docker กำหนดขนาด RAM ของ VPS ให้ถูกต้อง เพิ่ม swap อย่างปลอดภัย และตรวจสอบว่าเอกสารเปิดและบันทึกได้

ตรวจสอบหาสาเหตุของการส่งออกไฟล์ PDF ที่ล้มเหลวของ ONLYOFFICE

ตรวจสอบหาสาเหตุของการส่งออกไฟล์ PDF ที่ล้มเหลวของ ONLYOFFICE

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

แก้ไขข้อผิดพลาด “โทเค็นไม่ถูกต้อง” ของ ONLYOFFICE ใน Nextcloud

แก้ไขข้อผิดพลาด “โทเค็นไม่ถูกต้อง” ของ ONLYOFFICE ใน Nextcloud

ตรงกับรหัสลับ JWT ที่ใช้โดย ONLYOFFICE Docs และ Nextcloud สามารถนำไปใช้ได้อย่างปลอดภัยสำหรับการติดตั้งบน Docker หรือ Linux และตรวจสอบการเชื่อมต่อโดยไม่ลดทอนความปลอดภัยในการยืนยันตัวตน

ติดตั้ง ONLYOFFICE Workspace Community บน Ubuntu 24.04

ติดตั้ง ONLYOFFICE Workspace Community บน Ubuntu 24.04

ติดตั้ง ONLYOFFICE Workspace Community บน Ubuntu 24.04 โดยใช้สคริปต์ Docker อย่างเป็นทางการ ตรวจสอบข้อกำหนดของเซิร์ฟเวอร์ ข้ามการติดตั้ง Mail หากไม่จำเป็น และตรวจสอบพอร์ทัลอย่างปลอดภัย

ตั้งค่ารหัสลับ JWT ของ ONLYOFFICE ระหว่างเซิร์ฟเวอร์และตัวเชื่อมต่อ

ตั้งค่ารหัสลับ JWT ของ ONLYOFFICE ระหว่างเซิร์ฟเวอร์และตัวเชื่อมต่อ

กำหนดค่ารหัสลับ JWT ที่ตรงกันสำหรับ ONLYOFFICE Docs และตัวเชื่อมต่อ โดยใช้ขั้นตอนที่ปลอดภัยสำหรับแพ็คเกจ Linux การใช้งาน Docker และการตรวจสอบยืนยัน

ตกแต่ง ONLYOFFICE Docs ด้วยโลโก้และสีธีมของคุณ

ตกแต่ง ONLYOFFICE Docs ด้วยโลโก้และสีธีมของคุณ

ใส่โลโก้บริษัทและสีอินเทอร์เฟซของคุณลงในโปรแกรมแก้ไขเอกสาร ONLYOFFICE Docs ที่ฝังอยู่ภายใน โดยใช้ไฟล์ธีมแบบกำหนดเองและการกำหนดค่าโปรแกรมแก้ไข ดูข้อจำกัดของรุ่นและการตรวจสอบการใช้งาน

รักษาการแก้ไขของผู้เขียนให้มองเห็นได้เมื่อส่งออกเป็นไฟล์ DOCX

รักษาการแก้ไขของผู้เขียนให้มองเห็นได้เมื่อส่งออกเป็นไฟล์ DOCX

ติดตามการแก้ไขใน Writer รักษาไฟล์ต้นฉบับ ODT ที่สามารถแก้ไขได้ และตรวจสอบไฟล์ DOCX ที่ส่งออกใน Word ก่อนที่จะแชร์

เปิดใช้งานโหมด FIPS บน SLES 15 และตรวจสอบสถานะการบูต

เปิดใช้งานโหมด FIPS บน SLES 15 และตรวจสอบสถานะการบูต

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

ตั้งค่าไดรฟ์ข้อมูลที่เข้ารหัส LUKS บน SLES

ตั้งค่าไดรฟ์ข้อมูลที่เข้ารหัส LUKS บน SLES

เปรียบเทียบ YaST และ cryptsetup สำหรับไดรฟ์ข้อมูล SLES ที่เข้ารหัสใหม่ เลือก LUKS1 หรือ LUKS2 และตรวจสอบพฤติกรรมการปลดล็อกและการเมานต์อย่างปลอดภัย

สร้างเซิร์ฟเวอร์อัปเดต SUSE ในเครื่องด้วย RMT บน SLES 15

สร้างเซิร์ฟเวอร์อัปเดต SUSE ในเครื่องด้วย RMT บน SLES 15

ตั้งค่า RMT บน SLES 15 จำลองที่เก็บข้อมูลที่ได้รับสิทธิ์ และตรวจสอบการลงทะเบียน HTTPS และการเข้าถึงแพ็กเกจจากไคลเอ็นต์ทดสอบ