VPS ของ FDCServers ของผมทำงานปกติหลังรับทราฟฟิกเกิน 3 TB ก่อนที่การอ่านดิสก์จะเริ่มใช้เวลา 18 วินาที

ผมไม่ได้เขียนเรื่องนี้เพื่อเป็นรีวิวเชิงลบของ FDCServers และไม่ได้พยายามบอกใครว่าควรหรือไม่ควรซื้อ VPS จากที่นี่ ผมมีเซิร์ฟเวอร์หนึ่งเครื่อง workload หนึ่งแบบ และเหตุการณ์ปัญหาหนึ่งชุด ข้อมูลเท่านี้ไม่เพียงพอที่จะตัดสินบริษัทโฮสติ้งทั้งบริษัท

นี่เป็นเพียงเหตุการณ์หนึ่งในชีวิตประจำวันของผมในฐานะนักพัฒนา VPS ทำงานปกติมาระยะหนึ่งและถ่ายโอนทราฟฟิกไปแล้วมากกว่า 3 TB จากนั้น workload ตามปกติเริ่มทำให้เกิดความล่าช้าอย่างรุนแรง หน้าเว็บบางครั้งใช้เวลานานมากกว่าจะตอบ หรือ timeout ไปเลย ตอนแรกผมสงสัยสิ่งที่มักเป็นต้นเหตุ เช่น application, Nginx, memory, network, connection limit หรือ load ที่สูงเกินไป แต่ metrics ของ Linux ชี้ไปอีกทางหนึ่ง

VPS ไม่ได้ช้าตั้งแต่แรก

ระหว่างแต่ละ incident เครื่องสามารถดูปกติดีทุกอย่างได้ ในช่วงหนึ่งไม่มี process อยู่ใน D-state, CPU iowait อยู่ราว 0%, disk latency ประมาณ 2–4 ms และ I/O PSI แทบเป็นศูนย์:

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

ถ้าผมเข้ามาดูเฉพาะตอนนั้น แล้วเช็ก top, free -h, df -h และ systemctl status nginx ผมน่าจะสรุปว่า VPS ปกติดี จากนั้น workload ตามปกติกลับมา และสถานะของเครื่องก็เปลี่ยนไปอย่างมาก

การอ่านที่ใช้เวลา 18.7 วินาทีเปลี่ยนทิศทางการตรวจสอบ

หนึ่งใน sample ของ iostat ที่ชัดที่สุดคือ:

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

ตัวเลขเหล่านี้ต้องดูร่วมกัน read ที่เสร็จแล้วมี latency เฉลี่ยประมาณ 18.7 วินาที flush latency อยู่ที่ประมาณ 53.6 วินาที ค่าเฉลี่ย I/O queue สูงกว่า 128 แต่ throughput การอ่านที่ใช้งานได้จริงมีเพียง 88 KB/s นี่ไม่ใช่แค่ disk ที่ busy เพราะกำลังขนข้อมูลจำนวนมาก แต่เป็น storage path ที่เสียเวลาอย่างมหาศาลไปกับการรอให้ operation เสร็จ

iowait และ PSI แสดง I/O pressure ทั้งระบบ

ในช่วงที่แย่ที่สุด vmstat แสดง process ที่ blocked 4–9 ตัว, CPU iowait ราว 97–100% และ CPU idle 0% ค่า iowait ไม่ได้แปลว่า application ใช้ CPU ทั้งหมด แต่หมายถึงงานที่ควรทำกำลังรอ outstanding I/O ให้เสร็จ

Linux Pressure Stall Information ทำให้ภาพชัดขึ้นอีก:

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

ในการ reproduce ครั้งหลัง ๆ ค่า full เข้าใกล้ 98% Disk utilization บอกว่า device กำลัง busy ส่วน PSI บอกว่า workload ถูก resource นั้นทำให้ stall หนักแค่ไหน I/O pressure ที่ค้างอยู่แถว 95–98% ไม่ใช่ performance regression เล็กน้อย

D-state และ kernel stack ชี้ลงไปต่ำกว่า application

ผมตรวจต่อว่า process ใดกำลัง blocked ในเวลาเดียวกันพบ jbd2, systemd-journald, Nginx worker, Nginx cache process และ filesystem activity อื่น ๆ อยู่ใน D-state ถ้ามีเพียง application ของผมที่ค้าง ผมก็จะตรวจ application แต่เมื่อ Nginx, system journal และ EXT4 journal ค้างพร้อมกัน storage กลายเป็น dependency ร่วมที่ชัดที่สุด

เส้นทาง journaling ของ EXT4 มี:

wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transaction

Nginx worker กำลังรออยู่ในเส้นทางอ่านไฟล์ปกติ:

folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64

