วิธีเพิ่มขีดจำกัดหน่วยความจำสำหรับคอนเทนเนอร์ CODE ของ Collabora Online

หากคอนเทนเนอร์ Collabora Online Development Edition (CODE) ถูกปิดการทำงานเนื่องจากมีภาระงานมาก หรือทำงานใกล้ถึงขีดจำกัดหน่วยความจำของ Docker อย่างต่อเนื่อง วิธีแก้ไขที่ได้ผลโดยทั่วไปคือการเพิ่มขีดจำกัดหน่วยความจำของ Docker สำหรับคอนเทนเนอร์นั้น ไม่ใช่การเปลี่ยนการตั้งค่าภายใน Collabora เอง Docker กำหนดขีดจำกัดหน่วยความจำในระดับรันไทม์ของคอนเทนเนอร์ และ Collabora ทำงานอยู่ภายในขอบเขตนั้น

คู่มือนี้ใช้ตัวอย่างสมมติอย่างชัดเจนตลอดทั้งเล่ม: ลองนึกภาพทีมเล็กๆ ทีมหนึ่งกำลังใช้งานคอนเทนเนอร์ชื่อหนึ่งcodeบนโฮสต์ Docker บนระบบ Linux คอนเทนเนอร์นี้มีข้อจำกัดด้านหน่วยความจำสูงสุด 2 GiB และในช่วงเวลาที่มีการแก้ไขงานอย่างหนัก หน่วยความจำจะใกล้ถึงขีดจำกัดนั้น ทีมจึงตัดสินใจทดสอบขีดจำกัดที่ 4 GiB โดยยังคงเหลือ RAM เพียงพอสำหรับระบบปฏิบัติการและบริการอื่นๆ ตัวเลขและค่าการใช้งานในตัวอย่างนี้เป็นเพียงตัวอย่าง ไม่ใช่ผลการวัดจากการใช้งานจริง

ณ เดือนตุลาคม 2569 คำสั่งด้านล่างนี้สอดคล้องกับเอกสาร Docker ฉบับปัจจุบัน เอกสาร Docker ของ Collabora เองระบุว่าอิมเมจ CODE เป็นตัวเลือก Collabora Online ที่ใช้งานผ่าน Docker โดย Docker เป็นส่วนประกอบที่บังคับใช้ข้อจำกัดด้านทรัพยากรของคอนเทนเนอร์ โปรดดูเอกสาร Docker อย่างเป็นทางการของ Collabora Online CODEและเอกสารข้อจำกัดด้านทรัพยากร ของ Docker เมื่อปรับขั้นตอนให้เข้ากับสภาพแวดล้อมของคุณ

การเพิ่มขีดจำกัดหน่วยความจำจะเปลี่ยนแปลงอะไรบ้าง

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

เอกสารของ Docker --memory(หรือ-m) ระบุขีดจำกัดหน่วยความจำสูงสุดของคอนเทนเนอร์ นอกจากนี้ Docker ยังมี--memory-swapซึ่งควบคุมปริมาณ RAM และ swap ที่รวมกันเมื่อมีการตั้งค่าขีดจำกัดหน่วยความจำ swap สามารถช่วยเผื่อไว้ได้ แต่การใช้ swap บ่อยครั้งจะส่งผลเสียต่อประสิทธิภาพ สำหรับบริการตัดต่อเอกสาร ควรหลีกเลี่ยงการใช้ swap แทนหน่วยความจำทางกายภาพที่เพียงพอ

ขั้นตอนที่ 1: ยืนยันว่าปัญหาที่แท้จริงคือปัญหาที่เกิดจากหน่วยความจำไม่เพียงพอ

เริ่มต้นด้วยการระบุคอนเทนเนอร์ CODE ที่กำลังทำงานอยู่ และสังเกตการใช้งานทรัพยากรในปัจจุบัน:

docker ps
docker stats code

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

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

ขั้นตอนที่ 2: อ่านค่าขีดจำกัดหน่วยความจำที่ตั้งค่าไว้ของ Docker

ตรวจสอบค่าหน่วยความจำที่กำหนดค่าไว้ของคอนเทนเนอร์โดยตรง:

docker inspect code --format '{{.HostConfig.Memory}}'

Docker รายงานค่านี้เป็นไบต์ ตัวอย่างเช่น2147483648ไบต์เท่ากับ 2 กิกะไบต์ คุณสามารถแปลงค่าด้วยตนเองหรือใช้การคำนวณทางคณิตศาสตร์ในเชลล์ได้:

echo $((2147483648 / 1024 / 1024 / 1024))

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

ขั้นตอนที่ 3: เพิ่มขีดจำกัดให้กับคอนเทนเนอร์ Linux ที่มีอยู่แล้ว

Docker รองรับการเปลี่ยนขีดจำกัดหน่วยความจำของคอนเทนเนอร์ที่มีอยู่แล้วด้วยคำdocker updateสั่ง `docker alternate` ตัวอย่างเช่น การเปลี่ยนจาก 2 GiB เป็น 4 GiB:

docker update --memory 4g --memory-swap 4g code

