Debian 12 บน VPS ที่มี RAM ต่ำ: วิธีลดปัญหา MySQL OOM Crashes

คุณสามารถลดความเสี่ยงที่ OOM killer จะหยุดการทำงานของ MySQL บน VPS Debian 12 ที่มี RAM ต่ำได้โดยการตรวจสอบสาเหตุ จัดสรรหน่วยความจำให้กับทุกบริการ จำกัดการทำงานพร้อมกันของฐานข้อมูล และจัดสรรพื้นที่สวอปในกรณีที่ VPS อนุญาต การลดขนาดบัฟเฟอร์พูลของ InnoDB เพียงอย่างเดียวไม่ใช่วิธีแก้ปัญหาที่สมบูรณ์ ทั้งสวอปและการตั้งค่าป้องกัน OOM ก็ไม่รับประกันว่าภาระงานขนาดใหญ่จะยังคงทำงานต่อไปได้

คู่มือนี้จัดทำขึ้นเมื่อวันที่ 9 ตุลาคม 2569 โดยใช้ Debian 12 “bookworm”, Linux 6.1 และเอกสารประกอบของ Oracle MySQL 8.0/8.4 การตั้งค่าด้านล่างเป็นเพียงจุดเริ่มต้นที่เป็นตัวอย่าง ไม่ใช่ผลการทดสอบประสิทธิภาพหรือการกำหนดค่าสากล โปรดสำรองข้อมูลฐานข้อมูลและการกำหนดค่าก่อนทำการเปลี่ยนแปลง และกำหนดเวลาการรีสตาร์ทฐานข้อมูลเมื่อเวลาหยุดทำงานเป็นที่ยอมรับได้

1. ระบุเซิร์ฟเวอร์ก่อนคัดลอกการตั้งค่า MySQL

ตรวจสอบแล้ว: แพ็คเกจ default-mysql-serverของ Debian 12 ขึ้นอยู่กับ MariaDB ดังนั้น VPS ที่ระบุว่าใช้งาน “MySQL” อาจใช้งาน MariaDB ในขณะที่อีกเครื่องอาจใช้ Oracle MySQL จากที่เก็บหรือคอนเทนเนอร์แยกต่างหาก

mysql --version
systemctl status mysql mariadb

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

SELECT VERSION(), @@version_comment;

ใช้การตรวจสอบสิทธิ์ที่มีอยู่ของคุณ การติดตั้ง MariaDB บน ​​Debian อาจอนุญาตให้มีการดูแลระบบภายในเครื่องด้วยsudo mysql. บันทึกเวอร์ชันของเซิร์ฟเวอร์และชื่อบริการจริง คำสั่งบริการในภายหลังจะใช้mysql.service; แทนที่mariadb.serviceเมื่อเหมาะสม อย่าเพิ่มตัวแปรเฉพาะของ Oracle ลงในการกำหนดค่า MariaDB

2. ยืนยันว่าการปิดระบบเกิดจากเหตุการณ์ OOM (Out of Memory)

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

sudo journalctl -k -b
sudo journalctl -u mysql.service --since today
sudo journalctl -u systemd-oomd --since today

ตรวจสอบข้อความจากเคอร์เนลในช่วงเวลาที่เกิดเหตุ เพื่อหาข้อความที่ระบุถึงสภาวะหน่วยความจำไม่เพียงพอและกระบวนการที่ถูกยุติ จากนั้นเปรียบเทียบข้อความเหล่านั้นกับบันทึกการบริการ นอกจากนี้ ให้ตรวจสอบบันทึกข้อผิดพลาดของฐานข้อมูล หากแพ็กเกจของคุณเขียนบันทึกนั้นลงในไฟล์แทนที่จะเป็นบันทึกเหตุการณ์ หากเหตุการณ์เกิดขึ้นก่อนการรีบูต ให้ตรวจสอบการบูตครั้งก่อนหน้าjournalctl -k -b -1เมื่อมีบันทึกที่เก็บรักษาไว้ การขาดบันทึกประวัติจะทำให้ไม่สามารถยืนยันสาเหตุได้

