Tôi không viết bài này như một đánh giá tiêu cực về AVA Hosting.
Đây chỉ là một ngày làm việc bình thường của tôi với tư cách developer: server hoạt động bất thường, những lời giải thích hiển nhiên không phù hợp, và cuối cùng Linux cho tôi thấy điều gì thực sự đang xảy ra.
Tôi có một VPS KVM nhỏ tại AVA Hosting với:
1 vCPU
2 GB RAM
25 GB NVMeNó chạy một workload production bình thường. Nginx vẫn hoạt động. Backend vẫn hoạt động. Bộ nhớ còn trống. Disk chưa đầy.
Nhưng server không theo kịp tải.
Vì vậy tôi thực hiện một phép quan sát thụ động trong 60 giây dưới lưu lượng production bình thường. Không stress test, không HTTP flood nhân tạo và không benchmark disk.
Kết quả:
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11Con số quyết định là 32,73% CPU steal. Từ đó, hướng chẩn đoán thay đổi hoàn toàn.
Vì sao điều này khiến tôi bất ngờ
AVA Hosting hiện quảng cáo VPS bằng câu “Guaranteed resources — no sharing”. Các trang VPS cũng mô tả phân bổ vCPU là fixed hoặc dedicated và nói rằng hiệu năng không nên bị ảnh hưởng bởi khách hàng khác. Trong tài liệu Linux VPS, AVA còn đi xa hơn: workload CPU-intensive của một tenant khác trên cùng host không thể tạo steal time cho instance của bạn. Một trang khác nói CPU steal được loại bỏ ở tầng hypervisor.
Đó là những tuyên bố rất cụ thể. Đây không chỉ là một trang VPS ghi 1 vCPU nhưng bỏ ngỏ cách phân bổ CPU. AVA trực tiếp quảng cáo khả năng bảo vệ trước đúng loại CPU contention mà Linux dường như đang báo cáo bên trong VM của tôi.
CPU steal nghĩa là gì
steal là một metric CPU bình thường của Linux trong môi trường ảo hóa. Nó biểu thị khoảng thời gian guest có công việc runnable nhưng virtual CPU thực tế không được chạy.
Điều này khác với việc ứng dụng của tôi đơn giản sử dụng hết CPU. Nếu tôi thấy khoảng 100% user/system, 0% steal và 0% idle, tôi sẽ kết luận workload chỉ cần thêm sức mạnh xử lý.
Nhưng ở đây, khoảng một phần ba CPU accounting là steal.
Từ bên trong guest, tôi không thể nhìn thấy hypervisor của AVA. Tôi không biết tải của physical node, số lượng VM lân cận, chính sách CPU pinning hay tỷ lệ overcommit. Điều tôi có thể thấy là Linux báo gì cho VM: vCPU nhiều lần không được chạy trong khi vẫn có công việc đang chờ.
Đây không phải spike trong một giây
Một sample CPU xấu duy nhất sẽ không đủ thuyết phục. Vì vậy tôi đo liên tục trong 60 giây. Tôi chủ động không chạy stress test, HTTP flood nhân tạo hay disk benchmark.
Các sample theo từng giây liên tục có dạng:
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00Gần cuối thời gian quan sát, pattern vẫn còn:
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00Trung bình toàn bộ:
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%Vì vậy đây không phải một scheduling anomaly ngắn. Trong phần lớn một phút, steal duy trì khoảng 30% hoặc cao hơn trong khi CPU idle vẫn bằng 0.
Để dễ hình dung, 32,73% của một phút tương đương khoảng 19,64 giây. Điều đó không có nghĩa VPS đóng băng liên tục 19,64 giây; những khoảng nhỏ mà vCPU không được schedule cộng lại xấp xỉ lượng thời gian đó.
Backend không thể bắt kịp
Vấn đề CPU cũng xuất hiện ở tầng ứng dụng. Trước khi quan sát, listen queue của backend là:
Recv-Q: 168
Send-Q: 511Sau 60 giây:
Recv-Q: 166
Send-Q: 511Con số chính xác không phải điều quan trọng. Điểm đáng chú ý là queue gần như không giảm. Ứng dụng có trọn một phút để bắt kịp nhưng vẫn tụt lại phía sau.
Cũng có nhiều connection ở trạng thái CLOSE-WAIT. Tôi không quy riêng trạng thái này cho host vì connection handling phía ứng dụng cũng có thể gây ra nó. Nhưng bức tranh tổng thể nhất quán:
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingServer vẫn sống, nhưng không khỏe.
RAM và disk không phải bottleneck rõ ràng
Tôi kiểm tra các nguyên nhân thông thường. Memory:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBVẫn còn lượng bộ nhớ đáng kể và không có OOM event rõ ràng nào giải thích được hành vi này.
Filesystem:
24 GB total
14 GB used
9.4 GB available
60% usedCPU I/O wait trung bình là 0.00%. Trong khi đó CPU pressure duy trì gần 99%, load average khoảng 3,5–4 trên VM một vCPU và runnable queue đạt 11.
Mọi phép đo đều chỉ về cùng một hướng: máy bị thiếu CPU time, chứ không rõ ràng bị chặn bởi RAM hay storage.
Mâu thuẫn với cách AVA mô tả dịch vụ
Đây là phần tôi thấy thú vị nhất.
AVA nói “Guaranteed resources — no sharing”. Họ nói hiệu năng không nên bị ảnh hưởng bởi khách hàng khác. Tài liệu Linux VPS nói tenant khác không thể gây steal time, và một trang khác nói CPU steal được loại bỏ tại hypervisor.
VPS AVA của tôi lại cho thấy:
Average CPU steal: 32.73%Từ bên trong VM, tôi không thể chứng minh chính xác vì sao điều đó xảy ra. Tôi không thể chứng minh có intentional overselling, xác định một workload lân cận cụ thể hay tái dựng cấu hình CPU phía host của AVA.
Tôi cũng không nói mọi VPS của AVA Hosting đều hành xử như vậy. Tôi đã test một VPS.
Nhưng tôi có thể nói rằng hành vi tôi đo được rất khó dung hòa với những tuyên bố cụ thể về CPU isolation đó. Với bài viết này, thế là đủ.
Vì sao tôi không upgrade
Phản ứng hiển nhiên là mua thêm vCPU.
Nếu VPS gần như không có steal và ứng dụng của tôi chỉ đơn giản sử dụng hết một core, upgrade sẽ hợp lý. Nhưng khoảng một phần ba CPU accounting mà tôi quan sát là steal.
Tôi không muốn trả tiền cho thêm virtual CPU trước khi hiểu vì sao một phần lớn execution time của vCPU đầu tiên đã bị báo là unavailable. Vì vậy tôi hủy VPS và yêu cầu refund.
AVA hoàn lại toàn bộ tiền rất nhanh
Phần này của trải nghiệm là tích cực.
AVA Hosting hoàn lại toàn bộ số tiền. Refund được xử lý nhanh và họ không mất nhiều ngày tranh luận với tôi về các phép đo CPU. Tôi giải thích vấn đề, yêu cầu hoàn tiền và họ đã hoàn lại.
Tôi đánh giá cao điều đó.
Vì vậy từ trải nghiệm của tôi có hai kết luận riêng biệt: VPS tôi nhận được có vấn đề nghiêm trọng về khả năng tiếp cận CPU, và AVA xử lý refund của tôi đúng cách. Cả hai đều đúng.
Điều tôi rút ra
Tôi không còn đánh giá VPS chỉ bằng thông số kiểu 1 vCPU / 2 GB RAM / NVMe / KVM. Những con số đó cho biết thứ gì đã được provision, nhưng không cho biết CPU sẽ khả dụng ổn định đến đâu dưới workload thực tế.
Hiện giờ, một trong những việc đầu tiên tôi kiểm tra trên VM mới là:
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60Bài học hữu ích nhất từ trải nghiệm với AVA Hosting không phải là một vCPU luôn quá ít. Mà là một process đang chạy, RAM còn trống và disk nhìn có vẻ khỏe vẫn có thể che giấu một vấn đề hoàn toàn khác bên dưới.
Trong trường hợp của tôi, Linux thể hiện điều đó rất rõ:
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting quảng cáo tài nguyên CPU không chia sẻ và nói workload lân cận không nên gây steal. VPS của tôi báo cáo điều khác.
Tôi hủy nó. AVA hoàn lại toàn bộ tiền nhanh chóng và không tranh cãi.
Và ngày debugging này kết thúc ở đó.