ครั้งหนึ่ง kernel รายงานว่า task ของ Nginx ถูก block นานกว่า 122 วินาที แม้ Nginx ยังสามารถแสดงสถานะเป็น active ได้ แต่นั่นไม่ได้หมายความว่า worker ของมันทำงานที่มีประโยชน์จนเสร็จได้ สถานะ running กับ healthy ไม่ใช่สิ่งเดียวกัน

Backend ตอบใน 3 ms ช่วยแยก application ออกจาก filesystem path

การเปรียบเทียบที่ชัดที่สุดคือ Nginx กับ local application backend Request ผ่าน Nginx ได้ HTTP=000 จาก connection หรือ TLS timeout แต่ request ตรงไปยัง backend เสร็จในประมาณ 3 ms:

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

HTTP status ที่แน่นอนไม่สำคัญสำหรับ test นี้ Backend รับ connection ประมวลผล request และสร้าง response แทบจะทันที ในเวลาเดียวกัน Nginx worker กำลังรอ EXT4 read อยู่ จึงสามารถแยกการทำงานตามปกติของ application ออกจาก path ด้านหน้าที่พึ่งพา filesystem ได้

ปัญหา reproduce ได้ และก็หายไปอีกได้เช่นกัน

ก่อน reproduce ครั้งหนึ่ง เครื่องดูปกติ:

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

ประมาณครึ่งนาทีต่อมา:

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

ต่อมา CPU iowait ขึ้นถึง 96–100%, I/O PSI full ใกล้ 98%, HTTPS queue ถึง 512 และ HTTP checks ยังล้มเหลว นี่เป็นหลักฐานที่มีประโยชน์กว่าการบอกเพียงว่า VPS รู้สึกช้า

เมื่อผมเอา workload ออก การเปลี่ยนกลับก็เกิดขึ้นเร็วได้:

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

นี่คือเหตุผลที่ intermittent storage problem ตรวจย้อนหลังยาก Provider อาจมาดูหลัง recovery แล้วเห็น latency ปกติจริง ๆ แต่นั่นไม่ได้อธิบายสิ่งที่เกิดขึ้นเมื่อสิบนาทีก่อน Timestamp แบบ UTC ที่แม่นยำจึงสำคัญมาก

สอง metric ที่ทำให้เข้าใจผิดได้: await=0 และพื้นที่ว่างบนดิสก์

ในบางช่วงที่แย่ ผมเห็น r_await = 0 ขณะที่ iowait สูง, process อยู่ใน D-state, request ยังคง in-flight และแทบไม่มี read ใดเสร็จ Latency statistics อิงจาก I/O ที่เสร็จแล้ว หาก operation ค้างและไม่เสร็จใน sampling interval มันก็ไม่สามารถเข้าไปอยู่ในค่าเฉลี่ย latency ของ operation ที่เสร็จแล้วได้ ดังนั้นค่า zero ไม่ได้หมายถึง disk ที่ตอบทันทีเสมอไป

ผมพิจารณา disk fullness ด้วย ต่อมา filesystem เต็มกว่าระดับที่ผมปกติจะยอมให้เป็น แต่ failure แบบเดียวกันเกิดขึ้นไปแล้วตอนที่ root filesystem ใช้พื้นที่เพียงประมาณ 24% ตอนนั้นมี RAM available ราว 1.2 GiB, inode usage ราว 5% และ network interface ไม่มี error หรือ dropped packet ดังนั้น disk fullness อธิบาย incident ทั้งหมดไม่ได้

สิ่งที่ผมพิสูจน์ได้ และสิ่งที่พิสูจน์ไม่ได้

จากภายใน VPS ผมมองเห็น application, Linux VFS, EXT4 และ virtual block device หลังจากนั้นเป็น infrastructure ของ provider ทั้ง virtualization, distributed storage, storage network, physical device, scheduling และ layer อื่นที่ guest มองไม่เห็น

ดังนั้นผมจึงอ้างอย่างตรงไปตรงมาไม่ได้ว่า physical SSD ตัวใดตัวหนึ่งเสีย หรือชี้ว่า storage node, network path หรือ virtualization component ใดเป็น root cause

สิ่งที่ผมพูดได้มีขอบเขตแคบกว่าแต่มีหลักฐานชัด: virtual storage path ที่ส่งให้ Linux guest ของผมเข้าสู่สถานะซ้ำ ๆ ซึ่ง filesystem I/O ปกติใช้เวลาหลายวินาที หรือไม่เสร็จภายในเวลาที่สมเหตุสมผล หลักฐานมาจาก iostat, PSI, D-state, kernel wait stack, EXT4/jbd2 waits, Nginx filesystem waits, queue depth และ request timings ซึ่งเพียงพอสำหรับ engineering diagnosis ที่ผมต้องการ แต่ไม่พอระบุ physical root cause

ทำไมทราฟฟิกกว่า 3 TB ก่อนหน้านั้นไม่ขัดกับ stall ที่เกิดทีหลัง

