VPS FDCServers của tôi chạy ổn với hơn 3 TB lưu lượng. Sau đó, đọc đĩa bắt đầu mất 18 giây

Tôi không viết bài này như một đánh giá tiêu cực về FDCServers. Tôi cũng không cố bảo người khác có nên mua VPS của họ hay không. Tôi có một máy chủ, một workload và một chuỗi sự cố cụ thể. Chừng đó không đủ để đánh giá cả một công ty hosting.

Đây đơn giản là một câu chuyện trong công việc hằng ngày của tôi với tư cách developer. VPS đã hoạt động bình thường một thời gian và truyền hơn 3 TB lưu lượng. Sau đó, workload thông thường bắt đầu tạo ra độ trễ rất lớn. Trang có thể mất rất lâu mới phản hồi hoặc timeout hoàn toàn. Ban đầu tôi nghi ngờ những nguyên nhân quen thuộc: application, Nginx, memory, network, giới hạn connection hoặc load quá cao. Nhưng các metrics của Linux chỉ sang hướng khác.

VPS không chậm ngay từ đầu

Giữa các incident, máy có thể trông hoàn toàn khỏe mạnh. Trong một khoảng thời gian bình thường, không có process nào ở D-state, CPU iowait khoảng 0%, disk latency khoảng 2–4 ms và I/O PSI gần như bằng không:

D-state processes: 0
CPU iowait:        ~0%
disk latency:      ~2–4 ms
I/O PSI some:      0.04
I/O PSI full:      0.04

Nếu tôi chỉ kết nối vào đúng lúc đó và kiểm tra top, free -h, df -h cùng systemctl status nginx, có lẽ tôi sẽ kết luận VPS hoàn toàn bình thường. Sau đó workload thông thường quay lại và trạng thái của máy thay đổi rất mạnh.

Read mất 18,7 giây đã đổi hướng điều tra

Một trong những sample iostat rõ nhất là:

r_await = 18744 ms
f_await = 53561 ms
aqu-sz  = 128.54
util    = 100.10%
read    = 88 KB/s

Cần đọc các con số này cùng nhau. Những read đã hoàn tất có latency trung bình khoảng 18,7 giây. Flush latency khoảng 53,6 giây. Queue I/O trung bình lớn hơn 128, trong khi throughput đọc hữu ích chỉ 88 KB/s. Đây không chỉ là một disk bận vì đang chuyển nhiều dữ liệu. Storage path đang dành lượng thời gian khổng lồ để chờ operation hoàn tất.

iowait và PSI cho thấy I/O pressure trên toàn hệ thống

Trong các giai đoạn tệ nhất, vmstat cho thấy 4–9 process bị blocked, CPU iowait khoảng 97–100% và CPU idle 0%. iowait không có nghĩa application đang dùng hết CPU. Nó có nghĩa công việc hữu ích đang chờ outstanding I/O hoàn tất.

Linux Pressure Stall Information làm bức tranh rõ hơn:

I/O PSI some avg10 = 99.14
I/O PSI full avg10 = 95.55

Trong các lần reproduce sau, full tiến gần 98%. Disk utilization cho biết device đang bận; PSI cho biết workload thực sự bị resource đó làm stall đến mức nào. I/O pressure duy trì ở 95–98% không phải là một mức giảm performance nhỏ.

D-state và kernel stack chỉ xuống dưới application layer

Sau đó tôi kiểm tra process nào đang blocked. Cùng lúc, tôi thấy jbd2, systemd-journald, Nginx worker, Nginx cache process và các hoạt động filesystem khác ở D-state. Nếu chỉ application của tôi bị treo, tôi sẽ điều tra application. Khi Nginx, system journal và EXT4 journal đều block cùng lúc, storage trở thành dependency chung rõ ràng nhất.

Các path journaling của EXT4 gồm:

wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transaction

Nginx worker đang chờ trong các thao tác đọc file thông thường:

folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64

Có lúc kernel báo một Nginx task đã blocked hơn 122 giây. Nginx vẫn có thể hiển thị là active, nhưng điều đó không có nghĩa worker của nó có thể hoàn thành công việc hữu ích. running và healthy là hai trạng thái khác nhau.

