میرا FDCServers VPS 3 TB سے زیادہ ٹریفک تک ٹھیک چلتا رہا، پھر ڈسک پڑھنے میں 18 سیکنڈ لگنے لگے

میں یہ FDCServers کا منفی جائزہ لکھنے کے لیے نہیں لکھ رہا۔ میرا مقصد یہ بتانا بھی نہیں کہ کسی کو ان سے VPS خریدنا چاہیے یا نہیں۔ میرے پاس ایک server، ایک workload اور مسائل کا ایک مخصوص سلسلہ تھا۔ اتنی معلومات پوری hosting company کے بارے میں فیصلہ کرنے کے لیے کافی نہیں ہیں۔

یہ بس ایک developer کے طور پر میرے روزمرہ کام کا ایک واقعہ ہے۔ VPS کچھ عرصے تک معمول کے مطابق چلتا رہا اور 3 TB سے زیادہ ٹریفک منتقل کر چکا تھا۔ پھر عام workload پر شدید تاخیر شروع ہو گئی۔ صفحات کو جواب دینے میں بہت وقت لگنے لگا یا وہ مکمل طور پر 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 تقریباً صفر تھا:

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 سیکنڈ کے read نے investigation کی سمت بدل دی

سب سے نمایاں iostat samples میں سے ایک یہ تھا:

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

ان اعداد کو ایک ساتھ دیکھنا ضروری ہے۔ مکمل ہونے والے reads کی اوسط latency تقریباً 18.7 سیکنڈ تھی۔ flush latency تقریباً 53.6 سیکنڈ تھی۔ اوسط I/O queue 128 سے زیادہ تھی، جبکہ مفید read throughput صرف 88 KB/s تھا۔ یہ صرف کوئی busy disk نہیں تھا جو بہت سا data منتقل کر رہا ہو۔ Storage path operations کے مکمل ہونے کے انتظار میں بہت زیادہ وقت گزار رہا تھا۔

iowait اور PSI نے پورے system کا I/O pressure دکھایا

بدترین اوقات میں vmstat 4–9 blocked processes، 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

بعد کی reproductions میں full تقریباً 98% تک پہنچا۔ Disk utilization بتاتا ہے کہ device busy ہے؛ PSI بتاتا ہے کہ workload اس resource کی وجہ سے حقیقت میں کتنا stall ہو رہا ہے۔ 95–98% کا مسلسل I/O pressure معمولی performance regression نہیں ہے۔

D-state اور kernel stacks نے application سے نیچے کی layer کی طرف اشارہ کیا

پھر میں نے دیکھا کہ کون سے processes blocked تھے۔ ایک ہی وقت میں jbd2، systemd-journald، Nginx workers، Nginx cache processes اور filesystem کی دوسری سرگرمیاں D-state میں تھیں۔ اگر صرف میری application رکی ہوتی تو میں application دیکھتا۔ جب Nginx، system journal اور EXT4 journal ایک ساتھ block ہوں تو storage سب سے واضح مشترک dependency بن جاتا ہے۔

EXT4 journaling paths میں یہ شامل تھے:

wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transaction

Nginx 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 مفید کام مکمل کر سکتے ہیں۔ running اور healthy دو الگ حالتیں ہیں۔

3 ms کے backend response نے application کو filesystem path سے الگ کر دیا

سب سے صاف comparison 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 کو الگ کرنا ممکن ہوا۔

مسئلہ reproduce ہو سکتا تھا اور پھر غائب بھی ہو جاتا تھا

ایک reproduction سے پہلے machine معمول کے مطابق تھی:

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 ناکام رہیں۔ یہ صرف یہ کہنے سے کہیں زیادہ کارآمد evidence تھا کہ VPS سست محسوس ہو رہا ہے۔

Workload ہٹانے پر الٹی تبدیلی بھی بہت جلد ہو سکتی تھی:

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

اسی لیے intermittent storage problems کو بعد میں investigate کرنا مشکل ہوتا ہے۔ Recovery کے بعد provider واقعی normal latency دیکھ سکتا ہے، مگر اس سے دس منٹ پہلے ہونے والی چیز explain نہیں ہوتی۔ Exact UTC timestamps اس لیے بہت اہم ہو گئے۔

دو misleading metrics: await=0 اور free disk space

کچھ خراب intervals میں مجھے r_await = 0 نظر آتا تھا جبکہ iowait زیادہ تھا، processes D-state میں تھے، requests in-flight تھیں اور تقریباً کوئی read مکمل نہیں ہو رہی تھی۔ Latency statistics مکمل شدہ I/O پر بنتی ہیں۔ اگر operation sampling interval کے دوران مکمل نہ ہو تو وہ 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 پر error یا dropped packets نہیں تھے۔ Disk fullness پورے incident کو explain نہیں کر سکتی تھی۔

