Vấn đề: Tại sao “cảm giác” không phải là một thước đo
Tháng trước, tôi đã chuyển API của một khách hàng sang nhà cung cấp VPS mới. Những lời quảng cáo hứa hẹn “lưu trữ NVMe siêu tốc” và “luồng CPU chuyên dụng”. Trên lý thuyết, các thông số kỹ thuật giống hệt như máy chủ cũ của họ. Tuy nhiên, ngay sau khi chuyển đổi, độ trễ (latency) API trung bình đã tăng từ 140ms lên gần 200ms. Về mặt chủ quan, thao tác trên terminal có cảm giác bị lag, nhưng bạn không thể đưa một “cảm giác” vào yêu cầu hỗ trợ và mong đợi được hoàn tiền.
Khoảng cách giữa thông số quảng cáo và thực tế bàn giao thường rất lớn. Các môi trường ảo hóa thường xuyên gặp phải tình trạng CPU steal time hoặc I/O bị bóp băng thông mà không hiển thị trong lệnh top. Để có câu trả lời thực sự, bạn cần dữ liệu khách quan. Tôi dựa vào hai công cụ tiêu chuẩn trong ngành để vượt qua những lời quảng cáo hào nhoáng: UnixBench để đánh giá nhanh hệ thống cơ bản và Phoronix Test Suite để kiểm tra áp lực (stress test) chi tiết cho từng loại tác vụ cụ thể.
Đánh giá cơ bản trong 10 phút: UnixBench
UnixBench là “lão làng” trong việc đo hiệu suất. Nó kiểm tra các hoạt động cơ bản như sao chép tệp, thông lượng đường ống (pipe throughput) và thực thi shell script. Sau đó, nó đưa ra một điểm chỉ số duy nhất. Con số này đóng vai trò như một cách tóm tắt tình trạng hệ thống, cho phép bạn so sánh một instance giá rẻ 5 USD/tháng với một máy chủ dedicated cao cấp chỉ trong vài phút.
1. Chuẩn bị môi trường
Trên một hệ thống Debian hoặc Ubuntu sạch, bạn sẽ cần các công cụ biên dịch cơ bản và Perl để biên dịch mã nguồn của bài benchmark.
sudo apt update
sudo apt install build-essential libx11-dev libgl1-mesa-dev libxext-dev perl -y2. Thực thi bài kiểm tra
Tôi khuyên bạn nên sử dụng bản fork UnixBench hiện đại trên GitHub. Nó xử lý các bộ vi xử lý đa nhân tốt hơn nhiều so với mã nguồn gốc từ những năm 1990.
git clone https://github.com/krakjoe/byte-unixbench.git
cd byte-unixbench/UnixBench
./RunBài kiểm tra thường kết thúc sau khoảng 15 phút. Hãy tìm dòng System Benchmarks Index Score ở dưới cùng. Để tham khảo, một VPS đơn nhân khiêm tốn thường đạt điểm khoảng 900–1.100. Nếu bạn thấy số điểm dưới 600 trên một hệ thống hiện đại, có khả năng nhà cung cấp đang bán quá mức (overselling) tài nguyên phần cứng của họ.
Phân tích chi tiết: Phoronix Test Suite (PTS)
UnixBench cho bạn cái nhìn tổng thể, nhưng nó sẽ không cho bạn biết máy chủ xử lý cơ sở dữ liệu MySQL hoặc nén 7-Zip như thế nào. Đây là lúc Phoronix Test Suite (PTS) tỏa sáng. Đây là một khung thử nghiệm mã nguồn mở, tự động, có khả năng chạy hàng nghìn hồ sơ thử nghiệm riêng biệt.
Cài đặt PTS
Trên Ubuntu 22.04 hoặc 24.04, bạn có thể tải gói .deb mới nhất. Phương pháp này sạch hơn so với cài đặt thủ công vì PTS tự động quản lý các chuỗi phụ thuộc phức tạp cần thiết cho các bài kiểm tra cụ thể.
wget https://phoronix-test-suite.com/releases/repo/pts.debian/files/phoronix-test-suite_10.8.4_all.deb
sudo apt install ./phoronix-test-suite_10.8.4_all.debChạy một bài kiểm tra mục tiêu
PTS sắp xếp các bài benchmark thành các “test suites”. Nếu bạn muốn đo cách CPU xử lý việc nén dữ liệu nặng—một tác vụ phổ biến cho sao lưu tự động—hãy chạy lệnh này:
phoronix-test-suite run pts/compress-7zipKhi quá trình thử nghiệm kết thúc, it sẽ hỏi bạn có muốn lưu kết quả không. Hãy luôn chọn Có (yes). Sử dụng một cái tên mô tả như “AWS-t3-medium-baseline”. Điều này cho phép bạn chạy lại cùng một bài kiểm tra sau sáu tháng để xem liệu hiệu suất có bị giảm sút theo thời gian hay không.
Sức mạnh của việc so sánh
Đo hiệu suất sẽ vô nghĩa nếu thực hiện trong sự cô lập. Giá trị thực sự xuất hiện khi bạn so sánh hai cấu hình khác nhau. Ví dụ, nếu bạn đang phân vân giữa một VPS chạy Intel và một instance AMD EPYC, hãy chạy bài kiểm tra apache trên cả hai để xem bên nào xử lý lưu lượng web đồng thời cao tốt hơn.
# Chạy bài kiểm tra trên cả hai máy chủ, sau đó gộp kết quả
phoronix-test-suite compare-results-to-self [tên-kết-quả-đã-lưu-của-bạn]Stress Testing để kiểm tra tính ổn định
Hiệu suất không chỉ là về tốc độ; nó còn là về độ tin cậy dưới áp lực. Tôi sử dụng bộ stress-ng để đẩy CPU và bộ nhớ lên mức tải 100% trong thời gian dài. Điều này giúp xác định các vấn đề về quá nhiệt (thermal throttling) trên máy chủ vật lý hoặc việc giới hạn tài nguyên khắt khe trên các cloud instance.
phoronix-test-suite run pts/stress-ngMẹo chuyên nghiệp để có dữ liệu chính xác
Tôi đã thấy nhiều kỹ sư nhận được kết quả sai lệch nghiêm trọng vì họ bỏ qua môi trường của máy chủ. Hãy tuân thủ các quy tắc sau để đảm bảo dữ liệu của bạn được chuẩn xác:
- Loại bỏ các tác vụ nền: Dừng các tiến trình Cron, máy chủ web và các công cụ cơ sở dữ liệu trước khi bắt đầu. Bạn muốn bài benchmark có quyền truy cập độc quyền vào phần cứng.
- Theo dõi “Hàng xóm ồn ào” (Noisy Neighbors): Trên VPS, hãy chạy
topvà nhìn vào cột%st(steal time). Nếu con số đó vượt quá 2% trong khi thử nghiệm, một người dùng khác trên cùng máy chủ vật lý đang chiếm dụng CPU. Kết quả của bạn sẽ không còn giá trị. - Chạy ba lần: PTS thường chạy các bài kiểm tra ba lần và tính toán độ lệch chuẩn. Nếu độ lệch cao hơn 5%, môi trường của bạn quá không ổn định để có một kết quả benchmark đáng tin cậy.
- Theo dõi nhiệt độ: Trên phần cứng chuyên dụng, hãy để mắt đến lệnh
sensors. Nếu CPU của bạn chạm mức 95°C và hiệu suất giảm mạnh, bạn đang gặp vấn đề về tản nhiệt chứ không phải nghẽn cổ chai do phần mềm.
Bằng cách sử dụng UnixBench để kiểm tra sức khỏe nhanh và PTS để phân tích sâu, tôi đã chứng minh được mảng lưu trữ mới của khách hàng gặp nút thắt cổ chai về độ trễ nghiêm trọng. Nhà cung cấp đã chuyển instance sang một nút phần cứng khác và thời gian phản hồi API đã giảm 60ms. Dữ liệu thực tế luôn đánh bại mọi linh cảm.