Backend trả lời trong 3 ms giúp tách application khỏi filesystem path

So sánh rõ nhất là giữa Nginx và local application backend. Request qua Nginx trả về HTTP=000 vì connection hoặc TLS timeout. Request trực tiếp tới backend hoàn tất trong khoảng 3 ms:

connect = 0.000423 s
TTFB    = 0.003063 s
total   = 0.003139 s

HTTP status chính xác không quan trọng với test này. Backend nhận connection, xử lý request và tạo response gần như ngay lập tức. Cùng lúc đó, Nginx worker đang chờ EXT4 read. Điều này tách được việc application thực thi bình thường khỏi path phía trước phụ thuộc vào filesystem.

Sự cố có thể reproduce và cũng có thể biến mất trở lại

Trước một lần reproduce, máy trông bình thường:

HTTP:          200
D-state:       0
CPU iowait:    3%
r_await:       ~1.18 ms
I/O PSI full:  ~2.95%

Khoảng nửa phút sau:

D-state:       4
CPU iowait:    91%
CPU idle:      0%
I/O PSI some:  86.11%
I/O PSI full:  78.02%
r_await:       236.50 ms
HTTP:          000

Sau đó CPU iowait lên 96–100%, I/O PSI full gần 98%, HTTPS queue đạt 512 và các HTTP check vẫn thất bại. Đây là evidence hữu ích hơn nhiều so với chỉ nói VPS có vẻ chậm.

Khi tôi gỡ workload, quá trình ngược lại có thể diễn ra rất nhanh:

D-state:      0
CPU iowait:   6%
r_await:      ~0.98 ms
queue depth:  ~0.07
HTTP:         200

Đó là lý do intermittent storage problem rất khó kiểm tra sau khi sự cố đã qua. Provider có thể nhìn server sau recovery và thực sự thấy latency bình thường. Điều đó vẫn không giải thích chuyện xảy ra mười phút trước. Timestamp UTC chính xác vì thế trở nên thiết yếu.

Hai metric có thể gây hiểu lầm: await=0 và dung lượng trống

Trong một số interval xấu, tôi thấy r_await = 0 trong khi iowait cao, process ở D-state, request vẫn in-flight và gần như không có read nào hoàn tất. Latency statistics dựa trên I/O đã hoàn thành. Nếu operation vẫn mắc kẹt và không kết thúc trong sampling interval, nó không thể đóng góp vào average latency của các operation đã hoàn tất. Vì vậy zero không phải lúc nào cũng có nghĩa disk phản hồi tức thì.

Tôi cũng xem xét disk fullness. Về sau filesystem đầy hơn mức tôi thường chấp nhận, nhưng cùng kiểu failure đã xuất hiện trước đó khi root filesystem mới dùng khoảng 24%. Khi ấy còn khoảng 1,2 GiB RAM available, inode usage khoảng 5% và network interface không có error hay dropped packet. Disk fullness không thể giải thích toàn bộ incident.

Điều tôi có thể chứng minh và điều tôi không thể

Từ trong VPS, tôi có thể quan sát application, Linux VFS, EXT4 và virtual block device. Sau đó là infrastructure của provider: virtualization, distributed storage, storage network, physical device, scheduling và những layer khác mà guest không thể inspect.

Vì vậy tôi không thể thành thật tuyên bố một physical SSD cụ thể bị hỏng, hoặc chỉ ra một storage node, network path hay virtualization component cụ thể là root cause.

Điều tôi có thể nói hẹp hơn nhưng có bằng chứng vững chắc là: virtual storage path được cung cấp cho Linux guest của tôi nhiều lần rơi vào trạng thái mà filesystem I/O thông thường mất nhiều giây hoặc không hoàn tất trong khoảng thời gian hợp lý. Evidence đến từ iostat, PSI, D-state, kernel wait stack, EXT4/jbd2 waits, Nginx filesystem waits, queue depth và request timings. Chừng đó đủ cho engineering diagnosis tôi cần, nhưng không đủ để xác định physical root cause.

Vì sao hơn 3 TB lưu lượng trước đó không mâu thuẫn với stall về sau

Ban đầu điều này khiến tôi bối rối. Nếu storage có vấn đề, tại sao VPS đã chuyển được vài terabyte thành công trước đó?

