MySQL/MariaDB tuning my.cnf cho VPS nhỏ (1-2GB)

Vì sao cần tuning my.cnf ngay?

Mặc định, MySQL và MariaDB được thiết kế để tiêu thụ tài nguyên tối đa nhằm tăng tốc độ xử lý trên các máy chủ lớn. Khi bạn cài đặt nguyên bản cấu hình này lên một VPS chỉ có 1GB hoặc 2GB RAM, cơ sở dữ liệu sẽ nhanh chóng phình to và ăn hết bộ nhớ. Hậu quả là tiến trình bị hệ điều hành “giết chết” (OOM Killer) khiến website sập hoàn toàn.

Dưới đây là những lý do bạn cần bắt tay vào tối ưu file my.cnf ngay lập tức:

• 💥 Tránh lỗi Out of Memory (OOM): Ngăn chặn tình trạng database crash liên tục do cạn kiệt RAM vật lý.
• 🚀 Tăng tốc độ phản hồi: Tối ưu hóa bộ đệm giúp các truy vấn (query) được xử lý nhanh hơn từ bộ nhớ thay vì đọc từ ổ cứng.
• 📉 Giảm tải CPU và Disk I/O: Hạn chế việc hệ điều hành phải swap dữ liệu liên tục ra ổ cứng gây nghẽn cổ chai.
• 🛠️ Tối đa hóa tài nguyên: Tận dụng hiệu quả từng MB RAM ít ỏi của VPS nhỏ cho các tiến trình thực sự cần thiết.
• 💸 Tiết kiệm chi phí: Giúp hệ thống chạy ổn định trên gói VPS giá rẻ mà chưa cần phải vội vàng nâng cấp.

1. Xác định vị trí và cấu trúc file my.cnf

Tóm gọn: Tìm đúng file cấu hình trên Ubuntu 22.04/24.04 và luôn tạo bản sao lưu an toàn trước khi tiến hành chỉnh sửa.

Trên các phiên bản Ubuntu mới, cấu hình MySQL/MariaDB không nằm gọn trong một file duy nhất mà bị phân mảnh thành nhiều file include. File /etc/mysql/my.cnf gốc thường chỉ đóng vai trò gọi các file cấu hình con. Bạn cần xác định chính xác file chứa block [mysqld] để thực hiện tuning.

Tìm file cấu hình chính xác

Hãy chạy lệnh dưới đây để xem MySQL hoặc MariaDB đang ưu tiên đọc cấu hình từ những đường dẫn nào. Lệnh này sẽ liệt kê thứ tự nạp file cấu hình của hệ thống.

mysqld --help --verbose | grep -A 1 "Default options"

Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf

• --help --verbose: Yêu cầu MySQL daemon in ra toàn bộ thông số cấu hình mặc định đang được sử dụng.
• grep -A 1 "Default options": Lọc và chỉ hiển thị dòng chứa thứ tự đọc file cấu hình để bạn dễ dàng theo dõi.

Backup trước khi sửa

Luôn sao lưu file cấu hình trước khi đụng vào bất cứ thông số nào. Nếu bạn cấu hình sai cú pháp, MySQL sẽ từ chối khởi động và việc có file backup sẽ cứu sống bạn.

cp /etc/mysql/mariadb.conf.d/50-server.cnf /etc/mysql/mariadb.conf.d/50-server.cnf.bak

💡 Mẹo: Đối với MariaDB trên Ubuntu 22.04/24.04, file bạn cần sửa thường là /etc/mysql/mariadb.conf.d/50-server.cnf. Đối với MySQL gốc, file đó thường nằm ở /etc/mysql/mysql.conf.d/mysqld.cnf.

2. Tối ưu InnoDB Buffer Pool (Trái tim của MySQL)

Tóm gọn: Dành khoảng 30-40% tổng RAM của VPS cho innodb_buffer_pool_size để cache dữ liệu và index hiệu quả.

InnoDB hiện tại là storage engine mặc định và quan trọng nhất của MySQL. Bộ đệm của nó (Buffer Pool) quyết định phần lớn hiệu suất tổng thể của toàn bộ database. Trên VPS nhỏ, bạn không thể cấp 80% RAM cho InnoDB như trên server chuyên dụng vì hệ điều hành và Web Server (NGINX/Apache) cũng cần không gian để hoạt động.

Cấu hình innodb_buffer_pool_size

Mở file cấu hình bằng trình soạn thảo nano hoặc vim. Tìm đến block [mysqld] và thêm hoặc sửa thông số sau.

[mysqld]
innodb_buffer_pool_size = 256M

