Tối ưu cấu hình VPS theo số liệu 30 ngày: Tránh lãng phí phần cứng

Khi lựa chọn cấu hình máy chủ cho một ứng dụng web mới hoặc nâng cấp hệ thống hiện tại, tâm lý phổ biến của nhiều kỹ sư là "thuê dư cho yên tâm" (Over-provisioning). Nỗi sợ máy chủ bị quá tải trong giờ cao điểm thường dẫn đến việc doanh nghiệp sẵn sàng chi trả cho gói VPS 8 vCPU và 16GB RAM (40 đến60 USD mỗi tháng), dù lượng tải thực tế cả tháng hầu như không dùng hết 1 vCPU và 3GB RAM.

Khoản chi phí chênh lệch này trông có vẻ nhỏ trên một máy chủ đơn lẻ, nhưng khi nhân lên với cụm 5 đến 10 máy chủ (Web Nodes, Staging, Worker, Tools nội bộ), ngân sách lãng phí có thể lên tới hàng nghìn USD mỗi năm. Ngược lại, việc hạ cấu hình một cách cảm tính mà không có số liệu kiểm chứng lại đẩy hệ thống vào nguy cơ nghẽn tải, rớt kết nối hoặc kích hoạt cơ chế OOM Killer tiêu diệt tiến trình cơ sở dữ liệu.

Để giải quyết bài toán này, phương pháp điều chỉnh cấu hình theo nhu cầu thực tế (Right-Sizing) không dựa vào phỏng đoán hay cảm giác an toàn, mà căn cứ vào chuỗi số liệu giám sát trong 30 ngày. Bài viết này hướng dẫn bạn phương pháp đọc đúng số liệu phân vị P95 CPU, phân biệt giữa RAM dùng thật và bộ nhớ đệm đĩa, nhận diện điểm nghẽn ổ đĩa qua chỉ số %iowait, cùng quy trình 4 bước thay đổi cấu hình an toàn với thời gian gián đoạn tối thiểu.

Tại sao số liệu trung bình và đỉnh cực đại thường gây sai lệch?

Nhiều quản trị viên đưa ra quyết định nâng hoặc hạ cấu hình dựa trên bảng điều khiển mặc định của nhà cung cấp đám mây hoặc lệnh top chạy tức thời. Hai cách tiếp cận này thường dẫn đến hai sai lầm kỹ thuật trái ngược nhau:

1. Cạm bẫy của giá trị trung bình (Average CPU)

Giá trị trung bình làm phẳng toàn bộ các đỉnh tải trong ngày. Ví dụ: một website tin tức hoặc thương mại điện tử có lượng truy cập thấp vào ban đêm (CPU chỉ 5%), nhưng trong khung giờ vàng 19:30 đến 21:30, lượng người dùng tăng vọt khiến CPU hoạt động ở mức 85%.

Nếu tính trung bình theo chu kỳ 24 giờ hoặc 30 ngày, hệ thống sẽ báo mức sử dụng CPU chỉ khoảng 15% – 20%. Nếu người quản trị vội vàng hạ cấu hình máy chủ từ 4 vCPU xuống 2 vCPU dựa trên con số 20% này, hệ thống chắc chắn sẽ bị tê liệt ngay trong đợt cao điểm tối hôm sau.

2. Sự ngộ nhận từ giá trị cực đại tức thời (Max Peak / P100)

Ngược lại, nếu bạn nhìn vào biểu đồ và thấy CPU chạm ngưỡng 98%, bạn có thể nghĩ rằng máy chủ đã quá tải và cần nâng cấp gói cấu hình cao hơn. Tuy nhiên, nếu kiểm tra nhật ký cronjob, bạn sẽ phát hiện đỉnh 98% này chỉ xuất hiện trong vòng 2 phút lúc 03:00 sáng, khi tiến trình sao lưu nén tệp tin tar.gz hoạt động.

