NỘI DUNG
OOM Killer là cơ chế của Linux tự động chọn và kill một tiến trình khi hệ thống cạn RAM. Nếu VPS của bạn xuất hiện log như kernel: Out of Memory: Kills process 30199 (mysql), điều đó có nghĩa là kernel đã kill MySQL để giải phóng bộ nhớ và tránh cho cả máy chủ bị treo hoàn toàn.
Trong bài này, tôi sẽ giải thích OOM Killer là gì, vì sao MySQL thường bị chọn, cách kiểm tra log OOM và hướng xử lý an toàn cho VPS chạy WordPress, MySQL/MariaDB, PHP-FPM hoặc các control panel như cPanel, DirectAdmin, CyberPanel.
OOM Killer là gì?
OOM là viết tắt của Out of Memory, nghĩa là hết bộ nhớ. Khi Linux không còn đủ RAM để cấp phát cho các tiến trình đang chạy, kernel phải đưa ra quyết định: hoặc để toàn bộ hệ thống đứng cứng, hoặc kill một tiến trình để giải phóng RAM. Cơ chế tự động chọn tiến trình để kill đó thường được gọi là OOM Killer.
Nói dễ hiểu, OOM Killer giống như người điều phối khẩn cấp. Khi VPS quá tải RAM, nó sẽ tìm tiến trình nào đang dùng nhiều bộ nhớ, ít quan trọng hơn so với tiến trình hệ thống, rồi kết thúc tiến trình đó để máy chủ còn khả năng sống tiếp.
OOM Killer không phải là lỗi riêng của MySQL. Nó là dấu hiệu cho thấy toàn hệ thống đã thiếu RAM tại thời điểm đó.
Log “Out of Memory: Kills process … (mysql)” nghĩa là gì?
Một dòng log thường gặp là:
kernel: Out of Memory: Kills process 30199 (mysql)Dòng này có thể hiểu như sau:
kernel: thông báo đến từ nhân Linux.Out of Memory: hệ thống bị hết RAM tại thời điểm đó.Kills process 30199: kernel đã kill tiến trình có PID 30199.(mysql): tiến trình bị kill là MySQL hoặc MariaDB.
Sau khi MySQL bị kill, website thường sẽ gặp lỗi kết nối database, ví dụ WordPress báo Error establishing a database connection. Nếu systemd có cấu hình tự restart, MySQL có thể tự chạy lại sau vài giây hoặc vài phút, nhưng trong khoảng thời gian đó website vẫn bị downtime.
OOM Killer chọn process nào để kill?
Linux không kill ngẫu nhiên. Kernel sẽ tính điểm cho các tiến trình, thường gọi là oom_score. Tiến trình nào có điểm cao hơn thì có khả năng bị kill cao hơn.
Các yếu tố thường làm một process dễ bị chọn hơn gồm:
- Đang dùng nhiều RAM.
- Có nhiều tiến trình con hoặc tạo tải lớn.
- Không phải tiến trình kernel hoặc tiến trình hệ thống cực kỳ quan trọng.
- Kill tiến trình đó có thể giải phóng đủ RAM để hệ thống tiếp tục hoạt động.
Vì vậy trên VPS chạy web, các ứng viên thường gặp là MySQL/MariaDB, PHP-FPM, Apache, Java, Redis, Elasticsearch, process backup, process quét mã độc hoặc một ứng dụng đang bị lỗi memory leak.
Vì sao MySQL thường bị OOM Killer kill?
MySQL/MariaDB thường bị kill không phải vì nó “có lỗi” ngay lập tức, mà vì nó là một trong các process dùng RAM lớn nhất trên VPS. Đặc biệt với VPS nhỏ 1GB, 2GB hoặc 4GB RAM, MySQL rất dễ trở thành mục tiêu khi hệ thống bị dồn tải.
Các nguyên nhân phổ biến gồm:
- Không có swap hoặc swap quá nhỏ.
- innodb_buffer_pool_size cấu hình quá lớn so với RAM thật.
- max_connections quá cao, nhiều connection đồng thời.
- PHP-FPM mở quá nhiều child process.
- Website WordPress bị bot/crawler quét mạnh.
- Plugin WordPress tạo query nặng hoặc không có index tốt.
- Backup, scan malware, cron, import/export dữ liệu chạy cùng lúc.
- Slow query làm nhiều connection treo lâu, RAM tăng dần.
Cách kiểm tra VPS có bị OOM Killer không
Đầu tiên, hãy kiểm tra log kernel. Trên Ubuntu/Debian/AlmaLinux/RockyLinux có systemd, bạn có thể dùng:
journalctl -k --since '24 hours ago' --no-pager | grep -iE 'out of memory|oom|killed process'Hoặc dùng dmesg:
dmesg -T | grep -iE "out of memory|oom|killed process"Nếu thấy dòng tương tự dưới đây, gần như chắc chắn VPS đã từng bị OOM:
kernel: Out of Memory: Kills process 30199 (mysql)Các lệnh kiểm tra nhanh sau khi MySQL bị kill
Khi phát hiện MySQL bị OOM Killer kill, đừng vội chỉ restart rồi bỏ qua. Hãy kiểm tra RAM, swap và process đang dùng bộ nhớ.
1. Kiểm tra RAM và swap
free -h
swapon --show2. Xem process đang ăn RAM nhiều nhất
ps aux --sort=-%mem | head -203. Kiểm tra trạng thái MySQL/MariaDB
systemctl status mysql --no-pager
# Hoặc nếu dùng MariaDB:
systemctl status mariadb --no-pager4. Xem cấu hình MySQL liên quan đến RAM
mysql -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size','sort_buffer_size','join_buffer_size','read_buffer_size','read_rnd_buffer_size');"
Hướng xử lý khi VPS bị OOM Killer kill MySQL
1. Thêm swap nếu VPS chưa có
Swap không thay thế được RAM thật, nhưng giúp giảm khả năng kernel kill process đột ngột khi RAM tăng vọt trong thời gian ngắn. Với VPS nhỏ, swap 1GB đến 2GB thường rất hữu ích.
Ví dụ tạo swap 2GB:
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
cp /etc/fstab /etc/fstab.bak-$(date +%F-%H%M%S)
echo "/swapfile none swap sw 0 0" >> /etc/fstab
sysctl vm.swappiness=10
echo "vm.swappiness=10" > /etc/sysctl.d/99-swappiness.confTrước khi chỉnh
/etc/fstab, luôn backup file. Cấu hình sai fstab có thể làm VPS lỗi khi reboot.
2. Giảm RAM MySQL cho phù hợp VPS
Nếu VPS chỉ có 2GB RAM nhưng MySQL đặt innodb_buffer_pool_size quá cao, PHP-FPM và hệ thống sẽ không còn đủ RAM. Với WordPress thông thường, có thể tham khảo mức sau:
- VPS 1GB RAM: buffer pool khoảng 256M – 384M.
- VPS 2GB RAM: khoảng 512M – 768M.
- VPS 4GB RAM: khoảng 1G – 2G tuỳ lượng web và PHP-FPM.
- VPS 8GB RAM trở lên: cần tính theo workload thực tế, không nên đoán mò.
Ví dụ cấu hình tham khảo cho VPS WordPress 2GB RAM:
[mysqld]
innodb_buffer_pool_size=512M
max_connections=80
tmp_table_size=64M
max_heap_table_size=64M
sort_buffer_size=2M
join_buffer_size=2M
read_buffer_size=1M
read_rnd_buffer_size=1MSau khi sửa cấu hình MySQL/MariaDB cần kiểm tra cú pháp và restart service. Việc restart có downtime ngắn, nên thực hiện vào thời điểm phù hợp.
3. Giảm số process PHP-FPM
Nhiều trường hợp MySQL bị kill vì PHP-FPM mở quá nhiều child process. Mỗi child có thể dùng vài chục MB đến vài trăm MB RAM tuỳ website/plugin. Nếu pm.max_children đặt quá cao, RAM có thể cạn rất nhanh khi traffic tăng.
Kiểm tra PHP-FPM process:
ps aux --sort=-%mem | grep -E 'php-fpm|php' | head -20Nếu thấy quá nhiều process PHP-FPM và RAM tăng cao, cần tính lại pm.max_children theo RAM thực tế còn lại sau khi trừ MySQL, web server, Redis và hệ thống.
4. Kiểm tra slow query và plugin WordPress
Nếu MySQL bị OOM lặp lại, cần kiểm tra query chậm. Một plugin tạo query nặng hoặc bảng thiếu index có thể làm MySQL giữ nhiều connection và tốn RAM.
mysql -e "SHOW FULL PROCESSLIST;"
mysql -e "SHOW VARIABLES LIKE 'slow_query_log%';"
mysql -e "SHOW VARIABLES LIKE 'long_query_time';"5. Kiểm tra cron, backup, scan malware và traffic bot
OOM thường xảy ra theo khung giờ. Nếu log OOM trùng với giờ backup, quét malware, import sản phẩm WooCommerce, crawl sitemap hoặc bot traffic tăng, hãy tách lịch cron ra hoặc giới hạn tài nguyên cho các tác vụ đó.
Có nên tắt OOM Killer không?
Không nên. OOM Killer là cơ chế bảo vệ cuối cùng của Linux. Nếu cố tắt hoặc né OOM Killer không đúng cách, hệ thống có thể treo toàn bộ, SSH không vào được, website chết lâu hơn và buộc phải hard reboot VPS.
Việc cần làm không phải là tắt OOM Killer, mà là xử lý nguyên nhân khiến VPS hết RAM: thêm swap, tối ưu MySQL/PHP-FPM, giảm bot traffic, sửa query chậm hoặc nâng RAM nếu tài nguyên thật sự không đủ.
Checklist xử lý nhanh
- Xác nhận OOM bằng
journalctl -khoặcdmesg. - Kiểm tra
free -hvàswapon --show. - Xem top process ăn RAM bằng
ps aux --sort=-%mem. - Kiểm tra MySQL buffer pool, max_connections và các buffer per-connection.
- Kiểm tra PHP-FPM
pm.max_children. - Tìm slow query, cron nặng, backup/scan chạy trùng giờ.
- Thêm swap hoặc nâng RAM nếu VPS thường xuyên chạm ngưỡng.
FAQ về OOM Killer
OOM Killer có phải lỗi của MySQL không?
Không hẳn. MySQL bị kill vì tại thời điểm đó hệ thống hết RAM và MySQL là một process tiêu thụ RAM lớn. Cần kiểm tra toàn hệ thống, không chỉ riêng MySQL.
VPS có swap rồi có hết OOM không?
Swap giúp giảm nguy cơ OOM đột ngột, nhưng không giải quyết triệt để nếu workload vượt quá tài nguyên VPS. Nếu swap bị dùng nhiều liên tục, website sẽ chậm và vẫn cần tối ưu hoặc nâng RAM.
Nên restart MySQL ngay khi bị OOM không?
Nếu MySQL chưa tự chạy lại, có thể cần restart để khôi phục dịch vụ. Nhưng sau đó phải kiểm tra log, RAM, process và cấu hình để tránh bị lặp lại.
Tại sao website WordPress hay bị lỗi database sau OOM?
Vì database MySQL/MariaDB bị kernel kill. WordPress cần database để tải nội dung, user, options, plugin settings; khi database chết, WordPress sẽ báo lỗi kết nối database.
Kết luận
OOM Killer là cơ chế bảo vệ của Linux khi VPS hết RAM. Nếu bạn thấy log Out of Memory: Kills process ... (mysql), hãy hiểu rằng MySQL là nạn nhân được kernel chọn để giải phóng bộ nhớ, còn nguyên nhân thật nằm ở việc VPS bị thiếu RAM hoặc cấu hình dịch vụ chưa phù hợp.
Cách xử lý đúng là kiểm tra log, thêm swap nếu cần, tối ưu MySQL/PHP-FPM, rà soát slow query và cron nặng. Nếu hệ thống vẫn thường xuyên chạm ngưỡng RAM sau khi tối ưu, nâng cấp RAM VPS là lựa chọn an toàn hơn so với để OOM Killer lặp lại.
Bài viết có tham khảo khái niệm OOM Killer từ cộng đồng VPS căn bản và được biên soạn lại theo hướng thực hành quản trị VPS/Linux.
Với kinh nghiệm thực chiến từ việc tiếp xúc hàng ngày với vô vàn vấn đề về Website, Hosting, VPS, Server tại Phòng Kỹ thuật AZDIGI, mình luôn ấp ủ niềm đam mê chia sẻ kiến thức.
Mình xây dựng các blog không chỉ để tự trau dồi kỹ năng mà còn để cung cấp những tài liệu, hướng dẫn hữu ích nhất đến cộng đồng. Rất mong nhận được sự quan tâm của các bạn!
Để lại thông tin, mình sẽ phản hồi ngay.