การตั้งค่า--memory-swapให้มีค่าเท่ากับค่าที่กำหนดไว้--memoryจะป้องกันไม่ให้คอนเทนเนอร์นั้นใช้พื้นที่สวอปตามกฎการใช้หน่วยความจำสวอปที่ระบุไว้ในเอกสารของ Docker หากนโยบายการใช้งานของคุณอนุญาตให้ใช้สวอป ให้เลือกค่าที่เหมาะสมด้วยตนเอง แทนที่จะคัดลอกตัวอย่างนี้ ตัวอย่างเช่น--memory-swapค่าที่มากขึ้นจะอนุญาตให้ใช้สวอปเกินขีดจำกัดของ RAM ในขณะที่ค่า-1ที่ต่ำกว่าจะอนุญาตให้ใช้สวอปได้ไม่จำกัด ขึ้นอยู่กับพื้นที่สวอปที่มีให้ใช้งานในโฮสต์

เอกสารเกี่ยวกับการอัปเดตคอนเทนเนอร์ Docker ในปัจจุบันระบุว่ามี--memory, --memory-reservation, และ--memory-swapเป็นการตั้งค่าที่สามารถอัปเดตได้ Docker ยังระบุด้วยว่าdocker updateไม่รองรับสำหรับคอนเทนเนอร์ Windows การใช้งาน CODE โดยทั่วไปจะใช้คอนเทนเนอร์ Linux แต่ความแตกต่างนี้มีความสำคัญหากคุณกำลังปรับใช้คำสั่งในที่อื่น

หลังจากอัปเดตแล้ว โปรดตรวจสอบทั้งการตั้งค่าและสถานะการทำงาน:

docker inspect code --format '{{.HostConfig.Memory}}'
docker stats code

อย่าตีความว่าเปอร์เซ็นต์ที่ลดลงหลังจากการเปลี่ยนแปลงเป็นหลักฐานว่าบริการนั้นต้องการ RAM น้อยลง เปอร์เซ็นต์ลดลงเนื่องจากตัวหารมีขนาดใหญ่ขึ้น สิ่งที่สำคัญคือคอนเทนเนอร์ยังคงเสถียรภายใต้ภาระงานที่เคยทำให้เกิดปัญหาเรื่องหน่วยความจำไม่เพียงพอมาก่อนหรือไม่

ขั้นตอนที่ 4: ยืนยันการเปลี่ยนแปลงใน Docker Compose

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

สำหรับ Docker Compose รุ่นใหม่ คุณสมบัติ service-level mem_limitจะกำหนดปริมาณหน่วยความจำที่คอนเทนเนอร์สามารถจัดสรรได้:

services:
  collabora:
    image: collabora/code
    container_name: code
    restart: unless-stopped
    mem_limit: 4g
    ports:
      - "9980:9980"

เอกสารอ้างอิงบริการ Compose ของ Docker ระบุถึงสถานะ mem_limitซึ่งmem_limitใช้กำหนดขีดจำกัดหน่วยความจำสำหรับคอนเทนเนอร์บริการ Compose ยังรองรับการจำกัดทรัพยากรภายใต้ รูปแบบอื่นด้วย deploy.resources.limits.memoryหากคุณใช้ทั้งสองรูปแบบ Docker ระบุว่าค่าหน่วยความจำต้องสอดคล้องกัน

ใช้การตั้งค่า:

docker compose up -d

จากนั้นตรวจสอบบริการที่สร้างขึ้นใหม่หรือเริ่มต้นใหม่:

docker inspect code --format '{{.HostConfig.Memory}}'
docker stats code

ควรจัดสรรหน่วยความจำเท่าไหร่ดี?

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

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

กระบวนการกำหนดขนาดที่ใช้งานได้จริง

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

แล้วเรื่องการจองและการสลับหน่วยความจำล่ะ?

Docker แยกความแตกต่างระหว่างขีดจำกัดหน่วยความจำแบบตายตัว (hard memory limit) กับการสำรองหน่วยความจำแบบยืดหยุ่น (soft memory reservation) การสำรองหน่วยความจำสามารถส่งผลต่อพฤติกรรมเมื่อโฮสต์เกิดการแย่งชิงทรัพยากร ในขณะที่ขีดจำกัดแบบตายตัวยังคงเป็นขีดจำกัดสูงสุดอย่างแท้จริง สำหรับการตั้งค่า CODE บนโฮสต์เดียวหลายๆ ครั้ง การเริ่มต้นด้วยขีดจำกัดแบบตายตัวที่ชัดเจนจะเข้าใจได้ง่ายกว่า ควรเพิ่มการสำรองหน่วยความจำก็ต่อเมื่อคุณมีนโยบายการแบ่งปันทรัพยากรระดับโฮสต์ที่ชัดเจนแล้วเท่านั้น