Trong 23 giờ 58 phút còn lại của ngày, CPU không bao giờ vượt quá 15%. Việc bỏ ra gấp đôi tiền hàng tháng chỉ để phục vụ một tác vụ chạy nền trong 2 phút là một sự lãng phí phần cứng không đáng có.

3. Chuẩn mực đo lường: Chỉ số phân vị P95 (95th Percentile)

Để loại trừ hai cạm bẫy trên, ngành quản trị hạ tầng sử dụng phân vị 95 (P95) trên chu kỳ 30 ngày làm thước đo năng lực:

• Nguyên lý P95: Sắp xếp toàn bộ các mẫu đo CPU trong tháng theo thứ tự từ thấp đến cao và lấy giá trị ở vị trí 95%. Điều này đồng nghĩa với việc: trong 95% thời gian vận hành của tháng, hệ thống hoạt động dưới ngưỡng này; chỉ có 5% thời gian xuất hiện các đột biến ngắn hạn được loại trừ.
• Giá trị thực tế: P95 bao quát trọn vẹn toàn bộ các khung giờ cao điểm thường nhật của người dùng thật, giúp bạn xác định chính xác năng lực tính toán cần thiết của ứng dụng.

Phân tích 3 thông số giám sát cốt lõi trong 30 ngày

Để đưa ra quyết định điều chỉnh cấu hình chính xác, bạn cần thu thập số liệu từ hệ thống giám sát (như Prometheus, Grafana, Netdata hoặc Cloud Monitoring) theo hướng dẫn tại các chỉ số giám sát VPS quan trọng.

1. Chỉ số vCPU: Tách biệt giữa xử lý code và chờ đợi I/O

Không phải mọi trường hợp CPU cao đều do ứng dụng thiếu vCPU. Bạn cần phân tích cấu trúc sử dụng CPU:

• user + system: Tỷ lệ CPU thực sự đang xử lý mã nguồn (PHP, NodeJS, Python, Go) hoặc tác vụ nhân Linux.
• %iowait: Tỷ lệ thời gian CPU ở trạng thái nghỉ vì đang phải chờ ổ đĩa phản hồi dữ liệu.

Nếu chỉ số P95 của user + system vượt trên 80%, đó là dấu hiệu máy chủ thực sự chạm trần tính toán. Nhưng nếu CPU báo 80% mà trong đó %iowait chiếm tới 60%, nguyên nhân gốc nằm ở ổ đĩa đọc ghi chậm. Việc nâng thêm số lượng vCPU trong tình huống này hoàn toàn vô ích, vì các lõi CPU mới được thêm vào cũng chỉ nhàn rỗi đứng chờ ổ đĩa.

2. Bộ nhớ RAM: Phân biệt giữa "Free RAM" và "Available RAM"

Một ngộ nhận kỹ thuật rất phổ biến khi kiểm tra bộ nhớ bằng lệnh free -m:

               total        used        free      shared  buff/cache   available
Mem:           15980        4210         320         280       11450       11250
Swap:           2048           0        2048

Nhiều người nhìn vào cột free thấy chỉ còn 320MB và kết luận máy chủ sắp cạn kiệt RAM.

Thực tế, nhân Linux luôn chủ động dùng phần RAM chưa sử dụng để nạp các tệp tin thường dùng vào bộ nhớ đệm (buff/cache) nhằm tăng tốc độ hệ thống. Khi ứng dụng cần thêm bộ nhớ, Linux sẽ lập tức thu hồi không gian cache này để cấp phát cho ứng dụng.

Chỉ số duy nhất phản ánh chính xác dung lượng bộ nhớ thực tế là available (ở đây là 11.250MB ≈ 11.2GB). Nếu cột available duy trì ổn định trên 50% tổng dung lượng RAM suốt 30 ngày và phân vùng Swap không phát sinh hoạt động đọc ghi (pgpgin/pgpgout = 0), máy chủ của bạn đang dư thừa rất nhiều RAM.

