VPN سرور کا بوجھ سمجھایا گیا: صارفین، CPU یا اوپر کا لنک؟
کم بوجھ کا اسکور بیکار صارفین، بچا ہوا CPU یا چوڑا اوپر کا لنک ہو سکتا ہے۔ اسے تیز کہنے سے پہلے loadavg، انٹرفیس کاؤنٹرز اور اسٹیٹس فائل پڑھیں۔
0.4 بوجھ پر بیٹھا گیٹ وے اپنے پیچھے ہر صارف کے لیے اب بھی رینگ سکتا ہے۔ اوسط بوجھ اُن کاموں کو گنتا ہے جو چلائے جا سکتے ہیں یا جو بلا تعطل نیند میں پھنسے ہوئے ہیں، اور چار کور والے ہوسٹ پر ایک ہی مطمئن عمل اسے 1.0 کی طرف دھکیلنے کے لیے کافی ہے جبکہ تین کور بیکار بیٹھے رہتے ہیں۔ اُس عدد کو زائد صلاحیت سمجھ کر پڑھنا اینڈپوائنٹ کے انتخاب میں سب سے عام غلطی ہے۔ سرنگ کو دراصل محدود کرنے والی چیز عام طور پر چار میں سے ایک ہوتی ہے: ایک مصروف کور، اوپر کا لنک، اس کے آگے کی قطار، یا کسی ایسی فی سیشن پالیسی جسے کسی نے دستاویز نہیں کیا۔
اوسط بوجھ کام گنتا ہے، تھرو پٹ نہیں
کرنل رن کیو اور ان پٹ آؤٹ پٹ کے منتظر کاموں کی تعداد کے نمونے لیتا ہے، پھر دونوں کو ایک، پانچ اور پندرہ منٹ میں ہموار کرتا ہے۔ اُس تعریف میں بائٹس، پیکٹ یا سرنگ کا کوئی ذکر نہیں ہے۔ جس ہوسٹ کا اسٹوریج پھنسا ہوا ہو تو وہ تقریباً بغیر ٹریفک کے زیادہ بوجھ بتا سکتا ہے، اور کرنل ڈیٹا راستے سے گیگابٹ دھکیلنے والا ہوسٹ آرام دہ بوجھ بتا سکتا ہے۔
اس لیے بوجھ کو سرنگ کی کارکردگی سے جوڑنے کے لیے ہر کور کا نظارہ درکار ہے۔ اگر ایک کور پوری طرح بھرا ہوا ہے تو ڈیش بورڈ پر مجموعی فیصد پھر بھی ٹھیک دکھائی دے گا:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20تیسری کمانڈ وہی ہے جو VPN ہوسٹس پر سب سے زیادہ اہم ہے۔ OpenVPN 2.x میں صارف کی جگہ پر پیکٹ پروسیسنگ زیادہ تر فی عمل ترتیب وار ہے، اس لیے ایک ہی مصروف تھریڈ چھت بن سکتا ہے جبکہ ڈیش بورڈ کافی خالی صلاحیت بتاتا ہے۔ اگر آپ کی سست مدت میں ایک تھریڈ کور کا زیادہ تر حصہ رکھتا ہے تو ہوسٹ مجموعی طور پر کم لیس نہیں؛ وہ اُس جہت میں محدود ہے جو اتفاقاً اہم ہے۔
وقت پر بھی توجہ دیں۔ پندرہ منٹ کی اوسطیں اُس دھماکے کو چھپا دیتی ہیں جس نے کال خراب کی، اس لیے شکایت کے بعد لی گئی اسکرین شاٹ کمزور ثبوت ہے۔ مسئلے کے دوران نمونے لیں، اور آؤٹ پٹ کے ساتھ وقت کی مہر رکھیں۔
اوپر کا لنک اور اس کے آگے کی قطار
انٹرفیس کاؤنٹرز بینڈوتھ کے اُس سوال کا جواب دیتے ہیں جس کا CPU کے اعداد جواب نہیں دے سکتے۔ وہ صلاحیت کو نقصان سے بھی الگ کرتے ہیں، اور یہ مختلف علاج والی مختلف ناکامیاں ہیں:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitآپ کے ٹیسٹ کے دوران اپنی مختص رفتار کے قریب لنک ہی وضاحت ہے، اور بچے ہوئے CPU کی کوئی مقدار اسے نہیں بدلتی۔ qdisc کی سطر وہ تفصیل شامل کرتی ہے جو متعامل ٹریفک کے لیے اہم ہے: بیک لاگ اور ڈراپ بتاتے ہیں کہ پیکٹ نکلنے سے پہلے قطار میں رکتے ہیں یا نہیں۔ بھاری اپ لوڈ کے تحت بھرنے والی قطار بالکل وہی علامت پیدا کرتی ہے جس کا الزام لوگ دور کے سرور پر لگاتے ہیں، یعنی ایسے کنکشن پر سست کالیں جو بینچ مارک میں اب بھی اچھا دکھتا ہے۔
دوبارہ ترسیل کے کاؤنٹرز اُس کیفیت کو پکڑتے ہیں جہاں پیکٹ نکلتے ہیں مگر کبھی صاف نہیں پہنچتے۔ اگر سست ونڈو میں دوبارہ ترسیل بڑھے اور انٹرفیس صلاحیت کے قریب نہ ہو تو مسئلہ ہوسٹ پر نہیں راستے میں ہے، اور اسی شہر میں دوسرے اینڈپوائنٹ پر جانے سے مدد نہیں ملے گی۔
سیشنوں کی تعداد طلب بتاتی ہے، زائد صلاحیت نہیں
ہر عوامی ڈائریکٹری کچھ تعداد میں منسلک صارفین دکھاتی ہے، اور اُن میں سے تقریباً کوئی نہیں بتاتا کہ وہ صارفین کیا کر رہے ہیں۔ بیس سیشنز جو متعامل کام کرتے ہیں اور چار سیشنز جو بڑی فائلیں کھینچتے ہیں ایک ہی ہارڈویئر پر بہت مختلف بوجھ پیدا کرتے ہیں۔ دوسرا نمونہ صارفین کی تعداد میں نظر نہیں آتا، اور وہی ایک شام برباد کرتا ہے۔ اس لیے سیشن کی تعداد کو طلب کا اشارہ سمجھ کر پڑھنا بہتر ہے، کبھی بھی خالی صلاحیت کے بارے میں بیان کے طور پر نہیں۔
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
جس ہوسٹ کو آپ کنٹرول کرتے ہیں وہاں اسٹیٹس فائل گمشدہ جہت دیتی ہے۔ OpenVPN وقتاً فوقتاً اسنیپ شاٹ لکھتا ہے جس میں فی کلائنٹ بائٹ کاؤنٹرز شامل ہوتے ہیں، اور یہ دیکھنے کے لیے کافی ہے کہ کیا ایک ہی سیشن پورے اوپر کے لنک کا ذمہ دار ہے:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusدس سیکنڈ کے وقفے پر دو نمونے اُن مجموعی گنتیوں کو فی کلائنٹ شرح میں بدل دیتے ہیں۔ یہی وہ پیمائش ہے جس کی جگہ صارفین کی تعداد لیتی ہے، اور یوں ہی آپ پاتے ہیں کہ ایک غلط کنفیگر کلائنٹ ہر رات اسی گھنٹے لنک کو مطمئن کرتا ہے۔
فی سیشن حدود پالیسی میں چھپی ہوتی ہیں
سرور بیکار ہو سکتا ہے اور پھر بھی آپ کو بینڈوتھ دینے سے انکار کر سکتا ہے۔ شرح کی حدیں، فی کلائنٹ بینڈوتھ کی چھتیں اور ٹریفک کی تشکیل اکثر مشترک نام یا پول کے مطابق لاگو ہوتی ہیں، اس لیے ایک ہی گیٹ وے پر دو صارفین بہت مختلف نتائج پا سکتے ہیں۔ طریقہ کار باریک نہیں، مگر باہر سے نظر نہیں آتا کیونکہ دونوں صورتوں میں سرنگ معمول کے مطابق اٹھتی ہے۔
تشکیل سرنگ کے انٹرفیس پر تلاش کریں، جسمانی پر نہیں۔ دیکھیں کہ حد صارف، سرٹیفکیٹ یا پتوں کے پول کی پیروی کرتی ہے۔ اگر آپ کا ٹیسٹ اکاؤنٹ بغیر حد کے پول میں پڑ جائے تو آپ نتیجہ نکالیں گے کہ سرور درست ہے اور شکایت کرنے والا صارف غلط ہے۔ یہ نتیجہ کسی بھی نتیجے سے بدتر ہے، کیونکہ یہ ٹکٹ بند کر دیتا ہے۔
دو اینڈپوائنٹس کا موازنہ ایک مقررہ کام سے کریں
کلائنٹ کی طرف کا تجربہ اب بھی کرنے کے قابل ہے، مگر صرف اُس وقت جب متغیرات مقرر ہوں۔ وہی ڈیوائس، وہی رسائی نیٹ ورک، وہی پروٹوکول اور وہی منزل فائل استعمال کریں، پھر اسی جیسے فاصلے پر دوسرے اینڈپوائنٹ کے خلاف دہرائیں۔ رنز کے درمیان جو کچھ بدلے، دن کا وقت بھی شامل، نتیجہ کو آلودہ کرتا ہے۔
ناکامیوں کو کامیابیوں جیسی احتیاط سے ریکارڈ کریں۔ وہ سلسلہ جس میں تین اینڈپوائنٹس چلتے ہیں اور ایک وقت کی حد پر پہنچ جاتا ہے چار رفتار کے اعداد سے زیادہ معلوماتی ہے، کیونکہ وہ صلاحیت کی نہیں بلکہ راستے یا پالیسی کی مشکل کی طرف اشارہ کرتا ہے۔ ہر کیس کم از کم دو بار چلائیں؛ مشترکہ نیٹ ورک پر ایک سست نمونہ کچھ ثابت نہیں کرتا۔
آخر میں، آپ نے جو اعداد جمع کیے ہیں اُنہیں اُس دعوے کے ساتھ رکھیں جس کی وہ تائید کرتے ہیں۔ "اس اینڈپوائنٹ نے منتقلی اُسی ونڈو میں مکمل کی جس میں دوسرا پھنس گیا" قابل دفاع ہے، جبکہ "یہ اینڈپوائنٹ تیز ہے" ایسی بحث کو دعوت دیتا ہے جو ہوم پیج کے اسکور سے نہیں جیتی جا سکتی۔ OpenVPN 2.6 کا دستورالعمل اسٹیٹس فائل اور تشکیل کے اختیارات کو دستاویز کرتا ہے، اگر آپ کو ہوسٹ کی طرف کے درست ہدایات درکار ہوں۔