मैं इसे FDCServers की नकारात्मक समीक्षा के रूप में नहीं लिख रहा हूँ। मेरा उद्देश्य यह बताना भी नहीं है कि किसी को उनसे VPS खरीदना चाहिए या नहीं। मेरे पास एक server, एक workload और समस्याओं की एक खास श्रृंखला थी। इससे पूरी hosting company का फैसला नहीं किया जा सकता।
यह बस developer के रूप में मेरे काम के दिनों में से एक की कहानी है। VPS कुछ समय तक सामान्य रूप से चल रहा था और 3 TB से अधिक ट्रैफिक ट्रांसफर कर चुका था। फिर सामान्य workload पर गंभीर delays आने लगे। Pages को response देने में बहुत समय लगने लगा या वे पूरी तरह timeout होने लगीं। शुरुआत में सामान्य suspects थे: application, Nginx, memory, network, connection limits या ज्यादा load। लेकिन Linux metrics किसी और दिशा में इशारा कर रहे थे।
VPS शुरुआत से धीमा नहीं था
Incidents के बीच machine पूरी तरह healthy दिख सकती थी। एक सामान्य अवधि में कोई process D-state में नहीं था, CPU iowait लगभग 0%, disk latency करीब 2–4 ms और I/O PSI लगभग zero था:
D-state processes: 0
CPU iowait: ~0%
disk latency: ~2–4 ms
I/O PSI some: 0.04
I/O PSI full: 0.04अगर मैं सिर्फ उसी समय connect करके top, free -h, df -h और systemctl status nginx देखता, तो शायद निष्कर्ष निकालता कि VPS ठीक है। फिर सामान्य workload लौटा और machine की स्थिति तेजी से बदल गई।
18.7 सेकंड की reads ने जांच की दिशा बदल दी
सबसे स्पष्ट iostat samples में से एक यह था:
r_await = 18744 ms
f_await = 53561 ms
aqu-sz = 128.54
util = 100.10%
read = 88 KB/sइन numbers को साथ पढ़ना जरूरी है। पूरी हुई reads की average latency लगभग 18.7 सेकंड थी। flush latency करीब 53.6 सेकंड थी। average I/O queue 128 से ऊपर थी, जबकि useful read throughput सिर्फ 88 KB/s था। यह केवल एक busy disk नहीं था जो बहुत data तेजी से move कर रहा हो। Storage path operations के पूरा होने का इंतजार करते हुए बहुत ज्यादा समय खर्च कर रहा था।
iowait और PSI ने system-wide I/O pressure दिखाया
सबसे खराब periods में vmstat 4–9 blocked processes, CPU iowait करीब 97–100% और CPU idle 0% दिखा रहा था। iowait का मतलब यह नहीं है कि application पूरा CPU इस्तेमाल कर रही है। इसका मतलब है कि useful work outstanding I/O के पूरा होने का इंतजार कर रहा है।
Linux Pressure Stall Information ने picture और साफ कर दी:
I/O PSI some avg10 = 99.14
I/O PSI full avg10 = 95.55बाद की reproductions में full करीब 98% तक पहुँचा। Disk utilization बताता है कि device busy है; PSI बताता है कि workload उस resource के कारण कितना stall हो रहा है। 95–98% का sustained I/O pressure कोई मामूली performance regression नहीं है।
D-state और kernel stacks ने application से नीचे की layer की ओर इशारा किया
फिर मैंने blocked processes देखे। एक ही समय पर jbd2, systemd-journald, Nginx workers, Nginx cache processes और दूसरी filesystem activity D-state में दिखाई दी। अगर सिर्फ application अटकती, तो application की जांच करता। जब Nginx, system journal और EXT4 journal साथ में block हों, तो storage सबसे स्पष्ट shared dependency बन जाता है।
EXT4 journaling paths में ये शामिल थे:
wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transactionNginx workers सामान्य file reads में इंतजार कर रहे थे:
folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64एक समय kernel ने report किया कि एक Nginx task 122 सेकंड से ज्यादा blocked था। Nginx अभी भी active दिख सकता था, लेकिन इसका मतलब यह नहीं था कि उसके workers useful work पूरा कर पा रहे थे। running और healthy अलग स्थितियाँ हैं।
3 ms के backend response ने application को filesystem path से अलग कर दिया
सबसे साफ तुलना Nginx और local application backend के बीच थी। Nginx के जरिए requests connection या TLS timeout के साथ HTTP=000 दे रही थीं। Backend को direct request करीब 3 ms में पूरा हुआ:
connect = 0.000423 s
TTFB = 0.003063 s
total = 0.003139 sइस test में exact HTTP status महत्वपूर्ण नहीं था। Backend ने connection लिया, request process किया और लगभग तुरंत response दिया। उसी समय Nginx workers EXT4 reads का इंतजार करते दिख रहे थे। इससे application execution और उसके सामने के filesystem-dependent path को अलग करना आसान हो गया।
Failure reproducible था और फिर गायब भी हो सकता था
एक reproduction से पहले machine normal थी:
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 लगातार failed रहे। यह सिर्फ यह कहने से कहीं ज्यादा उपयोगी evidence था कि VPS slow महसूस हो रहा है।
Workload हटाने के बाद उल्टा transition भी जल्दी हो सकता था:
D-state: 0
CPU iowait: 6%
r_await: ~0.98 ms
queue depth: ~0.07
HTTP: 200इसीलिए intermittent storage problems को बाद में inspect करना मुश्किल होता है। Recovery के बाद provider सचमुच normal latency देख सकता है, लेकिन वह दस मिनट पहले हुई घटना को explain नहीं करता। Exact UTC timestamps जरूरी हो गए।
दो misleading metrics: await=0 और free disk space
कुछ खराब intervals में मुझे r_await = 0 दिखा, जबकि iowait high था, processes D-state में थे, requests in-flight थीं और लगभग कोई read complete नहीं हो रही थी। Latency statistics completed I/O पर आधारित होती हैं। अगर operation sampling interval में complete नहीं होती, तो वह completed latency average में शामिल नहीं होती। इसलिए zero हमेशा instant disk नहीं बताता।
मैंने disk fullness भी जांची। बाद में filesystem मेरी सामान्य सीमा से ज्यादा भर गया था, लेकिन यही class का failure पहले तब भी आ चुका था जब root filesystem सिर्फ लगभग 24% used था। उस समय करीब 1.2 GiB RAM available थी, inode usage करीब 5% और network interface पर errors या dropped packets नहीं थे। Disk fullness पूरी घटना की व्याख्या नहीं कर सकती थी।
मैं क्या साबित कर सका और क्या नहीं
VPS के अंदर से मैं application, Linux VFS, EXT4 और virtual block device देख सकता था। उसके बाद provider infrastructure आता है: virtualization, distributed storage, storage networking, physical devices, scheduling और दूसरी layers जिन्हें guest से inspect नहीं किया जा सकता।
इसलिए मैं ईमानदारी से यह दावा नहीं कर सकता कि कोई खास physical SSD खराब था या किसी खास storage node, network path या virtualization component को root cause कह सकता हूँ।
मैं जो कह सकता हूँ वह सीमित लेकिन अच्छी तरह supported है: मेरे Linux guest को दिया गया virtual storage path बार-बार ऐसी स्थिति में गया जहाँ सामान्य filesystem I/O को पूरा होने में कई सेकंड लगे या वह reasonable समय में complete नहीं हुआ। Evidence iostat, PSI, D-state, kernel wait stacks, EXT4/jbd2 waits, Nginx filesystem waits, queue depth और request timings से मिला। Engineering diagnosis के लिए यह पर्याप्त था, physical root cause के लिए नहीं।
पहले के 3 TB से ज्यादा traffic बाद के stalls का खंडन क्यों नहीं करते
शुरुआत में यही मुझे सबसे ज्यादा उलझाता था। अगर storage में problem थी, तो VPS पहले कई terabytes successfully transfer कैसे कर पाया?
क्योंकि network traffic और physical disk I/O एक चीज नहीं हैं। कोई file backing storage से एक बार read हो सकती है, Linux page cache में रह सकती है और फिर memory से कई बार serve हो सकती है। इसलिए network से 3 TB transfer होने का मतलब 3 TB unique physical disk reads नहीं है।
Infrastructure conditions समय के साथ बदलती भी हैं: cache state, storage load, queueing, host placement और दूसरे workloads बदल सकते हैं। VPS का कल ठीक चलना आज बिल्कुल वही storage behavior guarantee नहीं करता।
आखिरकार मैंने deeper root cause का इंतजार करना बंद कर दिया
मैंने exact timestamps, vmstat, iostat, PSI, blocked-process snapshots, kernel stacks, filesystem waits, queue depths और HTTP timings जमा किए। Diagnostics FDCServers को भेजे और deeper infrastructure-level explanation का इंतजार किया।
मैंने काफी समय इंतजार किया। आखिरकार रुक गया। मेरे पास operational decision के लिए पर्याप्त जानकारी थी: problem reproducible और severe थी, application layer के नीचे दिखाई दे रही थी और physical cause मेरे VPS की visibility से बाहर था।
मैंने refund माँगा और FDCServers ने पैसे लौटा दिए
मैंने problems और collected diagnostics का summary FDCServers को भेजा, service cancel करने को कहा और refund माँगा। उन्होंने पैसे वापस कर दिए।
इसलिए कहानी पैसे के लिए लंबी लड़ाई पर खत्म नहीं होती। मैंने definitive technical explanation का इंतजार किया, फिर तय किया कि अब और नहीं इंतजार करूंगा, अपने evidence भेजे और पैसे वापस माँगे। FDCServers ने refund कर दिया।
इसके बाद मैंने क्या बदला
इस अनुभव का उपयोगी नतीजा यह तय करना नहीं था कि कोई hosting company अच्छी है या बुरी। इसने slow Linux servers को debug करने का मेरा तरीका बदल दिया।
top, free -h और df -h अभी भी उपयोग करता हूँ, लेकिन अब इन commands तक बहुत जल्दी पहुँचता हूँ:
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जहाँ संभव हो request paths को अलग-अलग test करता हूँ: public request, local Nginx, direct backend, filesystem और block-device metrics। सवाल अब सिर्फ यह नहीं है कि server slow क्यों है। सवाल है: किस layer पर useful work पूरा होना बंद हो रहा है?
जहाँ संभव हो, reboot से पहले evidence capture करता हूँ। Reboot service वापस ला सकता है, लेकिन वही D-state, PSI, queues और latency भी मिटा सकता है जिनसे intermittent incident diagnose किया जा सकता है।
अंतिम बात
मैंने FDCServers VPS इसलिए नहीं खरीदा था कि hosting article लिखने का material मिले। मुझे ज्यादा bandwidth वाला server चाहिए था। कुछ समय तक मुझे ठीक वही मिला: उसने real workload संभाला और तीन terabytes से ज्यादा transfer किया।
फिर normal workload reproducibly iowait को 100% तक, I/O PSI को लगभग 100%, reads को 18.7 सेकंड तक, flush latency को 53 सेकंड से ऊपर, बड़ी queues, filesystem reads में blocked Nginx और I/O की प्रतीक्षा करता EXT4/jbd2 पैदा करने लगा।
मैं कभी नहीं जान पाया कि कौन-सा physical या host-side component इसका कारण था, और मुझे ऐसा दिखाने की जरूरत भी नहीं कि मैं जानता हूँ। मैंने वह layer पहचानी जहाँ failure दिखाई दे रहा था, application problem से अलग करने लायक evidence जुटाया, deeper root-cause explanation का इंतजार बंद किया और पैसे वापस माँगे। FDCServers ने refund दिया।
यह हर FDCServers VPS पर verdict नहीं है। यह सिर्फ अच्छी तरह documented reminder है कि service active और process running दिख सकता है, जबकि machine अपना लगभग पूरा useful समय storage का इंतजार करते हुए बिता रही हो।