3. Tần suất truy cập Swap (Swap In / Swap Out)

Khi RAM thực sự cạn kiệt, hệ điều hành phải đẩy các trang nhớ sang phân vùng Swap trên đĩa. Do tốc độ đọc ghi của ổ đĩa chậm hơn hàng nghìn lần so với RAM, hiện tượng swap liên tục sẽ làm tê liệt toàn bộ ứng dụng.

Nếu trong 30 ngày, tỷ lệ sử dụng Swap luôn bằng 0 hoặc không phát sinh thao tác tráo đổi trang nhớ liên tục, đây là tín hiệu xác nhận dung lượng RAM hiện tại đang vượt xa nhu cầu của ứng dụng.

Quy tắc điều chỉnh cấu hình VPS theo mức tải thực tế

Sau khi thu thập chuỗi số liệu 30 ngày, bạn đối chiếu các thông số đo đạc với bảng tổng hợp dưới đây để xác định chính xác trạng thái của máy chủ:

Phân tích chi tiết 4 tình huống vận hành

1. Dư thừa tài nguyên (Over-provisioned)

Khi P95 CPU dưới 30% và lượng RAM khả dụng (MemAvailable) luôn vượt quá phân nửa tổng bộ nhớ trong suốt cả tháng, máy chủ đang chạy dưới mức công suất thiết kế.

Phương án hợp lý là hạ 1 bậc cấu hình (ví dụ: chuyển từ gói 8 vCPU / 16GB RAM xuống 4 vCPU / 8GB RAM). Thao tác này giúp bạn cắt giảm ngay 40% đến 50% chi phí thuê máy chủ mà hiệu năng ứng dụng hoàn toàn không bị ảnh hưởng. Bạn nên tránh hạ sâu 2 đến 3 bậc một lúc để luôn giữ lại biên độ an toàn cho các đợt tăng tải đột xuất.

2. Vùng tải tối ưu (Sweet Spot)

Đây là trạng thái cân bằng lý tưởng nhất của hạ tầng. Mức sử dụng CPU P95 dao động trong khoảng 45% đến 70% chứng minh phần cứng đang được khai thác hiệu quả, đồng thời vẫn còn từ 30% đến 50% công suất dự phòng để hấp thụ các đỉnh tải trong giờ cao điểm. Bạn không cần can thiệp thay đổi cấu hình, chỉ cần duy trì theo dõi định kỳ mỗi quý.

3. Chạm trần năng lực tính toán (Compute Bottleneck)

Khi CPU P95 thường xuyên vượt 80% và chỉ số %iowait thấp (dưới 5%), máy chủ thực sự đang bị nghẽn ở khâu xử lý mã nguồn.

Tuy nhiên, thay vì vội vàng chi thêm tiền nâng gói máy chủ, bạn nên rà soát lại kiến trúc phân phối lưu lượng. Việc áp dụng kiến trúc lai Hybrid VPS và Cloudflare (HTS-113) để đẩy việc đàm phán TLS, nén dữ liệu và lưu đệm tài nguyên tĩnh ra tầng biên thường giúp giảm 60% đến 80% áp lực CPU cho máy chủ gốc, giúp bạn duy trì cấu hình hiện tại mà không phát sinh thêm chi phí.

4. Nghẽn đọc ghi ổ đĩa (Disk I/O Bottleneck)

Một sai lầm rất phổ biến là thấy website phản hồi chậm liền vội nâng số lượng vCPU. Nếu số liệu cho thấy P95 CPU chỉ ở mức 20% nhưng %iowait lại vượt trên 20%, điểm nghẽn thực sự nằm ở tốc độ đọc ghi của ổ đĩa.