การใช้งาน Swap นั้นต้องระมัดระวังเป็นพิเศษ เอกสารของ Docker อธิบายว่าค่า ` --memory-swapswap` หมายถึงหน่วยความจำทั้งหมดรวมกับ Swap เมื่อตั้งค่าเป็นค่าบวก หาก ` swap` เป็น `true` --memory=4gและ--memory-swap=6g`true` คอนเทนเนอร์สามารถใช้ RAM ได้สูงสุด 4 GiB และ Swap เพิ่มเติมได้สูงสุด 2 GiB ซึ่งอาจช่วยป้องกันความล้มเหลวอย่างกะทันหันในบางสถานการณ์ แต่การใช้งาน Swap อย่างต่อเนื่องอาจทำให้การแก้ไขแบบโต้ตอบช้าลง การตรวจสอบค่า Swap แทนที่จะคาดเดาว่าจะมี Swap มากขึ้นนั้นปลอดภัยกว่าเสมอ

วิธีสังเกตว่าการเปลี่ยนแปลงนั้นได้ผลหรือไม่

ความสำเร็จไม่ได้เป็นเพียงแค่การมองเห็น4 GiBเท่านั้นdocker statsสัญญาณที่มีความหมายนั้นต้องมาจากการลงมือปฏิบัติ:

• ค่าขีดจำกัดที่ตั้งค่าไว้ตรงกับdocker inspectค่าที่ตั้งใจไว้
• ตู้คอนเทนเนอร์ยังคงอยู่ต่ำกว่าเพดานใหม่ระหว่างการทำงานที่เคยก่อให้เกิดปัญหามาก่อนหน้านี้
• การรีสตาร์ทที่ไม่คาดคิดหรือความล้มเหลวที่เกี่ยวข้องกับหน่วยความจำไม่เพียงพอจะไม่เกิดขึ้นอีกภายใต้เงื่อนไขที่เทียบเคียงได้
• โฮสต์ Docker ยังคงมีหน่วยความจำเหลือเฟือและไม่ได้เริ่มใช้หน่วยความจำเสมือน (swapping) อย่างหนัก
• การแก้ไขยังคงตอบสนองได้ดี ไม่ใช่แค่หลีกเลี่ยงการยุติการทำงานเท่านั้น

หากคอนเทนเนอร์ยังคงล้มเหลวต่ำกว่าขีดจำกัดใหม่ ให้เปลี่ยนแนวทาง ตรวจสอบdocker logs codeบันทึกเคอร์เนลของโฮสต์ ข้อผิดพลาดของรีเวิร์สพร็อกซี บันทึกของเซิร์ฟเวอร์การรวมระบบ และความอิ่มตัวของ CPU หรือ I/O ขีดจำกัดหน่วยความจำเป็นเพียงชั้นหนึ่งของการใช้งาน Collabora เท่านั้น

ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยง

• การเปลี่ยนแปลงเฉพาะคอนเทนเนอร์ที่กำลังทำงานอยู่ docker updateอาจช่วยแก้ปัญหาข้อจำกัดในทันทีได้ แต่บริการที่จัดการโดย Compose ก็ควรได้รับการอัปเดตในไฟล์ Compose ด้วยเช่นกัน
• การมอบหน่วยความจำทั้งหมดของโฮสต์ให้กับ CODE นั้นจำเป็นต่อการทำงานของโฮสต์และบริการข้างเคียง คอนเทนเนอร์ที่ไม่จำกัดอาจส่งผลให้เกิดความไม่เสถียรทั่วทั้งโฮสต์ได้
• สมมติว่าพื้นที่สวอปเป็นหน่วยความจำว่าง:สวอปทำงานช้ากว่า RAM และ Docker จะแจ้งเตือนอย่างชัดเจนถึงผลกระทบด้านประสิทธิภาพเมื่อแอปพลิเคชันใช้สวอปบ่อยครั้ง
• ความสับสนระหว่างหน่วยความจำของคอนเทนเนอร์กับหน่วยความจำของ PHP:ขีดจำกัดของคอนเทนเนอร์ Docker CODE นั้นแยกต่างหากจากการตั้งค่า PHP ที่แอปพลิเคชันต่างๆ เช่น Nextcloud ใช้
• ใช้ข้อมูล ณ ช่วงเวลาหนึ่งเป็นหลักฐาน:วัดผลในช่วงเวลาที่มีความต้องการเป็นตัวแทน และเปรียบเทียบพฤติกรรมก่อนและหลังการเปลี่ยนแปลง

สรุปแล้ว

ในการเพิ่มขีดจำกัดหน่วยความจำสำหรับคอนเทนเนอร์ Collabora Online CODE ก่อนอื่นให้ตรวจสอบว่าขีดจำกัดของ Docker ที่มีอยู่ถูกใช้งานจนเต็มแล้วหรือไม่ สำหรับคอนเทนเนอร์ Linux ที่มีอยู่docker update --memory ...คุณสามารถเปลี่ยนขีดจำกัดได้ในระหว่างการทำงาน สำหรับการใช้งานที่จัดการโดย Compose ให้บันทึกขีดจำกัดด้วยmem_limitการกำหนดค่าทรัพยากร Compose ที่สอดคล้องกัน จากนั้นสร้างหรืออัปเดตบริการใหม่และตรวจสอบผลลัพธ์

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