Debugging पर आने से पहले एक बात साफ करना चाहता हूँ: FDCServers के बारे में मेरी कुल धारणा नकारात्मक नहीं है। यह किसी को उनसे दूर रहने की सलाह देने वाली review नहीं है और न ही उनकी पूरी infrastructure quality पर फैसला है। मेरे पास एक VPS था, एक खास समय में, जिसमें एक असामान्य और मुश्किल समस्या आई।
काफी समय तक VPS सामान्य रूप से काम करता रहा और real production traffic संभालता रहा। फिर कुछ बदल गया। साधारण requests में बेहिसाब समय लगने लगा। Pages पहले धीरे खुलतीं और कभी-कभी पूरी तरह खुलना बंद कर देतीं। दूसरी बार machine failure को ठीक से inspect करने से पहले फिर normal दिखने लगती थी।
सबसे खराब स्थिति में मैंने यह capture किया:
CPU iowait: 97–100%
I/O PSI full: ~95–98%
read latency: up to 18.7 seconds
flush latency: up to 53.6 seconds
I/O queue depth: 128+Nginx चल रहा था। Backend चल रहा था। VM online थी। फिर भी लगभग कोई उपयोगी काम आगे नहीं बढ़ रहा था।
Production failure परेशान करने वाला था, लेकिन debugging खुद मुझे सच में मज़ेदार लगी। Linux की यही बात मुझे पसंद है: बाहर से machine ज़िंदा दिख सकती है, जबकि kernel के कई independent interfaces शांत तरीके से बता सकते हैं कि useful progress कहाँ रुक गई है। यह लेख उन्हीं clues को follow करने के बारे में है, FDCServers को अच्छा या खराब provider घोषित करने के बारे में नहीं।
active (running) का मतलब लगभग कुछ नहीं रह गया
मैंने usual checks से शुरुआत की:
top
free -h
df -h
systemctl status nginxHealthy periods में लगभग यह दिखता था:
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 करता, तो आसानी से मान लेता कि VPS healthy है। फिर normal traffic लौटता और state पूरी तरह बदल सकती थी। Intermittent system का healthy snapshot उसके failure state के बारे में बहुत कम बताता है। Evidence failure के दौरान ही capture करना था।
वह iostat sample जिसने investigation बदल दी
r_await = 18744 ms
f_await = 53561 ms
aqu-sz = 128.54
util ≈ 100%
read = 88 KB/sCompleted reads लगभग 18.7 सेकंड ले रही थीं। Flush operations लगभग 53.6 सेकंड ले रही थीं। Average queue 128 से ऊपर थी, जबकि useful read throughput केवल 88 KB/s था।
यह ऐसा storage नहीं लग रहा था जो demanding workload को efficiently serve करने के कारण busy हो। Virtual block path लगभग saturated था, लेकिन बहुत कम useful work कर रहा था। High utilization अकेले failure नहीं है; पर huge latency, large queue, stalled tasks, tiny throughput और failing requests साथ हों तो signal बिल्कुल अलग होता है।
मैंने iowait को diagnosis मानना बंद किया
blocked processes: 4–9
CPU iowait: 97–100%
CPU idle: 0%इसे यह कहकर simplify करना आसान है कि CPU 100% समय disk का इंतज़ार कर रहा था। Intuition के रूप में यह उपयोगी है, लेकिन Linux accounting ज्यादा complex है और iowait disk का direct measurement नहीं है। इसलिए मैंने इसे सिर्फ एक symptom माना और independent evidence ढूँढा।
PSI ने दिखाया कि I/O useful work रोक रहा था
cat /proc/pressure/ioएक severe period में:
some avg10=99.14
full avg10=95.55बाद की reproductions में full लगभग 98% तक पहुँचा। I/O pressure में some वह समय बताता है जब कम से कम कुछ non-idle work I/O पर stalled हो, जबकि full वह समय बताता है जब सभी non-idle tasks एक साथ I/O पर stalled हों। 100% के पास value सिर्फ “disk busy है” नहीं कहती; workload को progress करने का मौका लगभग नहीं मिल रहा था।
D-state ने एक process को दोष देना बंद कराया
ps -eo state,pid,ppid,etime,wchan:50,comm,args | awk 'NR==1 || $1 ~ /^D/'एक process थोड़ी देर D-state में दिखे तो उससे storage problem साबित नहीं होती। महत्वपूर्ण यह था कि कौन-कौन से processes साथ में blocked थे। मैंने jbd2, systemd-journald, Nginx workers, Nginx cache processes और दूसरी filesystem activity को एक साथ blocked देखा।
अगर सिर्फ backend अटकता है तो मैं backend देखता हूँ। सिर्फ Nginx अटकता है तो Nginx देखता हूँ। लेकिन Nginx, system journal और EXT4 journal thread एक साथ progress करना बंद करें तो उनकी shared dependency ज्यादा महत्वपूर्ण हो जाती है। यहाँ वह dependency filesystem और उसके नीचे का storage path था।
Kernel stacks ने अगली layer दिखाई
EXT4 journal thread इन paths में दिखा:
wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transactionNginx workers ordinary filesystem-read paths में दिखे:
folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64एक समय kernel ने report किया:
INFO: task nginx blocked for more than 122 seconds.systemctl status nginx फिर भी active (running) दिखा सकता था। दोनों बातें सही थीं: process मौजूद था, लेकिन Nginx task दो मिनट से ज्यादा समय तक useful work complete नहीं कर पाया था। Running process और healthy service एक ही चीज़ नहीं हैं।
सबसे साफ experiment लगभग तीन milliseconds का था
Nginx के जरिए request fail हुई:
HTTP=000
SSL connection timeoutफिर मैंने Nginx bypass करके local backend को direct call किया:
connect = 0.000423 s
TTFB = 0.003063 s
total = 0.003139 sलगभग 3 ms। Exact HTTP status इस test के लिए महत्वपूर्ण नहीं था। Backend ने connection accept किया, request execute की और लगभग तुरंत response दिया। लगभग उसी समय Nginx workers EXT4 read paths में दिखाई दे रहे थे।
application execution → progressing normally
filesystem-backed web path → not progressing normallyजितना अंदर गया, application-level explanation उतना कम plausible लगा।
वही VPS लगभग 30 सेकंड में collapse कर सकता था
एक reproduction से पहले:
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: 000Workload हटाते ही reverse transition जल्दी हो सकता था:
D-state: 0
CPU iowait: 6%
r_await: ~0.98 ms
queue depth: ~0.07
HTTP: 200इसीलिए intermittent infrastructure failures इतने कठिन होते हैं। दस मिनट बाद कोई उसी VM पर sub-millisecond latency देखकर बिल्कुल सही हो सकता है; वह बस दूसरा state देख रहा है।
Zero latency कभी-कभी बेहद कम उपयोगी होती है
मैंने एक iostat interval में r_await = 0 भी देखा, जबकि system साफ तौर पर unhealthy था: high iowait, D-state processes, outstanding I/O, लगभग कोई completed read नहीं और लगभग zero throughput।
Completed operations पर आधारित averages तब कम informative हो जाते हैं जब sampling interval में लगभग कुछ complete ही न हो। Zero यह साबित नहीं करता कि reads instantly complete हुईं; stuck operations को describe करने के लिए useful completions बहुत कम हो सकती हैं।
इस incident के बाद मैं latency, IOPS, throughput, queue depth, in-flight I/O, D-state, PSI और actual request completion को साथ देखता हूँ।
एक incident लंबी support investigation बन गया
पहला severe event original infrastructure पर scheduled backup के साथ overlap हुआ और FDCServers ने confirm किया कि backup चल रहा था। यह एक reasonable candidate explanation था। लेकिन backup खत्म होने और original backup window के बाहर मैंने वही class का storage stall फिर reproduce किया।
समस्या कई दिनों में वापस आई। एक incident में service logs के मुताबिक VPS बाद में 4 घंटे, 41 मिनट और 15 सेकंड unavailable रहा। मैं यह साबित नहीं कर सकता कि storage stall ने ही VM को उस state में पहुँचाया; इसके लिए host-side information चाहिए थी जो मेरे पास नहीं थी।
application
↓
Linux VFS
↓
EXT4
↓
virtual block device
↓
?उस question mark के पीछे virtualization, host queues, storage networking, distributed storage, physical media, schedulers और guest से invisible दूसरी systems हो सकती हैं। मैं failure कहाँ manifest हो रहा था यह देख सकता था, physical root cause नहीं।
FDCServers ने issue internally escalate किया और VPS को दूसरे node पर migrate किया। Migration के बाद भी मैंने guest side से एक और severe storage stall capture किया। इससे यह साबित नहीं होता कि हर FDCServers node में storage problem थी; सिर्फ इतना कि मेरी नज़र में मेरे VPS की समस्या खत्म नहीं हुई थी।
मैं इसे फिर भी FDCServers के खिलाफ कहानी क्यों नहीं मानता
Infrastructure incident को पूरे provider पर verdict में बदलना आसान है। मैं ऐसा नहीं करना चाहता।
एक service जिसका normal operating model मेरे workload के लिए fundamentally unsuitable हो, वह अलग बात है। एक intermittent infrastructure problem जिसे reproduce और isolate करना मुश्किल हो, वह अलग बात है। FDCServers के साथ मेरा अनुभव दूसरे case जैसा लगा।
Incident से पहले VPS सामान्य रूप से काम करता था और real production traffic संभालता था। Support ने investigate किया और problem solve करने की कोशिश की। आखिरकार मेरे पास इतना evidence था कि मैंने उस particular VPS पर production निर्भर न रखने का निर्णय लिया।
मैंने service cancel और refund माँगा। FDCServers ने मुझे refund दिया। मेरी overall impression में यह महत्वपूर्ण है।
मैंने उनकी current infrastructure को फिर test नहीं किया, इसलिए आज FDCServers VPS कैसे behave करता है यह नहीं कह सकता। मेरे पास यह evidence भी नहीं कि मेरी instance की समस्या पूरी fleet को represent करती थी। Infrastructure लगातार बदलती है। मैं एक मुश्किल incident को पूरे provider पर permanent judgment नहीं बनाऊँगा। यहाँ मैं FDCServers recommend भी नहीं कर रहा; केवल अपना experience बता रहा हूँ।
मुझे सबसे ज्यादा Linux ही पसंद आया
Downtime frustrating था, लेकिन investigation मज़ेदार थी। Problem की boundary ढूँढना मुझे सच में पसंद आया।
Physical root cause identify करने के लिए मेरे पास enough visibility नहीं थी। मेरा असली सवाल सरल था: useful work किस layer पर रुक रहा है?
Backend लगभग तीन milliseconds में respond कर रहा था। Nginx active दिख रहा था, लेकिन kernel stacks उसे EXT4 reads में waiting दिखा रहे थे। vmstat blocked processes और extreme I/O wait दिखा रहा था। PSI ने लगभग पूरा workload I/O stalls में जाते दिखाया। iostat ने huge latency और queueing दिखाए। D-state ने unrelated processes को साथ में waiting दिखाया। Kernel ने Nginx task के 122 सेकंड से ज्यादा blocked रहने की report भी की।
कोई single metric incident solve नहीं कर पाया। सभी signals का agreement कर पाया। Linux की यही बात मुझे पसंद है: “website कभी-कभी नहीं खुलती” जैसे vague symptom से धीरे-धीरे उस exact layer तक पहुँचा जा सकता है जहाँ useful work आगे बढ़ना बंद करता है।
अब मैं जो debugging workflow इस्तेमाल करता हूँ
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जहाँ संभव हो, request path के हर हिस्से को independently test करता हूँ:
public request
↓
reverse proxy
↓
direct backend
↓
filesystem
↓
block deviceअब मैं केवल “server slow क्यों है?” नहीं पूछता। मैं पूछता हूँ: किस layer पर useful work complete होना बंद करता है? यह सवाल कहीं बेहतर experiments देता है।
एक आखिरी नियम: reboot से पहले evidence जमा करें
Reboot production को ठीक करने के लिए बिल्कुल सही कदम हो सकता है, लेकिन वह सबसे valuable diagnostic state को मिटा भी सकता है।
Before reboot:
D-state: high
I/O PSI: ~97%
iowait: ~100%
queues: large
requests: failing
After reboot:
D-state: 0
latency: milliseconds
requests: healthyजब availability और business impact allow करें, मैं पहले UTC timestamp, PSI, vmstat, iostat, D-state, wchan, kernel messages, socket queues और request timings capture करता हूँ। उसके बाद machine recover करता हूँ।
Server चल रहा था। Workload नहीं।
मैं कभी नहीं जान पाया कि host-side का कौन-सा component अंततः incident का कारण था। मैं यह नहीं कह सकता कि कोई खास SSD fail हुआ, किसी specific storage node को identify नहीं कर सकता और virtual block device के पीछे क्या हुआ यह prove नहीं कर सकता।
Linux के अंदर से जो establish कर पाया, वह पर्याप्त था:
read latency: up to 18.7 s
flush latency: up to 53.6 s
I/O PSI full: almost 100%
iowait: almost 100%
I/O queue: 128+
Nginx: blocked in filesystem reads
EXT4/jbd2: blocked waiting for I/O
direct backend: ~3 ms
HTTP through Nginx: timing outApplication को failing layer से अलग करने और operational decision लेने के लिए यही काफी था। FDCServers ने VPS का refund दिया, मैं आगे बढ़ गया, और एक मुश्किल infrastructure incident को provider पर permanent verdict नहीं बनाता।
जो lesson मेरे साथ रहा वह ज्यादा उपयोगी है: process running हो सकता है, service active हो सकती है, VM online हो सकती है, ping काम कर सकता है—फिर भी machine लगभग कोई useful work पूरा नहीं कर रही हो सकती है।
Linux इस फर्क को देखने के लिए पर्याप्त evidence देता है। बस failure मौजूद रहते समय सही सवाल पूछने होते हैं।