Website tăng traffic: nâng RAM, CPU hay đổi kiến trúc trước

Website bắt đầu chậm dần theo từng nghìn visitor, và phản xạ của nhiều người là mở ngay bảng giá VPS để nâng cấp RAM hoặc CPU. Nhưng theo kinh nghiệm vận hành của mình, 7 trên 10 trường hợp website chậm vì traffic tăng không đến từ thiếu tài nguyên phần cứng, mà đến từ cấu hình ứng dụng chưa theo kịp. Một câu SQL không có index, một pool PHP-FPM quá nhỏ, hoặc swap đang gào thét vì thiết lập sai. Nâng cấp VPS là bước cuối, không phải bước đầu. Bài này mình sẽ hướng dẫn quy trình chẩn đoán chính xác và thứ tự xử lý đúng khi website tăng traffic.

Khi nào website thực sự cần nâng cấp VPS?

Câu trả lời ngắn: khi bạn đã tối ưu hết mọi lớp phía trên (code, database, cache, cấu hình web server) mà tài nguyên vẫn khan hiếm. Mình từng thấy một case WordPress chạy trên VPS 2GB RAM, traffic 5000 visitor/ngày, vẫn nuột nà sau khi bật page cache và tối ưu database. Chủ website suýt nâng lên gói 4GB vì nghĩ RAM là nguyên nhân. Thực tế, load average chỉ loanh quanh 0.5, iowait dưới 2%.

Dấu hiệu thực sự cần nâng cấp VPS: load average vượt số lõi CPU trong thời gian dài, iowait trên 10-15% liên tục, memory pressure khiến kernel bắt đầu kill process (OOM killer), hoặc swap sử dụng trên 30-40% dung lượng được cấp. Khi đó, kiến trúc hiện tại đã không đáp ứng nổi workload thực tế.

VPS hạ tầng Việt Nam như của thueVPS, với NVMe, IPv4 riêng, băng thông trong nước 100 Mbps, thường không phải nút cổ chai về I/O hay mạng cho đa số website tầm trung. Bottleneck thường nằm ở phần mềm hoặc cấu hình. Nếu bạn đã kiểm tra kỹ mà vẫn thiếu tài nguyên, thuê VPS Linux với cấu hình cao hơn là hướng đi đúng.

Bước 1: Đọc đúng các chỉ số hệ thống

Trước khi nghĩ đến nâng cấp VPS, bạn cần trả lời chính xác ba câu hỏi: CPU có bận không? Đĩa có chờ không? RAM có đủ không? Cả ba đều có công cụ đo trực tiếp trên Linux.

Load average và CPU

Lệnh đầu tiên khi thấy website chậm là uptime hoặc top. Load average hiển thị ba số cho 1, 5 và 15 phút. Quy tắc đơn giản: nếu load lớn hơn số lõi CPU (vd VPS 2 vCPU, load > 2), CPU đang quá tải. Dùng mpstat -P ALL 1 để xem từng lõi có %idle cao không; nếu %sys cao, kernel đang vật lộn với I/O hoặc context switch.

uptime
# output: 10:30:45 up 5 days, 2:10, 2 users, load average: 3.45, 2.80, 2.10
# VPS 2 vCPU, load > 2 ổn định -> thiếu CPU

Iowait, kẻ giết hiệu năng âm thầm

Iowait là thời gian CPU rỗi chờ I/O đĩa hoàn tất. Dùng iostat -x 1 5: nếu cột %iowait > 10-15% liên tục, storage đang là bottleneck. Với VPS NVMe, iowait thường rất thấp. Nếu cao, khả năng là swap đang hoạt động mạnh, hoặc database chạy truy vấn nặng thiếu index.

iostat -x 1 3
# avg-cpu:  %user %nice %system %iowait %steal %idle
#            15.2   0.0   3.1   18.7   0.0  63.0
# 18.7% iowait -> đĩa đang nghẹt, kiểm tra swap trước

Memory pressure, swap và OOM

Lệnh free -h cho thấy memory dùng và swap. Nếu swap used > 0 và tiếp tục tăng, RAM đang thiếu. Dùng vmstat 1 cột si so, nếu swap in/swap out > 0 liên tục, bạn đang bị memory pressure nặng. Đây là lúc cần nâng cấp VPS RAM, nhưng trước đó hãy kiểm tra xem ứng dụng có dùng cache hiệu quả không.

free -h
#               total        used        free      shared  buff/cache   available
# Mem:           1.9Gi       1.5Gi        98Mi       110Mi       330Mi       246Mi
# Swap:          512Mi       420Mi        92Mi
# Swap dùng 420/512 MB -> thiếu RAM trầm trọng, cần nâng cấp hoặc tối ưu ứng dụng

Bước 2: Kiểm tra tầng ứng dụng, database và web server

Sau khi loại trừ bottleneck phần cứng, bước tiếp theo là kiểm tra code và cấu hình. Slow query log của MySQL/MariaDB là công cụ hàng đầu. Dùng lệnh sau để bật slow query log tạm thời, chạy vài phút rồi tắt.

# Bắt đầu ghi slow query
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