ตัวจัดการพื้นที่ผู้ใช้สามารถยุติการทำงานของเวิร์กโหลดได้เช่นกันคู่มือ systemd-oomd ของ Debian อธิบายถึงการแทรกแซงโดยอิงจากแรงดันหน่วยความจำก่อนที่จะเกิดเหตุการณ์ OOM ในเคอร์เนล ตรวจสอบว่ามีการติดตั้งและใช้งานอยู่หรือไม่ แทนที่จะคิดว่า VPS Debian ทุกเครื่องใช้มัน

ตรวจสอบข้อจำกัดของ systemd ด้วยเช่นกัน:

systemctl show mysql.service \
  -p ControlGroup -p MemoryCurrent -p MemoryHigh \
  -p MemoryMax -p MemorySwapMax

ในระบบ cgroup v2 ให้ใช้พาธ ControlGroup ที่รายงานเพื่ออ่านmemory.events, memory.max, และmemory.swap.maxภายใต้/sys/fs/cgroupตรวจสอบ cgroup ระดับบนด้วยเอกสารประกอบ cgroup v2 ของ Linuxอธิบายตัวนับและข้อจำกัดเหล่านี้ cgroup อาจใช้หน่วยความจำหมดแม้ว่าโฮสต์จะมีพื้นที่เหลือเฟือ ตัวoom_killนับจะบันทึกการหยุดทำงาน แต่ต้องตีความร่วมกับข้อจำกัดและบันทึกเพื่อระบุสาเหตุ

3. วัดประสิทธิภาพของ VPS ทั้งหมด ไม่ใช่แค่บัฟเฟอร์พูล

free -h
ps -eo pid,comm,rss --sort=-rss
vmstat 1

รวบรวมข้อมูลจากการสังเกตการณ์ระหว่างการใช้งานปกติและงานที่เกี่ยวข้องกับความล้มเหลว ในส่วนของหน่วยfreeความจำที่ใช้งานได้ ให้เน้นที่หน่วยความจำที่ใช้งานได้จริง ไม่ใช่แค่คอลัมน์ "ว่าง" คู่มือหน่วยความจำว่าง ของ Debian อธิบายว่าหน่วยความจำที่ใช้งานได้จริงเป็นการประมาณค่าของสิ่งที่สามารถใช้งานได้โดยไม่ต้องใช้การสลับหน่วยความจำ ค่า RSS ในรายการกระบวนการมีหน่วยเป็น KiB การบวกค่าเหล่านี้อาจทำให้มีการนับหน่วยความจำที่ใช้ร่วมกันซ้ำสองครั้ง

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

การดำเนินการ:สำรองพื้นที่สำหรับเคอร์เนล, เว็บเวิร์กเกอร์, การตรวจสอบ, การสำรองข้อมูล และการทำงานของฐานข้อมูลชั่วคราว คำแนะนำทั่วไปที่ให้จัดสรร RAM ส่วนใหญ่ให้กับ InnoDB นั้นไม่เหมาะสมหากไม่มีการปรับแต่งบน VPS แบบแชร์ หากเวิร์กเกอร์ PHP หรืองานสร้างใช้พื้นที่ว่างเหลืออยู่ ให้ปรับแต่งหรือย้ายภาระงานนั้นแทนที่จะลดขนาด MySQL ซ้ำๆ

4. เพิ่มพื้นที่สวอปเพื่อใช้เป็นบัฟเฟอร์ ไม่ใช่ใช้แทนที่ RAM

ขึ้นอยู่กับบริบท:การสลับหน่วยความจำ (Swap) สามารถช่วยลดแรงกดดันจากหน่วยความจำที่ไม่ระบุชื่อชั่วคราวได้ แต่การสลับหน่วยความจำอย่างต่อเนื่องอาจทำให้การค้นหาข้อมูลช้าลงได้ VPS ที่ใช้คอนเทนเนอร์อาจจำกัดการใช้งาน Swap และข้อกำหนดของบริการบางอย่างMemorySwapMaxอาจป้องกันการใช้งาน Swap แม้ว่าโฮสต์จะมี Swap ก็ตาม