میں کیا ثابت کر سکا اور کیا نہیں

VPS کے اندر سے میں application، Linux VFS، EXT4 اور virtual block device دیکھ سکتا تھا۔ اس کے بعد provider infrastructure آتی ہے: virtualization، distributed storage، storage network، physical devices، scheduling اور دوسری layers جو guest سے inspect نہیں ہو سکتیں۔

اس لیے میں دیانت داری سے یہ دعویٰ نہیں کر سکتا کہ کوئی مخصوص physical SSD خراب تھا، یا کسی مخصوص storage node، network path یا virtualization component کو root cause قرار دے سکتا ہوں۔

میں جو بات کہہ سکتا ہوں وہ محدود مگر مضبوط evidence کے ساتھ ہے: میرے Linux guest کو دیا گیا virtual storage path بار بار ایسی حالت میں گیا جہاں عام filesystem I/O کو مکمل ہونے میں کئی سیکنڈ لگے یا وہ مناسب وقت میں مکمل ہی نہ ہوا۔ 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 میں مسئلہ تھا تو VPS پہلے کئی terabytes کامیابی سے کیسے منتقل کر چکا تھا؟

کیونکہ network traffic اور physical disk I/O ایک چیز نہیں ہیں۔ ایک file backing storage سے ایک بار پڑھی جا سکتی ہے، 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 کی ضمانت نہیں ہے۔

آخرکار میں نے deeper root cause کا انتظار چھوڑ دیا

میں نے exact timestamps، vmstat، iostat، PSI، blocked-process snapshots، kernel stacks، filesystem waits، queue depths اور HTTP timings جمع کیے۔ Diagnostics FDCServers کو بھیجے اور infrastructure level کی مزید گہری وضاحت کا انتظار کیا۔

میں نے کافی دیر انتظار کیا۔ آخرکار چھوڑ دیا۔ میری طرف سے operational decision کے لیے کافی معلومات تھیں: مسئلہ reproducible، شدید اور application layer کے نیچے نظر آ رہا تھا، جبکہ physical cause میرے VPS کی visibility سے باہر تھا۔

میں نے refund مانگا اور FDCServers نے رقم واپس کر دی

میں نے FDCServers کو مسائل اور جمع کی گئی diagnostics کا خلاصہ بھیجا، service cancel کرنے اور refund کی درخواست کی۔ انہوں نے رقم واپس کر دی۔

اس لیے یہ کہانی پیسے کے لیے طویل لڑائی پر ختم نہیں ہوتی۔ میں definitive technical explanation کا انتظار کرتا رہا، پھر فیصلہ کیا کہ مزید نہیں انتظار کروں گا، اپنا evidence بھیجا اور رقم واپس مانگی۔ FDCServers نے واپس کر دی۔

اس کے بعد میں نے کیا بدلا

اس تجربے کا مفید نتیجہ یہ فیصلہ کرنا نہیں تھا کہ 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 سست کیوں ہے۔ سوال یہ ہے: کس layer پر مفید کام مکمل ہونا بند ہو رہا ہے؟

جہاں ممکن ہو reboot سے پہلے evidence محفوظ کرتا ہوں۔ Reboot service واپس لا سکتا ہے، لیکن intermittent incident کی تشخیص کے لیے ضروری D-state، PSI، queues اور latency بھی مٹا سکتا ہے۔

آخری بات

میں نے FDCServers VPS اس لیے نہیں خریدا تھا کہ hosting article کے لیے مواد مل جائے۔ مجھے زیادہ bandwidth والا server چاہیے تھا۔ کچھ عرصے تک مجھے بالکل یہی ملا: اس نے حقیقی workload سنبھالا اور تین terabytes سے زیادہ منتقل کیے۔

پھر normal workload بار بار 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 اس کا سبب تھا، اور مجھے ایسا ظاہر کرنے کی ضرورت بھی نہیں کہ میں جانتا ہوں۔ میں نے failure کی layer شناخت کی، application problem سے الگ کرنے کے لیے کافی evidence جمع کیا، deeper root-cause explanation کا انتظار چھوڑا اور رقم واپس مانگی۔ FDCServers نے refund کر دیا۔

یہ ہر FDCServers VPS کے بارے میں verdict نہیں ہے۔ یہ صرف ایک اچھی طرح documented یاد دہانی ہے کہ service active اور process running دکھائی دے سکتا ہے جبکہ machine اپنا تقریباً سارا مفید وقت storage کا انتظار کرتے ہوئے گزار رہی ہو۔