Bởi network traffic không giống physical disk I/O. Một file có thể được đọc từ backing storage một lần, nằm trong Linux page cache rồi được phục vụ nhiều lần từ memory. Do đó 3 TB truyền qua network không đồng nghĩa 3 TB unique physical disk reads.

Điều kiện infrastructure cũng thay đổi theo thời gian: cache state, storage load, queueing, host placement và workload khác đều có thể thay đổi. VPS chạy bình thường hôm qua không đảm bảo storage hôm nay sẽ có behavior hoàn toàn giống vậy.

Cuối cùng tôi ngừng chờ một root cause sâu hơn

Tôi thu thập timestamp chính xác, vmstat, iostat, PSI, snapshot process bị blocked, kernel stack, filesystem waits, queue depth và HTTP timings. Tôi gửi diagnostics cho FDCServers và chờ một lời giải thích sâu hơn ở mức infrastructure.

Tôi đã chờ khá lâu. Cuối cùng tôi dừng lại. Từ phía mình, tôi đã biết đủ để đưa ra quyết định vận hành: vấn đề có thể reproduce, nghiêm trọng, hiển thị dưới application layer, còn nguyên nhân vật lý nằm ngoài visibility của VPS.

Tôi yêu cầu refund và FDCServers hoàn tiền

Tôi gửi FDCServers bản tóm tắt vấn đề cùng diagnostics đã thu thập, yêu cầu cancel service và refund. Họ đã hoàn tiền.

Vì vậy câu chuyện này không kết thúc bằng một cuộc tranh cãi dài về tiền. Tôi đã chờ một lời giải thích kỹ thuật dứt khoát, quyết định không chờ nữa, gửi evidence mình có và yêu cầu lấy lại tiền. FDCServers đã trả lại.

Điều tôi thay đổi sau đó

Kết quả hữu ích không phải là kết luận một công ty hosting tốt hay xấu. Điều thay đổi là cách tôi debug các Linux server chậm.

Tôi vẫn dùng top, free -h và df -h, nhưng giờ sẽ kiểm tra những thứ sau sớm hơn nhiều:

date -u
uptime
cat /proc/pressure/io
cat /proc/pressure/memory
cat /proc/pressure/cpu
vmstat 1 10
iostat -x 1 10
ps -eo state,pid,ppid,etime,wchan:50,comm,args | awk 'NR==1 || $1 ~ /^D/'
ss -lntp
journalctl -k --since '30 min ago' --no-pager

Khi có thể, tôi cũng test từng request path riêng: public request, local Nginx, direct backend, filesystem và block-device metrics. Câu hỏi không còn đơn giản là vì sao server chậm. Nó trở thành: ở layer nào công việc hữu ích ngừng hoàn tất?

Khi có thể, tôi thu thập evidence trước khi reboot. Reboot có thể khôi phục service, nhưng cũng có thể xóa chính D-state, PSI, queue và latency cần thiết để chẩn đoán một incident intermittent.

Suy nghĩ cuối cùng

Tôi không mua VPS FDCServers để có tư liệu viết bài về hosting. Tôi cần một server có nhiều bandwidth. Trong một thời gian, tôi nhận được đúng điều đó: nó xử lý workload thật và truyền hơn ba terabyte.

Sau đó normal workload bắt đầu lặp lại tình trạng iowait tới 100%, I/O PSI gần 100%, read tới 18,7 giây, flush latency trên 53 giây, queue lớn, Nginx blocked trong filesystem read và EXT4/jbd2 chờ I/O.

Tôi chưa bao giờ biết physical hoặc host-side component nào gây ra nó, và cũng không cần giả vờ rằng mình biết. Tôi xác định layer nơi failure biểu hiện, thu thập đủ evidence để phân biệt với application problem, ngừng chờ một root-cause explanation sâu hơn và yêu cầu lấy lại tiền. FDCServers đã hoàn tiền.

Đây không phải verdict về mọi VPS của FDCServers. Nó chỉ là một lời nhắc được ghi lại khá đầy đủ rằng service có thể trông active, process có thể trông running, nhưng machine vẫn có thể dành gần như toàn bộ thời gian hữu ích để chờ storage.