ใช้งาน Debian 12 บน VPS ที่มี RAM น้อย โดยไม่เกิดปัญหา OOM (Out of Memory) และทำให้ MySQL ล่ม

VPS ที่มีหน่วยความจำต่ำสามารถใช้งาน Debian 12 และฐานข้อมูลได้ แต่ความเสถียรขึ้นอยู่กับปริมาณงานทั้งหมด ไม่ใช่แค่แคชที่กำหนดค่าไว้ของ MySQL เท่านั้น เมื่อหน่วยความจำที่มีอยู่หมดลง Linux อาจเรียกใช้ตัวจัดการหน่วยความจำไม่เพียงพอ (OOM killer) ซึ่งจะยุติกระบวนการเพื่อป้องกันส่วนที่เหลือของระบบ หากกระบวนการนั้นคือฐานข้อมูล อาการที่เกิดขึ้นอาจดูเหมือนการหยุดทำงานแบบสุ่ม เป้าหมายในทางปฏิบัติคือการป้องกันแรงดันหน่วยความจำที่เกิดขึ้นอย่างต่อเนื่องและตรวจสอบว่าเคอร์เนลได้ยุติกระบวนการใดไปบ้าง การตั้งค่าใดๆ ก็ไม่สามารถรับประกันได้ว่าเหตุการณ์ OOM จะไม่เกิดขึ้นเลย

Debian 12 ใช้ MySQL หรือ MariaDB ครับ/คะ?

ตรวจสอบเซิร์ฟเวอร์ก่อนทำการเปลี่ยนแปลงการตั้งค่า Debian 12 (Bookworm) ใช้ MariaDB เป็นdefault-mysql-serverแพ็กเกจเริ่มต้น ในขณะที่ Oracle MySQL ต้องติดตั้งแยกต่างหาก ข้อมูลแพ็กเกจของ Debian ระบุว่า MariaDB เป็นส่วนประกอบที่จำเป็นของเมตาแพ็กเกจนั้น รันคำสั่ง:

mariadb --version
mysql --version
dpkg-query -W -f='${Package} ${Version}\n' mariadb-server mysql-community-server 2>/dev/null

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

เอกสารอ้างอิงหลัก: แพ็กเกจ default-mysql-server ของ Debian Bookwormและคู่มือการใช้หน่วยความจำของ MySQL 8.0

จะทราบได้อย่างไรว่า OOM (Out of Your Database) ทำให้ฐานข้อมูลเสียหาย?

ขั้นแรก ให้แยกแยะความผิดพลาด OOM kill ของเคอร์เนลออกจากข้อผิดพลาดของฐานข้อมูล การรีสตาร์ทบริการ การรีบูต หรือปัญหาเกี่ยวกับดิสก์ บน Debian journalctlให้ตรวจสอบ journal ของ systemd ค้นหาการบูตปัจจุบันและตรวจสอบบันทึกบริการของ MariaDB:

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process'
sudo journalctl -u mariadb -b --no-pager -n 100
sudo systemctl status mariadb --no-pager

หากพบชื่อเคอร์เนลในบันทึกmariadbdหรือmysqldข้อความ OOM แสดงว่ามีการปิดหน่วยความจำเกิดขึ้น หากไม่มีรายการที่ตรงกัน ให้ตรวจสอบบันทึกข้อผิดพลาดของบริการเอง และประวัติการรีบูตหรือการตรวจสอบของผู้ให้บริการ บันทึกอาจไม่สามารถใช้งานได้หลังจากการรีบูตหากการบันทึกไม่คงอยู่ และผู้ให้บริการ VPS แบบจัดการอาจเปิดเผยข้อมูลการวินิจฉัยของโฮสต์เพียงบางส่วนเท่านั้น

บันทึกค่าพื้นฐานขณะที่เซิร์ฟเวอร์มีการใช้งานในระดับที่เหมาะสม ไม่ใช่เฉพาะขณะที่ไม่ได้ใช้งาน:

free -h
swapon --show
vmstat 1
ps -eo pid,comm,rss,%mem --sort=-rss | head

ใน ไฟล์ ให้ vmstatสังเกต คอลัมน์ siและsoเพื่อดูการทำงานของการสลับหน่วยความจำเข้าและออกอย่างต่อเนื่อง การจัดสรรหน่วยความจำสลับที่ไม่เป็นศูนย์เพียงอย่างเดียวไม่ได้บ่งชี้ถึงปัญหา แต่การสลับหน่วยความจำอย่างต่อเนื่องพร้อมกับเวลาตอบสนองที่ช้า แสดงให้เห็นถึงแรงดันหน่วยความจำ เอกสารของ Linux กล่าวถึงการจัดการหน่วยความจำไม่เพียงพอ (OOM) ว่าเป็นวิธีสุดท้ายเมื่อไม่สามารถเรียกคืนหน่วยความจำได้อย่างเพียงพอ โปรดดูแนวคิดการจัดการหน่วยความจำของเคอร์เนล Linuxและคู่มือ journalctlของ Debian

คุณควรวัดอะไรบ้างก่อนทำการปรับแต่ง?

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

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

sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size'); SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"

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

จะปรับขนาด MariaDB ให้เหมาะสมกับ VPS ขนาดเล็กได้อย่างไร?