Trong tình huống này, việc nâng vCPU chỉ làm tăng hóa đơn hàng tháng mà không cải thiện được tốc độ tải trang, vì các nhân CPU mới cũng chỉ nhàn rỗi chờ ổ cứng nạp dữ liệu. Hướng giải quyết đúng là chuyển sang sử dụng ổ đĩa NVMe có tốc độ đọc ghi ngẫu nhiên (Random IOPS) cao hơn, hoặc tách riêng cơ sở dữ liệu sang một cụm lưu trữ chuyên dụng.

Truy vấn PromQL trích xuất số liệu từ Prometheus

Nếu hệ thống của bạn sử dụng cụm Prometheus kết hợp Node Exporter để thu thập số liệu giám sát, bạn có thể chạy trực tiếp các câu truy vấn PromQL sau trong giao diện Grafana để lấy số liệu đánh giá:

1. Tính toán P95 vCPU trong 30 ngày:

Truy vấn này tính phân vị 95 của tỷ lệ sử dụng CPU thực tế (loại bỏ thời gian nhàn rỗi idle), lấy mẫu mỗi 1 giờ trên toàn bộ dải thời gian 30 ngày:

quantile_over_time(0.95, (1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))[30d:1h]) * 100

2. Tính toán tỷ lệ RAM sử dụng thực tế (loại bỏ Cache):