ตอนแรกเรื่องนี้ทำให้ผมสับสน ถ้า storage มีปัญหา แล้ว VPS ส่งข้อมูลหลาย terabyte สำเร็จก่อนหน้านี้ได้อย่างไร?

เพราะ network traffic ไม่ใช่สิ่งเดียวกับ physical disk I/O ไฟล์หนึ่งอาจถูกอ่านจาก backing storage หนึ่งครั้ง แล้วค้างอยู่ใน Linux page cache ก่อนถูกส่งจาก memory อีกหลายครั้ง ดังนั้นทราฟฟิก 3 TB ผ่าน network ไม่ได้หมายถึง unique physical disk reads 3 TB

สภาพ infrastructure ยังเปลี่ยนตามเวลาได้ ทั้ง cache state, storage load, queueing, host placement และ workload อื่น VPS ที่ทำงานปกติเมื่อวานไม่ได้รับประกันว่า storage จะมี behavior เหมือนเดิมในวันนี้

ท้ายที่สุดผมหยุดรอ root cause ที่ลึกกว่านี้

ผมเก็บ timestamp ที่แม่นยำ, vmstat, iostat, PSI, snapshot ของ blocked process, kernel stack, filesystem waits, queue depth และ HTTP timings แล้วส่ง diagnostics ให้ FDCServers พร้อมรอคำอธิบายระดับ infrastructure ที่ลึกกว่านั้น

ผมรอนานมาก แล้วสุดท้ายก็หยุดรอ จากฝั่งของผมมีข้อมูลเพียงพอสำหรับตัดสินใจเชิง operation แล้ว: ปัญหา reproduce ได้ รุนแรง มองเห็นได้ต่ำกว่า application layer และ physical cause อยู่นอก visibility ของ VPS

ผมขอ refund และ FDCServers คืนเงินให้

ผมส่งสรุปปัญหาและ diagnostics ที่เก็บไว้ให้ FDCServers ขอ cancel service และขอ refund พวกเขาคืนเงินให้

ดังนั้นเรื่องนี้ไม่ได้จบด้วยการต่อสู้ยาวเรื่องเงิน ผมรอคำอธิบายทางเทคนิคที่ชัดเจน ตัดสินใจว่าไม่อยากรออีก ส่ง evidence ที่มี และขอเงินคืน FDCServers คืนให้

สิ่งที่ผมเปลี่ยนหลังจากนั้น

ผลลัพธ์ที่มีประโยชน์ไม่ใช่การตัดสินว่าบริษัท hosting ดีหรือไม่ดี แต่คือวิธีที่ผม debug Linux server ที่ช้าเปลี่ยนไป

ผมยังใช้ top, free -h และ df -h แต่ตอนนี้จะไปดูสิ่งเหล่านี้เร็วกว่าก่อนมาก:

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

เมื่อทำได้ ผมแยก test ตาม request path ด้วย: public request, local Nginx, direct backend, filesystem และ block-device metrics คำถามจึงไม่ใช่แค่ว่าทำไม server ช้า แต่เป็น งานที่มีประโยชน์หยุดเสร็จที่ layer ไหน?

เมื่อเป็นไปได้ ผมจะเก็บ evidence ก่อน reboot เพราะ reboot อาจทำให้ service กลับมา แต่ก็อาจลบ D-state, PSI, queue และ latency ที่ทำให้ intermittent incident วินิจฉัยได้ออกไปด้วย

ข้อคิดสุดท้าย

ผมไม่ได้ซื้อ FDCServers VPS เพราะอยากได้เรื่องไปเขียนบทความ hosting ผมต้องการ server ที่มี bandwidth เยอะ และช่วงหนึ่งผมก็ได้สิ่งนั้นจริง ๆ มันรับ workload จริงและถ่ายโอนข้อมูลมากกว่า 3 TB

จากนั้น workload ปกติเริ่มทำให้เกิดซ้ำได้ทั้ง iowait สูงถึง 100%, I/O PSI เกือบ 100%, read สูงถึง 18.7 วินาที, flush latency เกิน 53 วินาที, queue ขนาดใหญ่, Nginx blocked อยู่ใน filesystem read และ EXT4/jbd2 รอ I/O

ผมไม่เคยรู้ว่า physical หรือ host-side component ตัวไหนเป็นสาเหตุ และผมไม่จำเป็นต้องแกล้งทำเป็นรู้ ผมระบุ layer ที่ failure ปรากฏ เก็บ evidence มากพอจะแยกออกจากปัญหา application หยุดรอคำอธิบาย root cause ที่ลึกกว่านี้ และขอเงินคืน FDCServers คืนเงินให้

นี่ไม่ใช่คำตัดสินต่อ VPS ทุกเครื่องของ FDCServers แต่เป็นตัวอย่างที่บันทึกไว้อย่างชัดเจนว่า service สามารถดูเป็น active, process ดูเป็น running แต่เครื่องกลับใช้เวลาแทบทั้งหมดที่ควรทำงานไปกับการรอ storage ได้