• [mysqld]: Đây là block cấu hình dành riêng cho tiến trình MySQL server daemon. Các thông số nằm ngoài block này sẽ không có tác dụng.
• innodb_buffer_pool_size: Kích thước vùng nhớ dùng để cache data và index. Với VPS 1GB, mức an toàn là 256M, còn với VPS 2GB, bạn có thể set 512M.

Cấu hình innodb_buffer_pool_instances

Việc chia nhỏ buffer pool thành nhiều instance giúp giảm tranh chấp (contention) khi có nhiều luồng truy cập đồng thời. Tuy nhiên, tính năng này chỉ thực sự phát huy tác dụng khi buffer pool của bạn lớn hơn 1GB.

[mysqld]
innodb_buffer_pool_instances = 1

• innodb_buffer_pool_instances = 1: Ép MySQL sử dụng một vùng nhớ duy nhất. Điều này giúp tiết kiệm overhead quản lý bộ nhớ trên các VPS cấu hình thấp.

⚠️ Cảnh báo: Tuyệt đối không thiết lập innodb_buffer_pool_size vượt quá 50% tổng RAM trên VPS 1-2GB đang chạy chung với Web Server. Nếu vi phạm, OOM Killer của Linux sẽ lập tức “bắn hạ” MySQL khi hệ thống có traffic đột biến.

3. Giới hạn Connection và Thread Cache

Tóm gọn: Cắt giảm số lượng kết nối tối đa để ngăn MySQL cấp phát quá nhiều RAM cho các connection rác không hoạt động.

Mỗi kết nối (connection) đến MySQL đều tự động tiêu tốn một lượng RAM nhất định cho các buffers riêng biệt. Mặc định thông số max_connections thường được đặt ở mức 151, một con số quá lớn và nguy hiểm cho VPS 1GB. Bạn bắt buộc phải bóp thông số này lại để bảo vệ bộ nhớ hệ thống.

Giảm max_connections

Hãy thêm hoặc chỉnh sửa các cấu hình dưới đây bên trong block [mysqld]. Việc này giới hạn rủi ro cạn kiệt RAM khi website bị tấn công hoặc có quá nhiều người truy cập cùng lúc.

[mysqld]
max_connections = 50
max_user_connections = 40

• max_connections = 50: Giới hạn tối đa 50 kết nối đồng thời vào database. Con số này là hoàn toàn đủ cho hầu hết các blog hoặc website doanh nghiệp nhỏ.
• max_user_connections = 40: Giới hạn số kết nối tối đa trên mỗi user database. Việc này chừa lại một vài kết nối dự phòng cho user root để bạn có thể login vào quản trị khi hệ thống quá tải.

Tối ưu thread_cache_size

Thread cache giúp MySQL tái sử dụng các luồng xử lý (threads) cũ thay vì phải tạo mới liên tục cho mỗi kết nối. Tối ưu thông số này giúp giảm tải CPU đáng kể trên các VPS có ít nhân xử lý.

[mysqld]
thread_cache_size = 16

• thread_cache_size = 16: Giữ lại tối đa 16 threads trong bộ nhớ cache để sẵn sàng phục vụ. Công thức tham khảo an toàn cho thông số này thường là max_connections / 3.

💡 Mẹo: Bạn có thể kiểm tra số lượng kết nối đang thực sự hoạt động bằng câu lệnh SQL: SHOW STATUS LIKE 'Threads_connected';. Nếu con số này thường xuyên chạm ngưỡng 50, bạn mới cần cân nhắc tối ưu lại code hoặc tăng nhẹ limit.

4. Tinh chỉnh các bộ đệm (Buffers) trên mỗi Connection

Tóm gọn: Cắt giảm các buffer cấp phát trên mỗi kết nối và tắt hoàn toàn Performance Schema để thu hồi hàng trăm MB RAM.

Ngoài Buffer Pool được cấp phát một lần (Global), MySQL còn có các buffer cấp phát mỗi khi có một truy vấn cần sử dụng (Per-thread). Nếu max_connections là 50, lượng RAM tiêu thụ tối đa trong trường hợp xấu nhất sẽ là 50 nhân với tổng dung lượng của các buffer này.

Giảm sort_buffer_size và read_buffer_size

Bạn cần thiết lập các giá trị buffer này ở mức tối thiểu gọn nhẹ nhất. MySQL/MariaDB sẽ tự động cấp phát thêm bộ nhớ tạm trên disk nếu thực sự cần thiết, do đó base size nên được giữ ở mức nhỏ.

[mysqld]
sort_buffer_size = 256K
read_buffer_size = 128K
join_buffer_size = 256K

