میرا VPS آن لائن تھا، پھر Linux ڈسک ریڈ کے لیے 18 سیکنڈ انتظار کرنے لگا

Debugging کی تفصیل میں جانے سے پہلے ایک بات واضح کرنا چاہتا ہوں: FDCServers کے بارے میں میرا مجموعی تاثر منفی نہیں ہے۔ یہ ایسا review نہیں جو لوگوں سے کہے کہ وہ اس provider سے دور رہیں، اور نہ ہی میں اس کی پوری infrastructure quality کا فیصلہ کر رہا ہوں۔ میرے پاس ایک VPS تھا، ایک مخصوص مدت میں، جس پر ایک غیر معمولی اور مشکل مسئلہ آیا۔

کافی عرصے تک VPS معمول کے مطابق چلتا رہا اور حقیقی production traffic سنبھالتا رہا۔ پھر کچھ بدل گیا۔ عام requests غیر معمولی حد تک وقت لینے لگیں۔ Pages پہلے آہستہ کھلتیں، پھر بعض اوقات بالکل نہیں کھلتیں۔ کچھ مواقع پر machine دوبارہ normal دکھنے لگتی، اس سے پہلے کہ میں failure کو صحیح طرح inspect کر پاتا۔

بدترین حالت میں میں نے یہ اعداد ریکارڈ کیے:

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 کے کئی آزاد interfaces بتا سکتے ہیں کہ مفید progress کہاں رک گئی ہے۔ یہ مضمون انہی clues کو follow کرنے کے بارے میں ہے، FDCServers کو اچھا یا برا provider قرار دینے کے بارے میں نہیں۔

active (running) تقریباً بے معنی ہو گیا

میں نے عام checks سے آغاز کیا:

top
free -h
df -h
systemctl status nginx

Healthy 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 اسی وقت جمع کرنا ضروری تھا جب مسئلہ موجود ہو۔

وہ iostat sample جس نے investigation کا رخ بدل دیا

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

Completed 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 تھا مگر بہت کم کام مکمل کر رہا تھا۔ High utilization اکیلا failure نہیں، لیکن اس کے ساتھ بہت زیادہ latency، بڑی queue، stalled tasks، معمولی throughput اور failing requests ہوں تو معنی بالکل بدل جاتے ہیں۔

میں نے iowait کو diagnosis سمجھنا چھوڑ دیا

blocked processes: 4–9
CPU iowait:        97–100%
CPU idle:          0%

یہ کہنا آسان ہے کہ CPU 100% وقت disk کا انتظار کر رہا تھا۔ Intuition کے طور پر یہ مفید ہے، لیکن Linux accounting زیادہ پیچیدہ ہے اور iowait disk کی direct measurement نہیں ہے۔ اس لیے میں نے اسے صرف ایک symptom سمجھا اور independent evidence تلاش کیا۔

PSI نے دکھایا کہ I/O مفید کام روک رہا تھا

cat /proc/pressure/io

ایک شدید 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 ایک ساتھ block تھے۔ میں نے jbd2، systemd-journald، Nginx workers، Nginx cache processes اور دوسری filesystem activity کو ایک ساتھ رکا دیکھا۔

اگر صرف 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_transaction

Nginx workers عام 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 دو منٹ سے زیادہ وقت تک مفید کام 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 قبول کیا، request execute کی اور تقریباً فوراً response دیا۔ تقریباً اسی وقت Nginx workers EXT4 read paths کے اندر دکھائی دے رہے تھے۔

application execution       → progressing normally
filesystem-backed web path  → not progressing normally

جتنا گہرائی میں گیا، application-level explanation اتنی ہی کم قابلِ یقین ہوئی۔

وہی 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:          000

Workload ہٹانے پر 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 فوراً complete ہوئیں؛ stuck operations کو بیان کرنے کے لیے useful completions بہت کم ہو سکتی ہیں۔

اس incident کے بعد میں latency، IOPS، throughput، queue depth، in-flight I/O، D-state، PSI اور actual request completion کو ایک ساتھ دیکھتا ہوں۔

ایک incident طویل support investigation بن گیا

پہلا شدید event اصل 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
    ↓
?