swapon --show
free -h
df -h /
findmnt -no FSTYPE /

หากไม่มีการตั้งค่า swap ไว้ ผู้ให้บริการอนุญาต และคุณมีพื้นที่ดิสก์เหลือเฟือ คำสั่งต่อไปนี้จะสร้างไฟล์ swap ขนาด 1 GiB บนระบบไฟล์ภายในเครื่องที่เหมาะสม เช่น ext4 อย่าเรียกใช้คำสั่งนี้หาก /swapfile มีอยู่แล้วตรวจสอบข้อกำหนดเฉพาะของระบบไฟล์ก่อน Btrfs ต้องการการตั้งค่าไฟล์ swap แบบ no-copy-on-write ที่เหมาะสม

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

หลังจากเปิดใช้งานสำเร็จแล้ว ให้เพิ่มรายการนี้เพียงครั้งเดียวลงใน/etc/fstab:

/swapfile none swap sw 0 0

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

อย่าคัดลอกการตั้งค่า “set swappiness to zero” มาใช้เป็นวิธีการป้องกัน OOM (Out of Memory) เอกสารประกอบของ Kernel VMระบุว่า swappiness เป็นค่ากำหนดต้นทุนการเรียกคืนหน่วยความจำ ไม่ได้สร้างหน่วยความจำใหม่หรือกำหนดขีดจำกัดหน่วยความจำของฐานข้อมูล ในตอนแรกให้ปล่อยค่านี้ไว้ตามเดิมแล้ววัดพฤติกรรม

5. กำหนดฐานข้อมูลพื้นฐานที่ไม่สูงเกินไป

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

[mysqld]
innodb_buffer_pool_size=128M
max_connections=20
tmp_table_size=16M
max_heap_table_size=16M

ใส่ตัวเลือกเซิร์ฟเวอร์ลงในไฟล์การกำหนดค่าที่มาพร้อมกับการติดตั้งของคุณ แพ็กเกจ Oracle MySQL อาจมีไฟล์ `<configuration_file>` /etc/mysql/mysql.conf.d/; Debian MariaDB มักใช้ ไฟล์ /etc/mysql/mariadb.conf.d/`<configuration_file>` ตรวจสอบคำสั่ง `<configuration_file>` ที่มีอยู่และสำรองข้อมูลไว้เอกสารเกี่ยวกับไฟล์ตัวเลือก ของ MySQL อธิบายกลุ่มตัวเลือกเซิร์ฟเวอร์และการจัดการไฟล์

บัฟเฟอร์พูลขนาด 128 MiB จำกัดแคช ไม่ใช่หน่วยความจำฐานข้อมูลทั้งหมด การจำกัดการเชื่อมต่อไว้ที่ 20 อาจเข้มงวดเกินไปหากมีอินสแตนซ์แอปพลิเคชันหลายตัวที่แต่ละตัวดูแลพูลของตนเอง ในทางกลับกัน การเรียกใช้คิวรีขนาดใหญ่พร้อมกัน 20 รายการอาจทำให้ VPS ทำงานหนักเกินไปได้ ควรจำกัดจำนวนรวมของพูลแอปพลิเคชันให้อยู่ต่ำกว่าขีดจำกัดของเซิร์ฟเวอร์ที่ต้องการ โดยเว้นพื้นที่ไว้สำหรับการเข้าถึงของผู้ดูแลระบบ และสังเกตการเชื่อมต่อที่ถูกปฏิเสธ

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

6. ควบคุมตารางชั่วคราวและการทำงานพร้อมกันไปพร้อมกัน