• sort_buffer_size: Bộ đệm dùng cho các lệnh SQL có chứa ORDER BY hoặc GROUP BY. Đặt ở mức 256K là an toàn cho VPS nhỏ.
• read_buffer_size: Bộ đệm được sử dụng khi MySQL phải quét toàn bộ bảng (sequential scan). Mức 128K giúp tiết kiệm RAM đáng kể.
• join_buffer_size: Dùng cho các lệnh JOIN không có index tối ưu. Đặt ở mức 256K để tránh lãng phí bộ nhớ vô ích.

Vô hiệu hóa Performance Schema

Performance Schema là công cụ giám sát nội bộ của MySQL giúp theo dõi hiệu suất các truy vấn. Tuy nhiên, mặc định nó tiêu tốn khoảng 100MB đến 200MB RAM ngay từ lúc khởi động, một sự lãng phí quá lớn với VPS 1GB.

[mysqld]
performance_schema = 0

• performance_schema = 0: Tắt hoàn toàn tính năng giám sát này. Đây là bước bắt buộc phải làm trên mọi VPS có RAM từ 2GB trở xuống.

⚠️ Cảnh báo: Rất nhiều người nhầm lẫn giữa Global Buffers (như innodb_buffer_pool_size) và Per-thread Buffers. Việc copy cấu hình trên mạng và tăng Per-thread Buffers quá tay là nguyên nhân số 1 gây tràn RAM bí ẩn.

5. Áp dụng cấu hình và kiểm tra bằng MySQLTuner

Tóm gọn: Restart dịch vụ để nhận cấu hình mới, sau đó dùng script MySQLTuner để đánh giá lại hệ thống sau 24h hoạt động.

Sau khi lưu file my.cnf, hệ thống sẽ không tự động nhận diện các thay đổi này. Bạn bắt buộc phải khởi động lại MySQL/MariaDB và kiểm tra trạng thái dịch vụ ngay lập tức để đảm bảo không có lỗi cú pháp.

Khởi động lại dịch vụ

Sử dụng công cụ systemctl mặc định trên Ubuntu 22.04/24.04 để quản lý tiến trình. Hãy chạy lệnh sau với quyền root hoặc sudo.

systemctl restart mariadb
systemctl status mariadb

● mariadb.service - MariaDB 10.6.18 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2023-10-23 10:00:00 UTC; 5s ago

• systemctl restart: Lệnh ép buộc dịch vụ khởi động lại và đọc lại file my.cnf. Hãy thay mariadb bằng mysql nếu bạn đang dùng MySQL bản gốc.
• systemctl status: Kiểm tra xem tiến trình có đang chạy (active) hay không. Nếu báo failed, bạn đã cấu hình sai ở bước trước.

Cài đặt và chạy MySQLTuner

MySQLTuner là một script Perl mã nguồn mở giúp phân tích cấu hình và dữ liệu thực tế để đưa ra lời khuyên tối ưu. Lưu ý rằng bạn chỉ nên chạy script này sau khi database đã hoạt động liên tục ít nhất 24 giờ để có số liệu chính xác.

wget http://mysqltuner.pl/ -O mysqltuner.pl
chmod +x mysqltuner.pl
./mysqltuner.pl

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1d 2h 30m 15s (10K q [0.100 qps], 500 conn, TX: 50M, RX: 10M)
[OK] Maximum reached memory usage: 350.5M (35.05% of installed RAM)
[OK] Maximum possible memory usage: 450.2M (45.02% of installed RAM)
[OK] InnoDB buffer pool / data size: 256.0M/50.0M

• wget: Lệnh tải script trực tiếp từ kho lưu trữ chính thức.
• chmod +x: Cấp quyền thực thi cho file script vừa tải về.
• ./mysqltuner.pl: Chạy script để phân tích. Hãy chú ý đến dòng Maximum possible memory usage, đảm bảo nó không vượt quá 50% tổng RAM của VPS.

💡 Mẹo: Đừng nhắm mắt làm theo 100% lời khuyên của MySQLTuner. Script này không tự biết bạn đang chạy trên VPS 1GB. Hãy chỉ dùng nó để phát hiện các chỉ số bất thường như fragmented tables hay thiếu index.

Pitfalls & lỗi thường gặp

Dưới đây là các trường hợp lỗi phổ biến nhất khi tuning MySQL trên VPS nhỏ và cách khắc phục triệt để.

• Case 1: MySQL bị OOM Killer dập tắt (Error 137)
  • Triệu chứng: Website báo lỗi “Error establishing a database connection”. Khi kiểm tra log /var/log/syslog hoặc lệnh dmesg, bạn thấy dòng chữ Out of memory: Killed process (mysqld).
  • Cách fix: Bạn đã thiết lập innodb_buffer_pool_size quá cao so với lượng RAM thực tế. Hãy giảm thông số này xuống mức 128M hoặc 256M. Đồng thời, bắt buộc phải tạo thêm 1GB đến 2GB Swap file cho hệ điều hành Ubuntu.