اس سوالیہ نشان کے پیچھے virtualization، host queues، storage networking، distributed storage، physical media، schedulers اور دوسری systems ہو سکتی ہیں جو guest کو نظر نہیں آتیں۔ میں دیکھ سکتا تھا کہ failure کہاں ظاہر ہو رہا تھا، 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 کے لیے بنیادی طور پر نامناسب ہو، ایک الگ بات ہے۔ ایک intermittent infrastructure problem جسے reproduce اور isolate کرنا مشکل ہو، الگ بات ہے۔ FDCServers کے ساتھ میرا تجربہ دوسری category جیسا تھا۔

Incident سے پہلے VPS معمول کے مطابق کام کرتا تھا اور حقیقی production traffic سنبھالتا تھا۔ Support نے investigate کیا اور مسئلہ حل کرنے کی کوشش کی۔ آخر میں میرے پاس اتنا evidence تھا کہ میں نے فیصلہ کیا کہ production کو اس خاص VPS پر مزید depend نہیں کرنا چاہیے۔

میں نے service cancel اور refund مانگا۔ FDCServers نے مجھے refund دے دیا۔ میری overall impression میں یہ اہم ہے۔

میں نے ان کی current infrastructure کو دوبارہ test نہیں کیا، اس لیے آج FDCServers VPS کی quality پر کچھ نہیں کہہ سکتا۔ میرے پاس یہ evidence بھی نہیں کہ میری instance کی مشکل پوری fleet کی نمائندگی کرتی تھی۔ Infrastructure مسلسل بدلتی ہے۔ میں ایک مشکل incident کو پورے provider کے بارے میں permanent judgment نہیں بناتا۔ اور یہاں میں FDCServers کی recommendation بھی نہیں کر رہا؛ صرف اپنا تجربہ بیان کر رہا ہوں۔

مجھے سب سے زیادہ Linux ہی پسند آیا

Downtime پریشان کن تھا، لیکن investigation مزے دار تھی۔ مجھے واقعی problem کی boundary تلاش کرنا اچھا لگا۔

Physical root cause identify کرنے کے لیے میرے پاس کافی visibility نہیں تھی۔ میرا اصل سوال آسان تھا: useful work کس layer پر complete ہونا بند کرتی ہے؟

Backend تقریباً تین milliseconds میں جواب دے رہا تھا۔ Nginx active دکھ رہا تھا لیکن kernel stacks اسے EXT4 reads میں waiting دکھا رہے تھے۔ vmstat blocked processes اور extreme I/O wait دکھا رہا تھا۔ PSI نے دکھایا کہ I/O stalls تقریباً پورا workload لے رہی تھیں۔ iostat نے بہت زیادہ latency اور queueing دکھائی۔ D-state نے غیر متعلق processes کو ایک ساتھ انتظار کرتے دکھایا۔ Kernel نے Nginx task کے 122 سیکنڈ سے زیادہ blocked رہنے کی report بھی دی۔

کوئی ایک metric incident حل نہیں کر سکی۔ Independent signals کے اتفاق نے کیا۔ Linux کی یہی بات مجھے پسند ہے: آپ “website کبھی کبھی نہیں کھلتی” جیسے مبہم 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 کیوں ہے؟” نہیں پوچھتا۔ میں پوچھتا ہوں: useful work کس layer پر 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 اجازت دیں تو میں پہلے UTC timestamp، PSI، vmstat، iostat، D-state، wchan، kernel messages، socket queues اور request timings محفوظ کرتا ہوں۔ اس کے بعد machine recover کرتا ہوں۔

Server چل رہا تھا، workload نہیں

میں کبھی نہیں جان سکا کہ host-side کا کون سا component incident کی آخری وجہ تھا۔ میں یہ نہیں کہہ سکتا کہ کوئی خاص SSD خراب ہوا، کسی specific storage node کو identify نہیں کر سکتا، اور virtual block device کے پیچھے کیا ہوا یہ ثابت نہیں کر سکتا۔

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 out

Application کو failing layer سے الگ کرنے اور operational decision لینے کے لیے یہی کافی تھا۔ FDCServers نے VPS refund کیا، میں آگے بڑھ گیا، اور ایک مشکل infrastructure incident کو provider پر permanent verdict نہیں بناتا۔

جو lesson میرے ساتھ رہا وہ زیادہ اہم ہے: process running ہو سکتی ہے، service active ہو سکتی ہے، VM online ہو سکتی ہے، ping کام کر سکتا ہے—پھر بھی machine تقریباً کوئی useful work complete نہ کر رہی ہو۔

Linux اس فرق کو دیکھنے کے لیے کافی evidence دیتا ہے۔ بس failure موجود رہتے ہوئے صحیح سوال پوچھنے ہوتے ہیں۔