# Chờ 5 phút, xem file
cat /var/log/mysql/slow.log | grep -c "Query_time:"
# Nếu có nhiều query trên 1 giây -> cần optimize index hoặc query

Tiếp theo, kiểm tra PHP-FPM pool. File config thường ở /etc/php/8.3/fpm/pool.d/www.conf (Ubuntu 24.04). Kiểm tra pm.max_children, nếu giá trị quá thấp so với traffic worker, bạn sẽ thấy lỗi 502 hoặc 504. Công thức đơn giản: pm.max_children = (total RAM - OS - MySQL) / avg PHP process size. Ví dụ: VPS 2GB RAM, MySQL dùng 300MB, mỗi PHP process ~ 40MB → max_children ≈ (2048 - 100 - 300) / 40 ≈ 41.

Bước 3: Tối ưu cache, giải pháp rẻ nhất trước khi nâng cấp VPS

Trước khi tính chuyện nâng cấp VPS lên gói cao hơn, hãy dùng thử các lớp cache. Mình gọi đây là "tip tiết kiệm tiền nhất cho sysadmin". Với WordPress, bật page cache (Redis cache + Nginx fastcgi cache hoặc LiteSpeed cache) có thể giảm tải 90% request động. Với web ứng dụng tự viết, kiểm tra xem có dùng opcache PHP, query cache MySQL, và Redis làm object cache chưa.

Một case thực tế: website PHP thuần 5000 request/phút, sau khi bật Redis cache cho session và query cache, CPU giảm từ 80% xuống 15%. Chủ website định nâng từ 2 lên 4 vCPU, cuối cùng chẳng cần nâng gì. Bảng giá dịch vụ VPS cho thấy chi phí nâng cấp mỗi tháng không nhỏ, tối ưu cache trước giúp bạn không phải chạm đến nút upgrade.

Bước 4: Khi nào thực sự nên nâng cấp, và nâng cái gì trước

Sau khi đã chẩn đoán và tối ưu hết mọi thứ, nếu ba chỉ số dưới đây vẫn vượt ngưỡng, đó là lúc mở billing để nâng cấp:

• Load > số vCPU * 1.5 trong 1 giờ+ → nâng CPU (thêm vCPU).
• Swap used > 50% tổng swap và vmstat báo si/so > 0 → nâng RAM trước.
• Iowait > 15% và iostat báo await > 20ms → cần VPS NVMe (nếu đang chạy HDD), hoặc nâng dung lượng RAM để giảm swap.

Thứ tự ưu tiên: RAM → CPU → Storage. RAM thiếu sẽ kéo theo swap, swap làm tăng iowait, iowait làm CPU chờ, cuối cùng là load cao. Nâng RAM giải quyết gốc rễ. Với VPS Windows cũng tương tự, Administrator nên kiểm tra Performance Monitor trước khi tăng vCPU.

Bước 5: Cân nhắc đổi kiến trúc thay vì nâng cấp phần cứng

Đôi khi, bottleneck là do kiến trúc ứng dụng không scalable. Một website PHP chạy single server, mọi request đều đồng bộ, dù nâng lên VPS 16GB RAM + 8 vCPU vẫn chậm dưới traffic torrent. Giải pháp là tách lớp: đặt Nginx reverse proxy + static cache ở tầng trước, PHP-FPM ở tầng sau, database riêng. Hoặc dùng Docker chạy many workers và load balance.

Nếu bạn đang chạy WordPress, thử di chuyển sang kiến trúc LiteSpeed + LSCache (WP plugin). Mình từng thấy một site WooCommerce với 50.000 sản phẩm, sau khi đổi web server từ Apache sang LiteSpeed và dùng LSCache queue mode, CPU giảm 70% dù traffic tăng gấp đôi. Đây là lúc "đổi kiến trúc" rẻ hơn nhiều so với nâng cấp VPS lên gói cao cấp.

Thứ tự xử lý bài bản khi website tăng traffic

1. Chẩn đoán: Đọc load, iowait, memory, slow query. Ghi lại baseline trước khi can thiệp.
2. Tối ưu tầng ứng dụng: Thêm index cho slow query, tăng PHP-FPM max_children, bật opcache, Redis cache.
3. Tối ưu tầng web server: Bật Nginx fastcgi cache / LiteSpeed cache, tối ưu worker connections, bật HTTP/2 và Brotli.
4. Tối ưu database: Cấu hình InnoDB buffer pool đúng, bật slow query log để bắt query xấu.
5. Kiểm tra lại chỉ số: Nếu load và iowait đã giảm, không cần nâng cấp.
6. Nếu vẫn quá tải: Nâng cấp VPS, ưu tiên RAM trước, rồi CPU, cuối cùng là storage NVMe dung lượng lớn hơn.

Hãy nhớ: nâng cấp VPS là mua thêm tài nguyên để che giấu bottleneck chưa được xử lý. Làm sạch bottleneck trước, phần cứng sẽ tự dưng "đủ" hơn rất nhiều.

Câu hỏi thường gặp

Bài viết liên quan

• Tối ưu MariaDB cho VPS RAM thấp trên Ubuntu 24.04
• Tối ưu PHP-FPM cho WordPress trên VPS Ubuntu
• Tối ưu Nginx cho traffic cao, worker, gzip, buffer, cache