(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

3. Tỷ lệ phần trăm thời gian CPU chờ đĩa (%iowait):

avg by (instance) (rate(node_cpu_seconds_total{mode="iowait"}[5m])) * 100

Nếu không dùng Prometheus, bạn có thể sử dụng gói công cụ sysstat tích hợp sẵn trên Linux để xem thống kê lịch sử 30 ngày thông qua tệp nhật ký sar:

# Xem thống kê CPU trung bình theo từng ngày trong tháng
sar -u -f /var/log/sysstat/sa$(date +%d)

# Xem thống kê dung lượng bộ nhớ thực tế
sar -r

Quy trình 4 bước thay đổi cấu hình an toàn (Safe Resize Runbook)

Khi số liệu 30 ngày xác nhận máy chủ của bạn thuộc Kịch bản 1 (Dư thừa phần cứng) và bạn quyết định hạ cấu hình để cắt giảm chi phí, hãy tuân thủ quy trình 4 bước sau để đảm bảo không gặp sự cố:

Bước 1: Tính toán cấu hình mục tiêu với biên độ an toàn 30%

Không bao giờ hạ cấu hình vừa khít với số liệu P95. Bạn luôn cần duy trì một biên độ dự phòng an toàn (Safety Headroom) tối thiểu 30%:

$vCPU mục tiêu = P95 vCPU × 1.3RAM mục tiêu = RAM sử dụng thực tế đỉnh × 1.3$

Ví dụ: Máy chủ hiện tại có 8 vCPU / 16GB RAM. Số liệu 30 ngày ghi nhận P95 vCPU là 1.8 vCPU và RAM sử dụng thực tế tối đa là 4.2GB.

• vCPU mục tiêu: 1.8 × 1.3 = 2.34 (Làm tròn lên gói 4 vCPU).
• RAM mục tiêu: 4.2 × 1.3 = 5.46GB (Làm tròn lên gói 8GB RAM).
• Kết luận: Bạn có thể hạ cấu hình từ gói 8 vCPU / 16GB RAM (48/tháng) xuống gói 4 vCPU / 8GB RAM (24/tháng), tiết kiệm ngay 50% chi phí máy chủ này mà vẫn đảm bảo độ an toàn cao.

Bước 2: Tạo bản sao lưu chốt chặn trước khi thay đổi

Trước khi thực hiện bất kỳ thao tác thay đổi phần cứng nào:

1. Chụp snapshot toàn bộ máy chủ trên bảng điều khiển đám mây.
2. Xuất một bản sao lưu cơ sở dữ liệu (mysqldump hoặc pg_dump) và lưu trữ độc lập ra dịch vụ Object Storage ngoài máy chủ.

Bước 3: Thực hiện thay đổi cấu hình trong khung giờ bảo trì

Lựa chọn khung giờ lưu lượng truy cập thấp nhất trong tuần (thường từ 01:00 đến 03:00 sáng):

1. Thông báo thời gian bảo trì ngắn (khoảng 10 phút) nếu ứng dụng chưa có cơ chế chuyển vùng dự phòng.
2. Tắt các dịch vụ web và ứng dụng để đảm bảo toàn bộ dữ liệu trên bộ nhớ đệm được ghi hoàn tất xuống đĩa:

   sudo systemctl stop nginx
   sudo systemctl stop docker

1. Tắt máy chủ (Shutdown / Stop Instance) từ bảng điều khiển hoặc lệnh sudo poweroff.
2. Trên giao diện quản trị của nhà cung cấp đám mây (AWS EC2, DigitalOcean, Hetzner), chọn tính năng Resize Instance / Change Plan sang gói cấu hình mục tiêu đã tính toán.
3. Khởi động lại máy chủ (Start Instance). Quá trình này thường diễn ra trong vòng 90 đến 180 giây.

Lưu ý quan trọng về ổ đĩa: Đa số các nhà cung cấp đám mây cho phép tăng dung lượng ổ đĩa một chiều nhưng không hỗ trợ thu nhỏ ổ đĩa (Disk Shrink). Khi chọn hạ gói cấu hình, bạn chỉ nên hạ số lượng vCPU và dung lượng RAM (Compute Resize), giữ nguyên phân vùng ổ đĩa hiện tại để tránh nguy cơ lỗi hệ thống tập tin.

Bước 4: Giám sát chặt chẽ trong 72 giờ đầu tiên

Sau khi máy chủ khởi động lại với cấu hình mới:

• Kiểm tra tính sẵn sàng của toàn bộ dịch vụ: Nginx, PHP/Node, MySQL, Docker containers.
• Theo dõi sát biểu đồ CPU, RAM và độ trễ phản hồi trang (TTFB) trong 72 giờ liên tục.
• Kiểm tra nhật ký nhân Linux để đảm bảo không xuất hiện thông điệp cảnh báo OOM:

  sudo dmesg -T | grep -i -E "oom|out of memory|killed process"

Tích hợp vào chu trình quản trị định kỳ

Việc tối ưu cấu hình máy chủ không phải là thao tác làm một lần rồi bỏ quên. Bạn nên đưa hoạt động rà soát này vào chu trình quản trị VPS hàng tháng hoặc đánh giá định kỳ hàng quý:

1. Trước các đợt cao điểm kinh doanh (Mùa mua sắm, chiến dịch lớn): Tạm thời giữ nguyên hoặc nâng tạm thời cấu hình trước 1 tuần nếu dự báo lưu lượng tăng trên 50%.
2. Sau các đợt cao điểm: Khi lưu lượng quay trở về trạng thái bình thường sau 30 ngày, bạn rà soát lại các biểu đồ giám sát để hạ cấu hình về mức tối ưu, tránh để chi phí phát sinh kéo dài qua các tháng thấp điểm.
3. Phối hợp với dọn dẹp tài nguyên: Kết hợp việc điều chỉnh cấu hình máy chủ với việc dọn dẹp tài nguyên dư thừa (HTS-114) để đưa ngân sách hạ tầng của doanh nghiệp về trạng thái tinh gọn.

Bài viết tiếp theo trong cụm quản trị chi phí

Sau khi đã làm chủ phương pháp điều chỉnh cấu hình máy chủ dựa trên số liệu thực tế, bước tiếp theo để chuẩn hóa việc quản trị chi phí là áp dụng bảng kiểm toán định kỳ:

• Đọc bài Checklist kiểm soát chi phí hạ tầng doanh nghiệp (HTS-116) để sở hữu bảng kiểm toán FinOps toàn diện hàng tháng, thiết lập cảnh báo ngân sách tự động và quy trình rà soát hợp đồng cam kết.