• Case 2: Lỗi “Too many connections”
  • Triệu chứng: Ứng dụng web không thể kết nối tới database và liên tục trả về lỗi SQLSTATE[HY000] [1040] Too many connections.
  • Cách fix: Tham số max_connections (đang set 50) đã bị vượt quá giới hạn. Hãy kiểm tra lại code website xem có bị rò rỉ kết nối (không đóng connection sau khi query) hay không. Tạm thời bạn có thể tăng lên 75 trong my.cnf và restart lại dịch vụ.
• Case 3: Cấu hình xong MySQL không khởi động được
  • Triệu chứng: Lệnh systemctl restart mariadb thất bại và báo lỗi Job for mariadb.service failed because the control process exited with error code.
  • Cách fix: Chạy ngay lệnh journalctl -xeu mariadb.service để xem chi tiết nguyên nhân. Lỗi này 99% là do bạn gõ sai chính tả tên biến trong my.cnf (ví dụ: innodb_buffer_pool_sizee) hoặc đặt biến sai vị trí (nằm ngoài block [mysqld]).
• Case 4: RAM vẫn đầy dù đã tuning
  • Triệu chứng: Lệnh htop báo RAM vẫn chạm đỉnh 95% sau khi chạy MySQL được 1 tiếng, hệ thống bắt đầu giật lag.
  • Cách fix: Kiểm tra lại xem bạn đã thêm dòng performance_schema = 0 chưa và đã restart dịch vụ chưa. Nếu MySQL chỉ chiếm 300MB nhưng RAM vẫn đầy, thủ phạm ăn RAM chính là Web Server (PHP-FPM hoặc Apache), bạn cần chuyển sang tuning các dịch vụ đó.

Key takeaways

• Tối ưu innodb_buffer_pool_size là bước quan trọng nhất, nhưng chỉ nên chiếm tối đa 30-40% tổng RAM vật lý trên VPS nhỏ.
• Luôn tắt tính năng performance_schema trên VPS 1GB-2GB để thu hồi ngay lập tức 100MB – 200MB RAM quý giá.
• Bóp chặt giới hạn max_connections (khoảng 50 kết nối) để ngăn chặn việc cấp phát bộ đệm vô tội vạ cho các kết nối rác.
• Giữ các bộ đệm cấp phát theo luồng (như sort_buffer_size, read_buffer_size) ở mức tối thiểu gọn nhẹ nhất (128K – 256K).
• Luôn backup file my.cnf trước khi chỉnh sửa và biết cách dùng journalctl để đọc log nếu dịch vụ từ chối khởi động.

FAQ

Có nên dùng Swap cho VPS 1GB chạy MySQL không?

Bắt buộc phải có Swap. Swap đóng vai trò như phao cứu sinh khi VPS đột ngột cạn kiệt RAM vật lý do traffic tăng cao. Hãy tạo ít nhất 1GB đến 2GB Swap file trên Ubuntu để tránh việc OOM Killer tiêu diệt database.

MariaDB và MySQL có dùng chung file my.cnf không?

Cấu trúc file cấu hình của chúng tương tự nhau nhưng vị trí lưu trữ thường khác biệt. Trên Ubuntu 22.04/24.04, hệ thống tách riêng thư mục /etc/mysql/mariadb.conf.d/ cho MariaDB và /etc/mysql/mysql.conf.d/ dành cho MySQL.

Làm sao biết MySQL đang dùng bao nhiêu RAM thực tế?

Bạn có thể dùng lệnh ps -o pid,user,%mem,command ax | grep mysql hoặc xem trực tiếp qua công cụ dòng lệnh htop. Cột RES trong giao diện htop sẽ thể hiện chính xác lượng RAM vật lý mà tiến trình đang chiếm dụng.

Khi nào cần nâng cấp VPS thay vì tiếp tục tuning?

Khi bạn đã tối ưu hết mức nhưng htop báo CPU luôn ở mức 100% do I/O Wait, hoặc database liên tục báo lỗi kết nối do traffic thực tế quá lớn. Lúc này tuning phần mềm không còn tác dụng, bạn bắt buộc phải nâng cấp thêm RAM và CPU.

Cần VPS chạy MySQL/MariaDB ổn định?

Tuning cấu hình chỉ phát huy tối đa sức mạnh khi bạn có một nền tảng máy chủ mạnh mẽ với ổ cứng NVMe tốc độ cao. Nếu bạn đang tìm kiếm giải pháp hạ tầng tối ưu cho database, hãy tham khảo ngay các gói dịch vụ chất lượng tại https://vsis.net/vps. Đảm bảo hiệu năng vượt trội, uptime ổn định và hỗ trợ kỹ thuật chuyên sâu cho mọi nhu cầu của bạn.