আমি এটি FDCServers-এর নেতিবাচক রিভিউ হিসেবে লিখছি না। তাদের কাছ থেকে VPS কেনা উচিত কি না, সেটাও কাউকে বলে দেওয়ার চেষ্টা করছি না। আমার ছিল একটি সার্ভার, একটি workload এবং একটি নির্দিষ্ট সমস্যার ধারাবাহিকতা। এতটুকু দিয়ে পুরো hosting company-কে বিচার করা যায় না।
এটি আমার একজন developer হিসেবে কাজের দিনের একটি ঘটনা। VPS কিছুদিন স্বাভাবিকভাবেই চলছিল এবং ইতিমধ্যে 3 TB-এর বেশি ট্র্যাফিক ট্রান্সফার করেছিল। তারপর স্বাভাবিক workload-এ তীব্র delay শুরু হলো। পেজের response পেতে অনেক সময় লাগছিল, কখনও পুরোপুরি timeout হচ্ছিল। প্রথম সন্দেহ ছিল application, Nginx, memory, network, connection limit বা অতিরিক্ত load। কিন্তু Linux metrics অন্য দিকে ইঙ্গিত করছিল।
VPS শুরু থেকেই ধীর ছিল না
ঘটনার মাঝখানে server পুরোপুরি healthy দেখাতে পারত। একটি পরিষ্কার সময়ে D-state-এ কোনো process ছিল না, 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 তদন্তের দিক বদলে দিল
সবচেয়ে শক্তিশালী iostat sample-গুলোর একটি ছিল:
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-এর বেশি, অথচ কার্যকর read throughput মাত্র 88 KB/s। অর্থাৎ disk শুধু প্রচুর data দ্রুত সরাচ্ছিল না; storage path operations শেষ হওয়ার অপেক্ষাতেই বিশাল সময় কাটাচ্ছিল।
iowait এবং PSI পুরো system-এর I/O pressure দেখাল
সবচেয়ে খারাপ সময়ে vmstat-এ 4–9টি blocked process, CPU iowait 97–100% এবং CPU idle 0% দেখা গেছে। iowait মানে application পুরো CPU খাচ্ছে না; এর অর্থ useful work outstanding I/O শেষ হওয়ার অপেক্ষায় আছে।
Linux Pressure Stall Information ছবিটা আরও স্পষ্ট করে:
I/O PSI some avg10 = 99.14
I/O PSI full avg10 = 95.55পরে পুনরায় ঘটার সময় full প্রায় 98%-এ পৌঁছেছিল। Disk utilization বলে device ব্যস্ত কি না; PSI বলে সেই resource-এর জন্য workload কতটা আটকে আছে। 95–98% sustained I/O pressure ছোটখাটো performance regression নয়।
D-state এবং kernel stack application-এর নিচের স্তরে ইঙ্গিত করছিল
আমি blocked process-গুলো দেখি। একই সময়ে jbd2, systemd-journald, Nginx worker, Nginx cache process এবং অন্যান্য filesystem activity D-state-এ ছিল। শুধু application আটকে থাকলে application-ই খুঁজতাম। কিন্তু Nginx, system journal এবং EXT4 journal একসঙ্গে আটকে গেলে তাদের shared dependency হিসেবে storage-ই সামনে আসে।
EXT4 journaling path-এ ছিল:
wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transactionNginx worker সাধারণ file read-এর মধ্যে অপেক্ষা করছিল:
folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64এক পর্যায়ে kernel জানায় একটি Nginx task 122 সেকেন্ডের বেশি blocked ছিল। Nginx তখনও active দেখা যেতে পারে, কিন্তু তার worker useful work শেষ করতে পারছে—এটা তার প্রমাণ নয়। running আর healthy এক জিনিস নয়।
3 ms backend response application-কে filesystem path থেকে আলাদা করল
সবচেয়ে পরিষ্কার তুলনা ছিল Nginx এবং local application backend-এর মধ্যে। Nginx দিয়ে request করলে 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 read-এর অপেক্ষায় দেখা যাচ্ছিল। এতে application execution এবং তার সামনে থাকা filesystem-dependent path পরিষ্কারভাবে আলাদা হয়।
সমস্যাটি পুনরায় ঘটানো যেত, আবার দ্রুত অদৃশ্যও হতে পারত
একটি 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 test ব্যর্থই ছিল। VPS ধীর মনে হচ্ছে—এই কথার চেয়ে এই measurement অনেক বেশি কার্যকর evidence।
Workload সরালে উল্টো পরিবর্তনও দ্রুত হতে পারত:
D-state: 0
CPU iowait: 6%
r_await: ~0.98 ms
queue depth: ~0.07
HTTP: 200এ কারণেই intermittent storage problem পরে গিয়ে diagnose করা কঠিন। Recovery-এর পরে provider সত্যিই normal latency দেখতে পারে, কিন্তু দশ মিনিট আগে কী হয়েছিল তা এতে বোঝা যায় না। তাই exact UTC timestamp গুরুত্বপূর্ণ হয়ে ওঠে।
দুটি misleading metric: await=0 এবং free disk space
কিছু খারাপ interval-এ r_await = 0 দেখেছি, অথচ iowait বেশি, process D-state-এ, request in-flight এবং read প্রায় complete-ই হচ্ছিল না। Latency statistics completed I/O-এর ওপর নির্ভর করে। কোনো operation sampling interval-এর মধ্যে শেষ না হলে completed latency average-এ সেটি আসে না। তাই zero সব সময় instant disk বোঝায় না।
Disk fullness-ও বিবেচনা করেছি। পরে filesystem আমার পছন্দের চেয়ে বেশি পূর্ণ হয়েছিল, কিন্তু একই ধরনের failure আগেই দেখা দিয়েছিল যখন root filesystem মাত্র প্রায় 24% used ছিল। তখন প্রায় 1.2 GiB RAM available ছিল, inode usage প্রায় 5%, এবং network interface-এ error বা dropped packet ছিল না। তাই disk fullness পুরো ঘটনাটি ব্যাখ্যা করতে পারে না।
আমি কী প্রমাণ করতে পেরেছি, আর কী পারিনি
VPS-এর ভিতর থেকে application, Linux VFS, EXT4 এবং virtual block device পর্যন্ত দেখতে পেরেছি। এরপর provider infrastructure: virtualization, distributed storage, storage network, physical device, scheduling এবং এমন আরও স্তর আছে যেগুলো guest থেকে inspect করা যায় না।
তাই কোনো নির্দিষ্ট physical SSD নষ্ট ছিল, বা নির্দিষ্ট storage node, network path বা virtualization component-ই root cause—এ কথা আমি সত্যি করে বলতে পারি না।
আমি যা বলতে পারি তা সীমিত কিন্তু ভালোভাবে supported: আমার Linux guest-কে দেওয়া virtual storage path বারবার এমন অবস্থায় গেছে যেখানে সাধারণ filesystem I/O শেষ হতে কয়েক সেকেন্ড লেগেছে অথবা যুক্তিসঙ্গত সময়ে শেষই হয়নি। এর evidence ছিল iostat, PSI, D-state, kernel wait stack, EXT4/jbd2 wait, Nginx filesystem wait, queue depth এবং request timing। Engineering diagnosis-এর জন্য এটি যথেষ্ট ছিল, physical root cause নির্ধারণের জন্য নয়।
আগের 3 TB-এর বেশি traffic কেন পরের stall-এর সঙ্গে বিরোধী নয়
প্রথমে এটিই আমাকে সবচেয়ে বেশি ভাবিয়েছিল। Storage সমস্যা হলে VPS আগে কয়েক terabyte সফলভাবে পাঠাল কীভাবে?
কারণ network traffic এবং physical disk I/O এক জিনিস নয়। একটি file backing storage থেকে একবার read হয়ে Linux page cache-এ থাকতে পারে, এরপর memory থেকেই বহুবার serve হতে পারে। তাই network দিয়ে 3 TB transfer মানে 3 TB unique physical disk read নয়।
Infrastructure condition-ও সময়ের সঙ্গে বদলায়: cache state, storage load, queueing, host placement এবং অন্য workload বদলাতে পারে। VPS গতকাল ভালো চলেছে মানে আজও storage একই আচরণ করবে—এমন নিশ্চয়তা নেই।
এক পর্যায়ে deeper root cause-এর জন্য অপেক্ষা বন্ধ করি
আমি exact timestamp, vmstat, iostat, PSI, blocked-process snapshot, kernel stack, filesystem wait, queue depth এবং HTTP timing সংগ্রহ করি। Diagnostics FDCServers-এ পাঠিয়ে infrastructure-level explanation-এর জন্য অপেক্ষা করি।
অনেকদিন অপেক্ষা করেছি। শেষে অপেক্ষা করা বন্ধ করি। আমার operational decision নেওয়ার জন্য যথেষ্ট তথ্য ছিল: সমস্যা reproducible, গুরুতর, application layer-এর নিচে দৃশ্যমান এবং physical cause VPS-এর ভিতর থেকে দেখা সম্ভব নয়।
আমি refund চেয়েছিলাম, FDCServers টাকা ফেরত দিয়েছে
আমি সমস্যাগুলো এবং সংগৃহীত diagnostics-এর summary FDCServers-এ পাঠিয়ে service cancel ও refund চেয়েছিলাম। তারা টাকা ফেরত দিয়েছে।
তাই গল্পটি টাকা ফেরত পাওয়ার দীর্ঘ লড়াইয়ে শেষ হয়নি। Definitive technical explanation-এর জন্য অপেক্ষা করেছি, আর অপেক্ষা করতে চাই না বলে সিদ্ধান্ত নিয়েছি, evidence পাঠিয়েছি এবং টাকা ফেরত চেয়েছি। FDCServers তা ফিরিয়ে দিয়েছে।
এরপর আমি কী বদলেছি
সবচেয়ে উপকারী ফল ছিল কোনো hosting company ভালো না খারাপ তা নির্ধারণ করা নয়। বরং slow Linux server debug করার পদ্ধতি বদলেছে।
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 আলাদাভাবে test করি: public request, local Nginx, direct backend, filesystem এবং block-device metrics। প্রশ্ন এখন শুধু server ধীর কেন নয়; বরং কোন স্তরে useful work শেষ হওয়া বন্ধ করছে?
সম্ভব হলে reboot-এর আগে evidence সংগ্রহ করি। Reboot service ফিরিয়ে দিতে পারে, কিন্তু intermittent incident diagnose করার জন্য দরকারি D-state, PSI, queue এবং latency-ও মুছে দিতে পারে।
শেষ কথা
Hosting article লেখার উপকরণ পাওয়ার জন্য আমি FDCServers VPS কিনিনি। আমার দরকার ছিল বেশি bandwidth-এর server। কিছুদিন ঠিক সেটাই পেয়েছিলাম: বাস্তব workload চলেছে এবং তিন terabyte-এর বেশি transfer হয়েছে।
তারপর normal workload বারবার iowait 100% পর্যন্ত, I/O PSI প্রায় 100%, read 18.7 সেকেন্ড পর্যন্ত, flush latency 53 সেকেন্ডের বেশি, বড় queue, filesystem read-এ blocked Nginx এবং I/O-এর অপেক্ষায় EXT4/jbd2 তৈরি করতে শুরু করে।
কোন physical বা host-side component এর কারণ ছিল তা আমি কখনও জানতে পারিনি, এবং জানি এমন ভান করার দরকারও নেই। Failure কোন layer-এ প্রকাশ পাচ্ছে তা নির্ধারণ করেছি, application problem থেকে আলাদা করার মতো যথেষ্ট evidence সংগ্রহ করেছি, deeper root-cause explanation-এর জন্য অপেক্ষা বন্ধ করেছি এবং refund চেয়েছি। FDCServers টাকা ফেরত দিয়েছে।
এটি সব FDCServers VPS সম্পর্কে verdict নয়। এটি শুধু একটি ভালোভাবে documented reminder: service active এবং process running দেখালেও machine তার প্রায় সব useful সময় storage-এর অপেক্ষায় কাটাতে পারে।