ทำการเปลี่ยนแปลงทีละอย่าง เก็บสำเนาของการตั้งค่าเดิมไว้ และทดสอบในช่วงเวลาการบำรุงรักษาว่าการรีสตาร์ทจะส่งผลกระทบต่อผู้ใช้หรือไม่ การตั้งค่า MariaDB ที่มาพร้อมกับ Debian มักจะมีไฟล์อยู่ใน/etc/mysql/mariadb.conf.d/; ตรวจสอบไดเร็กทอรี include ที่ใช้งานอยู่บนการติดตั้งของคุณก่อนทำการแก้ไข ไฟล์ขนาดเล็กที่เพิ่มเข้ามานั้นลบได้ง่ายกว่าการแทนที่ไฟล์หลักของผู้จำหน่าย:

sudo cp -a /etc/mysql/mariadb.conf.d /root/mariadb.conf.d.backup
sudoedit /etc/mysql/mariadb.conf.d/90-low-memory.cnf

สำหรับ VPS แบบแชร์ที่มี RAM ประมาณ 1 GiB ตัวอย่างต่อไปนี้เป็นเพียงตัวอย่างเริ่มต้นอย่างระมัดระวังเท่านั้น ไม่ใช่โปรไฟล์ที่ปลอดภัยสำหรับทุกกรณี ควรปรับค่าลงหรือเพิ่มตามการวัดค่าหน่วยความจำสูงสุด ขนาดฐานข้อมูล ปริมาณงาน และ RAM ที่เหลือสำหรับระบบปฏิบัติการและแอปพลิเคชัน:

[mariadb]
innodb_buffer_pool_size = 192M
max_connections = 30
tmp_table_size = 16M
max_heap_table_size = 16M

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

sudo systemctl restart mariadb
sudo systemctl is-active mariadb
sudo journalctl -u mariadb -b --no-pager -n 80
sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections;"

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

การสลับฟังก์ชัน (swap) สามารถป้องกันการเกิดข้อผิดพลาด OOM (Out of Memory) ได้หรือไม่?

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

หากรองรับ คุณสามารถสร้างไฟล์สวอปขนาด 1 GiB ได้ดังนี้ ปรับขนาดตามคำแนะนำของผู้ให้บริการและพื้นที่ดิสก์ที่ใช้งานได้ และตรวจสอบผลลัพธ์ของแต่ละคำสั่ง:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

หากต้องการเปิดใช้งานหลังจากรีบูต ให้เพิ่มรายการนี้/etc/fstabหลังจากตรวจสอบแล้วว่าไม่มีรายการที่เทียบเท่ากันอยู่แล้ว:

/swapfile none swap sw 0 0

จากนั้นตรวจสอบความถูกต้องของไฟล์ด้วยคำสั่ง `wholelist` sudo findmnt --verify --verboseและยืนยันว่าไฟล์ปรากฏอยู่ใน `/etc/wholelist` swapon --showหากfallocateระบบไฟล์ไม่รองรับคำสั่ง `wholelist` หรือผู้ให้บริการบล็อกการใช้งาน swap ให้หยุดการทำงานและใช้ขั้นตอนที่ผู้ให้บริการรองรับ อย่าปิดใช้งาน OOM killer หรือกำหนดคะแนนการป้องกัน OOM ที่สูงมากให้กับ MySQL เพราะจะไม่สร้างหน่วยความจำเพิ่มและอาจทำให้ VPS ขนาดเล็กส่วนที่เหลือมีความเสี่ยงมากขึ้น

คุณรู้ได้อย่างไรว่าการเปลี่ยนแปลงได้ผล?

สังเกตการทำงานของ VPS อย่างน้อยในช่วงเวลาที่มีการใช้งานปกติหนึ่งช่วง ผลลัพธ์ที่ดีจะมีสัญญาณหลายอย่างดังนี้:

• ไม่มีรายการ OOM-kill ของเคอร์เนลใหม่เกิดขึ้นระหว่างการทำงานที่เคยทำให้เกิดเหตุการณ์ดังกล่าว
• MariaDB ยังคงทำงานอยู่ และจำนวนการรีสตาร์ทจะไม่เพิ่มขึ้นโดยไม่คาดคิด
• vmstat 1ไม่แสดงการสลับเข้าและสลับออกอย่างต่อเนื่องภายใต้การจราจรปกติ
• แอปพลิเคชันยังคงตอบสนองได้ดี และปริมาณการเชื่อมต่อฐานข้อมูลสูงสุดยังคงต่ำกว่าขีดจำกัดใหม่โดยไม่มีข้อผิดพลาดในการเชื่อมต่อ
• การสำรองข้อมูลเสร็จสมบูรณ์ และการสืบค้นฐานข้อมูลยังคงเป็นไปตามความหน่วงเวลาที่ยอมรับได้ของแอปพลิเคชัน

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

เมื่อไหร่การปรับจูนจึงจะไม่ใช่วิธีแก้ปัญหาที่ถูกต้องอีกต่อไป?

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

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

เอกสารอ้างอิงหลักเพิ่มเติม: คำแนะนำการแก้ไขปัญหาการเริ่มต้นใช้งานของ MariaDBซึ่งระบุว่าเซิร์ฟเวอร์ยังต้องการหน่วยความจำสำหรับเอ็นจิ้นอื่นๆ บัฟเฟอร์ต่อการเชื่อมต่อ และระบบปฏิบัติการ และคู่มืออ้างอิง MySQL 8.0