ความเข้าใจผิดที่พบบ่อย:การตั้งtmp_table_size=16Mค่าจำกัดหน่วยความจำสำหรับคำสั่งค้นหาทั้งหมดไว้ที่ 16 MiB นั้นไม่ถูกต้อง เซสชันหลายรายการ ตารางชั่วคราวหลายรายการ และการจัดสรรหน่วยความจำสำหรับการประมวลผลอื่นๆ สามารถทำงานพร้อมกันได้

สำหรับOracle MySQL 8.4จุดเริ่มต้นที่เป็นตัวอย่างเพิ่มเติมคือ:

temptable_max_ram=64M
temptable_max_mmap=0

เพิ่มสิ่งเหล่านี้เข้าไปใน[mysqld]กลุ่มที่มีอยู่แล้วหลังจากยืนยันการสนับสนุนผลิตภัณฑ์แล้วเท่านั้น สิ่งเหล่านี้ควบคุมขีดจำกัด RAM ที่ใช้ร่วมกันของเอนจิน TempTable และการใช้งานไฟล์ชั่วคราวที่แมปหน่วยความจำ สิ่งเหล่านี้ไม่ได้จำกัดกระบวนการ mysqld ทั้งหมดหรือการจัดสรรเฉพาะเธรดทั้งหมด ขีดจำกัดที่ต่ำกว่าอาจทำให้มีการทำงานบนดิสก์มากขึ้น

เอกสารเกี่ยวกับตารางชั่วคราวของ MySQL 8.4อธิบายถึงข้อจำกัดเหล่านั้น MySQL 8.0 มีพฤติกรรมที่ขึ้นอยู่กับเวอร์ชัน: temptable_max_mmapเริ่มใช้ในเวอร์ชัน 8.0.23 และtmp_table_sizeกลายเป็นข้อจำกัดของ TempTable แต่ละตัวในเวอร์ชัน 8.0.28 โปรดศึกษาเอกสารอ้างอิงของ MySQL 8.0ก่อนนำการตั้งค่าเดียวกันไปใช้ อย่าคัดลอกตัวเลือกเฉพาะของ Oracle เหล่านี้ไปยัง MariaDB

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

7. ตรวจสอบความถูกต้องของการเปลี่ยนแปลงและเริ่มต้นใหม่อย่างรอบคอบ

สำหรับ Oracle MySQL เวอร์ชันที่รองรับตัวเลือกนี้ โปรดตรวจสอบการตั้งค่าก่อนรีสตาร์ท:

sudo mysqld --validate-config

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

เริ่มการทำงานของบริการจริงอีกครั้งในช่วงเวลาที่กำหนด จากนั้นตรวจสอบการเริ่มต้นและสอบถามค่าที่มีผล:

sudo systemctl restart mysql.service
systemctl status mysql.service
sudo journalctl -u mysql.service --since today

SHOW GLOBAL VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','max_connections','tmp_table_size',
 'max_heap_table_size','temptable_max_ram','temptable_max_mmap');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Threads_connected','Threads_running','Max_used_connections');

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

8. กำหนดความสำเร็จภายใต้ภาระงานที่เป็นตัวแทน

free -h
vmstat 1
cat /proc/pressure/memory

เปรียบเทียบปริมาณการรับส่งข้อมูลและงานที่กำหนดไว้ก่อนและหลังการเปลี่ยนแปลง ติดตามเหตุการณ์ OOM ใหม่ การรีสตาร์ทฐานข้อมูล หน่วยความจำที่ใช้งานได้ การปฏิเสธการเชื่อมต่อ กิจกรรมสวอป และความหน่วงในการสืบค้น ในบางกรณีvmstatการสวอปอิน/สวอปเอาต์ที่เกิดขึ้นอย่างต่อเนื่องสมควรได้รับการตรวจสอบคู่มือ vmstat ของ Debianอธิบายว่ารายงานฉบับแรกแสดงค่าเฉลี่ยของกิจกรรมตั้งแต่เริ่มบูต ให้ใช้รายงานฉบับถัดไปเพื่อดูอัตราปัจจุบัน

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

ความเข้าใจผิดที่อาจทำให้ปัญหารุนแรงขึ้น

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

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