OpenVPN ٹریفک کاؤنٹرز اور ڈسک I/O: تین مختلف اعداد
انٹرفیس کے بائٹس، عمل کے حروف کاؤنٹرز اور اسٹوریج کی تحریریں الگ الگ کام ناپتی ہیں۔ سرنگ کے حجم سے ڈسک کا تخمینہ لگانے سے پہلے ان کا موازنہ کریں۔
کوئی بڑی فائل سرنگ سے گزارئیں تو انٹرفیس کاؤنٹر فائل کے حجم جتنا بڑھ جاتا ہے۔ اس عدد میں کچھ بھی یہ نہیں بتاتا کہ وہی حجم کسی ڈسک تک پہنچا۔ ان بحثوں میں تین مختلف پیمانے موازنہ کیے جاتے ہیں، اور وہ تین مختلف سوالوں کا جواب دیتے ہیں: کتنی ٹریفک نیٹ ورک کی ایک تہہ سے گزری، کسی عمل نے سسٹم کالز کے ذریعے کتنے بائٹس پڑھے اور لکھے، اور کتنا کام اسٹوریج کی تہہ تک پہنچا۔
پہلے کا تیسرے سے موازنہ کرنا عام غلطی ہے، اور اس سے یا تو ڈسک کا بھوت مسئلہ بنتا ہے یا ایسی گنجائش کا منصوبہ جو واقعی ہونے والی تحریروں کو نظرانداز کرتا ہے۔ تینوں الگ کیے جا سکتے ہیں، اور ہر ایک کا درست استعمال ہے۔
تین اعداد جو آپس میں ملائے جاتے ہیں
انٹرفیس کاؤنٹرز نیٹ ورک کی تہہ میں نمٹائی جانے والی ٹریفک بیان کرتے ہیں۔ بینڈوتھ، سرنگ کے حجم اور گزرگاہ کی قیمت لگانے والے بلنگ ماڈلز کے لیے یہی درست عدد ہے۔
عمل کے حروف کاؤنٹرز پائپ، ٹرمینل اور حرفی آلات سمیت کسی بھی ڈسکرپٹر پر پڑھنے اور لکھنے کی کالز سے منتقل ہونے والے بائٹس بیان کرتے ہیں۔ سسٹم کال کی حد پر عمل کتنا مصروف ہے یہ پوچھنے کے لیے یہی درست عدد ہے، اور یہ اسٹوریج کا بل نہیں۔
اسٹوریج کاؤنٹرز وہ بائٹس بیان کرتے ہیں جو کرنل نے کسی بلاک ڈیوائس میں یا اس سے منتقل کرنے کی کوشش کی۔ گنجائش کی منصوبہ بندی کے لیے یہی درست عدد ہے، البتہ اس شرط کے ساتھ کہ کرنل اپنی حساب کی حدیں درج کرتا ہے: کیش میں رکھی گئی پڑھائی اسٹوریج کی پڑھائی نہیں بنتی، اور بعد میں منسوخ ہونے والی تحریر مکمل ڈیوائس تحریر نہیں بنتی۔
| Measurement | Question it answers |
|---|---|
| Interface bytes | How much traffic crossed this layer |
rchar and wchar | How much data the process moved through system calls |
read_bytes and write_bytes | How much work reached the storage layer |
فائل ڈسکرپٹر ڈسک پر تحریر کیوں نہیں
صارف کی جگہ کا VPN کرنل کے ساتھ پیکٹ TUN ڈیوائس کے ذریعے بدلتا ہے، جو عام فائل نہیں بلکہ حرفی آلہ ہے۔ اس سے پڑھنا ایک پیکٹ سپرد کرتا ہے؛ اس میں لکھنا ایک پیکٹ داخل کرتا ہے۔ اسٹوریج کے لیے تیار کی جانے والی فائل کے مواد کا کوئی صفحہ نہیں، اور فائل سسٹم کا کوئی راستہ شامل نہیں۔
اسی لیے مصروف سرنگ تقریباً کوئی اسٹوریج کاؤنٹر نہ ہونے کے باوجود بہت بڑے حروفی کاؤنٹرز دکھا سکتی ہے۔ عمل نے وہ بائٹس واقعی منتقل کیے، اور کرنل کو یہ کرنے کے لیے واقعی ڈسک کی ضرورت نہیں تھی۔
cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0پہلی آؤٹ پٹ کو عمل شروع ہونے کے بعد سے مجموعی سمجھ کر پڑھیں، رفتار کے طور پر نہیں۔ دوسری اسی ٹریفک کا انٹرفیس منظر دیتی ہے۔ دونوں کے درمیان بڑا فرق متوقع ہے اور یہ رساؤ، قطار یا غلط کنفیگریشن کی نشاندہی نہیں کرتا۔
بائٹس واقعی کہاں سے آتے ہیں
مسلسل آؤٹ پٹ کا اپنا بجٹ ہوتا ہے، اور اسے پے لوڈ نہیں بلکہ کارروائیاں چلاتی ہیں۔ تفصیلی لاگ سطح، بار بار بدلنے والی کلائنٹ فہرست، یا تنگ لوپ میں دہرانے والی غلطی سرنگ کے بہت کم اٹھانے پر بھی قابلِ ذکر تحریریں پیدا کر سکتی ہے۔
اسٹیٹس فائل ایک وقفے پر دوبارہ لکھی جانے والی اسنیپ شاٹ ہے، اس لیے اس کی لاگت وقفے اور اس میں موجود ریکارڈز کی تعداد پر منحصر ہے۔ یہ ہر کلائنٹ کی ٹریفک کی چلتی نقل نہیں، اور وقفہ کم کرنے سے ٹریفک کا حجم بدلے بغیر تحریر کا حجم بدل جاتا ہے۔
ان تحریروں کو ڈھونڈتے وقت ملکیت اہم ہے۔ اگر سروس پیغامات کسی لاگنگ ڈیمون کو دیتی ہے، تو جرنل یا لاگ فائل وہی ڈیمون لکھتا ہے، اور بائٹس VPN عمل کے اپنے کاؤنٹرز میں نہیں بلکہ ڈیمون کے حساب میں ظاہر ہوتے ہیں۔ صرف VPN عمل کو دیکھنا نہ ڈسک کی سرگرمی کی وضاحت کرتا ہے نہ اس کی عدم موجودگی کی۔
دوسرے شراکت داروں کو نظرانداز کرنا آسان ہے: آغاز میں سرٹیفکیٹ اور کنفیگریشن کی پڑھائی، اپنے ریکارڈ لکھنے والے ہک، اکاؤنٹنگ پلگ انز، کریش ڈمپ، اور اسی ہوسٹ پر غیر متعلقہ کام کا بوجھ۔ ان میں سے کسی کا بھی اندازہ سرنگ کی ٹریفک کو لکھے گئے بائٹس کے برابر کر کے نہیں لگانا چاہیے۔
ہر کاؤنٹر کو درست طریقے سے پڑھنا
تین تفصیلیں طے کرتی ہیں کہ موازنے کا کوئی مطلب ہے یا نہیں۔ عمل کی شناخت اہم ہے، کیونکہ دوبارہ شروع ہونے والی سروس اپنے کاؤنٹرز ری سیٹ کر دیتی ہے۔ وقت کا وقفہ اہم ہے، کیونکہ مجموعی عدد اور فی سیکنڈ چارٹ الگ پیمانے ہیں۔ اور اکائی بھی اہم ہے، کیونکہ لاگ فائل کا موجودہ حجم بھی رفتار نہیں۔
grep -E 'rchar|wchar|read_bytes|write_bytes' /proc/$(pgrep -n openvpn)/io
du -sh /var/log/openvpn 2>/dev/null
journalctl --disk-usageاگر آپ کو واقعی پے لوڈ تحریروں کا شک ہو، تو ایسا جزو تلاش کریں جس کا کام پے لوڈ محفوظ کرنا ہے: پیکٹ پکڑنے کا آلہ، باڈی کیش کرنے والا پراکسی، آرکائیو کرنے والا پلگ ان۔ یہ ایسی اسٹوریج ٹریفک پیدا کرتے ہیں جو ان سے جتنا ریکارڈ کرنے کو کہا جائے اس کے مطابق بڑھتی ہے، اور یہ نگہداشت اور رسائی کے بارے میں الگ پالیسی فیصلے سے تعلق رکھتے ہیں۔
درست عدد کے ساتھ گنجائش کی منصوبہ بندی
پیکٹ کے راستے کو نیٹ ورک کے اعداد سے ناپیں: تھرو پٹ، خفیہ نگاری کی کارروائی اور میموری کی حرکت۔ اسٹوریج کو ان مشاہداتی فیصلوں سے ناپیں جو آپ نے واقعی کیے: لاگ سطح، نگہداشت، اسٹیٹس وقفہ، اور جان بوجھ کر فعال کی گئی کوئی بھی گرفت۔
ان دو بجٹوں کو الگ رکھنا واقعات کو پڑھنا بھی آسان بناتا ہے۔ معمولی سرنگ ٹریفک کے ساتھ بھری ڈسک لاگز، گرفٹس یا کسی غیر متعلقہ چیز کی طرف اشارہ کرتی ہے، اور انٹرفیس کاؤنٹر اسے کبھی واضح نہیں کرے گا۔ خاموش لاگ کے ساتھ بھرا ہوا لنک دوسری سمت اشارہ کرتا ہے۔
قابلِ قدر موازنہ ایک ہی قسم کے پیمانوں کے درمیان ہوتا ہے۔ وقت کے ساتھ انٹرفیس بائٹس بمقابلہ انٹرفیس بائٹس آپ کو راستے کے بارے میں بتاتے ہیں۔ اسٹوریج تحریریں بمقابلہ اسٹوریج گنجائش آپ کو نگہداشت کے بارے میں بتاتی ہیں۔ آڑا موازنہ، ٹریفک بمقابلہ ڈسک، صرف بامعنی دکھتا ہے اور کبھی ہوتا نہیں۔