Hướng Dẫn Tối Ưu Hiệu Năng eCloud VPS Cho Nginx, PHP-FPM Và MariaDB
1. Giới thiệu tổng quan
Trong quá trình vận hành website doanh nghiệp hoặc ứng dụng thương mại điện tử trên hạ tầng eCloud VPS của ESC, hiện tượng phản hồi chậm, nghẽn kết nối hoặc xuất hiện lỗi 502 Bad Gateway / 504 Gateway Timeout thường không bắt nguồn từ thiếu hụt phần cứng mà do các thông số mặc định của Web Server và Database chưa được tinh chỉnh tương thích với lượng truy cập thực tế.
Tài liệu này hướng dẫn chi tiết quy trình chuẩn hóa các tham số cốt lõi của Nginx, PHP-FPM và MariaDB/MySQL nhằm khai thác tối đa tài nguyên CPU, RAM và ổ cứng SSD/NVMe trên máy chủ.
2. Tối ưu hóa Web Server Nginx
File cấu hình chính của Nginx nằm tại /etc/nginx/nginx.conf. Thực hiện mở file và điều chỉnh các khối tham số:
sudo nano /etc/nginx/nginx.conf2.1. Cấu hình luồng xử lý (Worker Processes & Connections)
user www-data;
worker_processes auto; # Tự động gán theo số lõi vCPU của VPS
worker_rlimit_nofile 65535; # Tăng giới hạn file descriptor mở đồng thời
events {
worker_connections 4096; # Số kết nối tối đa trên mỗi worker
use epoll; # Cơ chế xử lý I/O hiệu năng cao nhất trên Linux
multi_accept on; # Cho phép worker nhận tất cả kết nối mới cùng lúc
}2.2. Tinh chỉnh Buffer và Keepalive Timeout
Trong khối http { ... }, thêm hoặc sửa các thông số sau để giảm tải CPU và tăng tốc độ phân phối dữ liệu tĩnh:
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 30;
types_hash_max_size 2048;
server_tokens off; # Ẩn thông tin phiên bản Nginx để tăng cường bảo mật
# Giới hạn kích thước gói tin gửi lên (Upload)
client_max_body_size 64M;
# Nén Gzip tiết kiệm băng thông và tăng tốc độ tải trang
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
}Kiểm tra cú pháp và nạp lại cấu hình:
sudo nginx -t && sudo systemctl reload nginx3. Tinh chỉnh Pool xử lý PHP-FPM
Vấn đề nghẽn tài nguyên phổ biến nhất trên máy chủ chạy mã nguồn PHP (như WordPress, Laravel) là việc cấu hình sai chế độ quản lý tiến trình (pm - process manager).
/etc/php-fpm.d/www.conf (AlmaLinux).# Ví dụ trên Ubuntu với PHP 8.2:
sudo nano /etc/php/8.2/fpm/pool.d/www.conf3.1. Công thức tính toán pm.max_children
Mỗi tiến trình PHP-FPM trung bình chiếm khoảng 40MB – 70MB RAM (đối với WordPress). Công thức phân bổ RAM cho PHP-FPM:
Ví dụ: Gói eCloud VPS có 4GB RAM, dành 1GB cho OS/Nginx, 1.5GB cho MySQL, còn lại 1.5GB (1536MB) cho PHP: 1536 / 50 ≈ 30 tiến trình.
3.2. Áp dụng thông số cấu hình tối ưu
pm = dynamic
pm.max_children = 30
pm.start_servers = 8
pm.min_spare_servers = 5
pm.max_spare_servers = 12
pm.max_requests = 500 ; Tự giải phóng tiến trình sau 500 request để chống rò rỉ RAM (Memory Leak)3.3. Kích hoạt OPcache trong php.ini
Mở file php.ini tương ứng (/etc/php/8.2/fpm/php.ini):
opcache.enable=1
opcache.memory_consumption=128 ; Bộ nhớ cấp cho OPcache (MB)
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0 ; Đặt bằng 0 trên môi trường Production để đạt hiệu năng tối đaKhởi động lại dịch vụ PHP-FPM:
sudo systemctl restart php8.2-fpm4. Cấu hình Tối ưu Bộ đệm Database (MariaDB / MySQL)
Cơ sở dữ liệu lưu lượng lớn cần được cấp phát đủ bộ nhớ đệm để các truy vấn đọc/ghi diễn ra trực tiếp trên RAM thay vì truy xuất liên tục vào ổ cứng.
Tạo hoặc chỉnh sửa file cấu hình tùy chỉnh /etc/mysql/mariadb.conf.d/99-custom.cnf (Ubuntu) hoặc /etc/my.cnf.d/server.cnf (AlmaLinux):
[mysqld]
# Tùy chỉnh Engine InnoDB - trái tim của cơ sở dữ liệu
innodb_buffer_pool_size = 1536M # Chiếm khoảng 40% - 60% tổng RAM VPS
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2 # Ghi log bộ đệm mỗi giây (Tăng tốc độ ghi dữ liệu cực nhanh)
innodb_flush_method = O_DIRECT
# Quản lý kết nối
max_connections = 150 # Số kết nối tối đa phù hợp với max_children của PHP
max_connect_errors = 10000
wait_timeout = 60 # Tự động ngắt kết nối rảnh sau 60s
interactive_timeout = 60
# Bộ nhớ đệm bảng tạm
tmp_table_size = 64M
max_heap_table_size = 64MKhởi động lại dịch vụ MariaDB/MySQL để áp dụng:
sudo systemctl restart mariadb5. Kiểm tra Tải và Đánh giá Hiệu quả Tối ưu
Sau khi hoàn tất tinh chỉnh, cần tiến hành đo lường để đảm bảo hệ thống phản hồi ổn định dưới áp lực truy cập:
- Giám sát trực quan mức tiêu thụ: Chạy
htopđể kiểm tra phân bổ CPU và RAM khi có lưu lượng truy cập. - Kiểm tra trạng thái kết nối Nginx:
Lệnh này hiển thị số lượng socket TCP đang ở trạng thái ESTABLISHED, TIME-WAIT để đánh giá mức độ dọn dẹp kết nối rác.ss -s - Theo dõi truy vấn chậm (Slow Queries): Bật cờ
slow_query_log = 1trong MySQL để phát hiện các câu lệnh SQL chiếm nhiều thời gian xử lý và đánh index bổ sung.
6. Tổng hợp Kênh Hỗ trợ Kỹ thuật Chuyên môn tại ESC.VN
Đối với các hệ thống có quy mô cơ sở dữ liệu lớn hàng chục GB, kiến trúc phân tán Master-Slave, hoặc các chiến dịch cao điểm đòi hỏi giải pháp cân bằng tải (Load Balancing), Quý khách hàng có thể liên hệ ngay bộ phận kỹ sư hạ tầng của ESC để được hỗ trợ chuyên sâu:
- Tổng đài Hỗ trợ Kỹ thuật 24/7: 1900 2069
- Hotline trực ban: TP.HCM: (028) 71 099 199 | Hà Nội: (024) 39 42 68 96
- Gửi yêu cầu hỗ trợ (Ticket): esc.vn/support-esc hoặc cổng quản trị member.esc.vn
- Website chính thức: https://esc.vn


![[CẢNH BÁO AN NINH MẠNG] BÁO ĐỘNG CHIẾN DỊCH QUÉT TÌM LỖ HỔNG CHÈN WEB SHELL & DÒ QUÉT CỔNG MÁY CHỦ DOANH NGHIỆP](/api/images/40/png/wp-content/uploads/2026/09/Gemini_Generated_Image_lhrzgclhrzgclhrz.webp)





