ڈسک کی رفتار: بیس لائن اور برسٹ
ٹیئر کے حساب سے ڈسک کی رفتار کی حد کیسے شمار ہوتی ہے، 30 سیکنڈ کا برسٹ کیوں ضروری ہے، اصل رفتار کیسے ناپیں، اور حد پر پہنچ جائیں تو کیا کریں۔
اپ ڈیٹ 23 اگست، 2026
VPS پر ڈسک NVMe ہے، لیکن رفتار ٹیئر کے مطابق محدود ہے تاکہ ایک مشین نوڈ کے مشترکہ ریسورس کو نہ کھا جائے۔ ان نمبروں کو سمجھنا آپ کو اس سوال سے بچاتا ہے کہ ”جب CPU خالی ہے تو ڈیٹا بیس سست کیوں ہے“۔
یہ کیسے حساب ہوتی ہے
لکھنے کی بنیادی رفتار 60 MB/s فی کور ہے، لیکن 60 سے کم نہیں اور 400 MB/s سے زیادہ نہیں۔ پڑھنے کی رفتار لکھنے کی بنیادی رفتار سے دوگنی ہے۔ بنیادی رفتار سے اوپر، اس کی تین گنا قیمت کا برسٹ 30 سیکنڈ کے لیے دستیاب ہوتا ہے۔
| ٹیئر | کورز | لکھنے کی بنیادی رفتار | پڑھنے کی بنیادی رفتار | لکھنے کا برسٹ (30 سیکنڈ) |
|---|---|---|---|---|
| VDS-1 | 1 | 60 MB/s | 120 MB/s | 180 MB/s |
| VDS-2 | 2 | 120 MB/s | 240 MB/s | 360 MB/s |
| VDS-3 | 4 | 240 MB/s | 480 MB/s | 720 MB/s |
| VDS-4 | 6 | 360 MB/s | 720 MB/s | 1080 MB/s |
| VDS-5 | 8 | 400 MB/s | 800 MB/s | 1200 MB/s |
| VDS-6 | 10 | 400 MB/s | 800 MB/s | 1200 MB/s |
برسٹ وہ سب کچھ پورا کرتا ہے جو اسے پورا کرنا چاہیے: ایپلیکیشن اسٹارٹ اپ، آرکائیو نکالنا، مائیگریشن لاگو کرنا۔ مسلسل لکھنے کی اسٹریم — کئی گیگابائٹ کاپی کرنا، بلڈ، بڑے ڈیٹا بیس کی اسکیننگ — بنیادی رفتار پر چلتی ہے۔
پیمائش کیسے کریں
sudo apt install -y fio
fio --name=w --rw=write --bs=1M --size=2G --numjobs=1 \
--runtime=60 --time_based --end_fsync=1 --directory=/var/tmp
پہلے چند سیکنڈ برسٹ دکھائیں گے، پھر رفتار بنیادی سطح پر گر جائے گی — یہ معمول اور متوقع تصویر ہے، کوئی خرابی نہیں۔
پیکجز انسٹال کیے بغیر ایک فوری موٹا جائزہ:
dd if=/dev/zero of=/var/tmp/testfile bs=1M count=2048 oflag=direct
rm /var/tmp/testfile
کام کے اوقات میں پروڈکشن مشین پر ڈسک ٹیسٹ نہ چلائیں۔ ٹیسٹ واقعی پوری دستیاب بینڈوتھ استعمال کرے گا، اور ان منٹوں میں آپ کی سائٹ جواب دینے میں سیکنڈز لے گی۔ اور ٹیسٹ فائلیں پیچھے نہ چھوڑیں: 40 GB ڈسک پر دو گیگابائٹ ایک نمایاں حصہ ہے، دیکھیں disk space۔
کیسے پتہ چلے کہ ڈسک ہی رکاوٹ ہے
sudo apt install -y sysstat
iostat -x 2 5
vmstat 2 5
دو میٹرکس دیکھیں: %util کا 100 کے قریب ہونا اور await کا دسیوں ملی سیکنڈز میں ہونا ڈسک کی قطار کی نشاندہی کرتے ہیں۔ vmstat میں بھی علامت وہی ہے — بڑھتا ہوا b کالم (انتظار کرنے والے پروسیسز) جبکہ CPU کے استعمال کی شرح کم ہو۔
ایک اور علامت: زیادہ load average جبکہ CPU تقریباً بیکار ہو۔ Linux کا load average ڈسک کے انتظار میں موجود پروسیسز کو بھی گنتا ہے۔
اصل میں کون لکھ رہا ہے:
sudo iotop -o -b -n 3
اگر آپ رکاوٹ سے ٹکرا گئے ہیں تو کیا کریں
- انہیں وقت میں الگ الگ کریں۔ کاپیاں، رجسٹری بلڈز، رپورٹس — رات کو اور ایک ہی وقت میں نہیں۔ دیکھیں scheduled jobs۔
- پس منظر کے کاموں کو محدود کریں۔
rsync --bwlimit،nice -n 19 ionice -c3 <command>ہر اس چیز کے لیے جو فوری نہیں۔ - لکھنا کم کریں۔ لاگ کا سائز محدود کریں، ایپلیکیشن میں ضرورت سے زیادہ وربروزٹی بند کریں، کیش کو میموری (
tmpfs) میں منتقل کریں اگر یہ ری بوٹ کے بعد بچ جائے۔ - ڈیٹا بیس کو ٹیون کریں۔ PostgreSQL اور MySQL میں لکھنے کا بڑا حصہ ٹرانزیکشن لاگ ہوتا ہے۔ بفرز کے لیے زیادہ میموری کا مطلب کم ڈسک رسائی۔
- ایک ٹیئر اوپر جائیں۔ بنیادی رفتار کورز کے ساتھ بڑھتی ہے: VDS-1 سے VDS-2 تک یہ دوگنی ہو جاتی ہے۔ منصوبہ بند اپ گریڈ صرف اوپر کی طرف ممکن ہیں، ادا شدہ مدت کے باقی دنوں کے لیے اضافی ادائیگی کے ساتھ۔
عام غلطیاں
ddسےoflag=directکے بغیر رفتار ناپنا۔ ڈیٹا پیج کیش میں بیٹھ جاتا ہے، اور نمبر بڑھے ہوئے آتے ہیں۔- برسٹ کو مستقل رفتار سمجھنا۔ پہلے 30 سیکنڈ تیز، پھر بنیادی رفتار — یہ ڈیزائن کے مطابق ہے۔
- ایکٹو ڈسک پر swap رکھنا اور اس میں swap کرنا۔ جب میموری کم ہو، swap ڈسک کو رکاوٹ بنا دیتا ہے: بہتر ہے کنٹینرز کو محدود کریں، دیکھیں resource limits۔