کیا آپ کا VPN گیٹ وے CPU سے محدود ہے؟ پہلے ہر کور کا بوجھ پڑھیں
اوسط اہم تھریڈ کو چھپاتے ہیں۔ کنٹرول شدہ منتقلی کے دوران ہر کور کا بوجھ پڑھیں، راستہ خارج کریں، پھر ہر رن میں ایک دستاویزی ترتیب بدلیں۔
بڑا انسٹانس خریدنے سے پہلے طے کریں کہ آپ تین حدود میں سے کس تک پہنچے ہیں۔ ایک کور پوری طرح مصروف اور باقی خالی ہونا فی بہاؤ کریپٹو کام کی طرف اشارہ کرتا ہے۔ منتقلی کے دوران تمام کور سیر ہونا کل صلاحیت کی طرف اشارہ کرتا ہے۔ کم CPU اور بڑھتی ہوئی دوبارہ ترسیل کی تعداد راستے کی طرف اشارہ کرتی ہے۔ ہر ایک کا پہلا قدم مختلف ہے، اور ان میں سے صرف ایک بڑے انسٹانس سے حل ہوتا ہے۔
تین حدود، ایک جدول، تین اصلاحیں
| Limit | Reading during a transfer | First move |
|---|---|---|
| Single thread | one core near 100%, siblings idle | spread flows across workers |
| Aggregate CPU | every core busy, load average climbs | capacity, or less work per byte |
| Path or provider | low CPU, retransmits or steal time high | MTU, loss, host contention |
قطاریں مرحلوں کے بجائے تشخیص کے طور پر پڑھیں۔ ایک تھریڈ 100% پر اور باقی خالی ہونا ایک بڑی سرنگ لے جانے والے گیٹ وے پر سب سے عام نتیجہ ہے، کیونکہ اس بہاؤ کی انکرپشن ایک ہی کور پر چلتی ہے۔ منتقلی کے دوران تمام کور مصروف ہونا یعنی مشین پہلے ہی پوری صلاحیت سے کام کر رہی ہے۔ کم CPU اور بڑھتی ہوئی دوبارہ ترسیل یعنی پروسیسر ایسے نیٹ ورک کا انتظار کر رہا ہے جو مسلسل ڈیٹا گراتا ہے۔
انہیں ثبوت کی اسی ترتیب سے درست کریں۔ بہاؤ کو ورکرز میں پھیلانا پہلی صورت میں مدد کرتا ہے اور دوسری کے لیے کچھ نہیں کرتا۔ بڑا انسٹانس دوسری میں مدد کرتا ہے اور پہلی پر پیسہ ضائع کرتا ہے۔ MTU یا نقصان کی اصلاح ہی واحد ہے جو تیسری کو چھوتی ہے۔ یہ جاننے سے پہلے صلاحیت خریدنے کہ آپ کس قطار میں ہیں اندازے کا مہنگا نسخہ ہے۔
پھنسے ہوئے تھریڈ کو مصروف ہوسٹ سے الگ کریں
فی کور استعمال سے شروع کریں، تاکہ پھنسا ہوا ایک کور اوسط میں چھپ نہ سکے۔ منتقلی کے دوران ایک رن دکھاتا ہے کہ بوجھ ہموار ہے یا چوٹیوں والا۔ دونوں شکلیں معلوماتی ہیں، اور چوٹیوں والا پروفائل اکثر یعنی یہ کہ سیمپلنگ ونڈو نے انکرپشن کے بجائے شیڈولر کی سرگرمی پکڑی۔
mpstat -P ALL 1 5مصروف کور کو ایک پراسیس سے اور پھر ایک تھریڈ سے منسوب کریں۔ نیچے کا فالو اپ رن والدین اور بچہ تھریڈ کو ساتھ رکھتا ہے، جو اس وقت اہم ہے جب ڈیمون ہر کنکشن کے لیے فورک کرتا ہے:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10کرنل کریپٹو کبھی یوزر اسپیس پراسیس کاؤنٹر میں ظاہر نہیں ہوتا۔ تھریڈز کو الگ سیمپل کریں اور اس منظر کا پراسیس حساب سے موازنہ کریں:
top -H -b -n 1 | head -20ساکٹ کاؤنٹر سب سے آخر میں پڑھیں، کیونکہ وہی طے کرتے ہیں کہ زیادہ CPU بالکل مدد کرے گا یا نہیں۔ CPU ہموار ہوتے ہوئے دوبارہ ترسیل بڑھنا پروسیسر کا مسئلہ نہیں۔ سیمپلنگ کے دوران منتقلی جاری رکھیں، ورنہ اعداد خالی مشین بیان کریں گے:
ss -ti | grep -E 'retrans|cwnd|rtt'کنٹرول شدہ منتقلی، دو بار
خالی کاؤنٹر کچھ ثابت نہیں کرتے، اور کسی بے ترتیب اینڈ پوائنٹ کے خلاف بینچ مارک بہت کم ثابت کرتا ہے۔ ایک کلائنٹ، ایک منزل اور ایک نمائندہ منتقلی منتخب کریں جسے چلانے کی اجازت ہے، پھر اسی ونڈو میں تھروپٹ اور متعامل تاخیر ریکارڈ کریں۔ گیٹ وے سیر ہو سکتا ہے جبکہ بڑی کاپی ابھی مکمل ہو رہی ہو، اور تاخیر کا منحنی خط ہی وہ ہے جو صارفین واقعی محسوس کرتے ہیں۔ منتقلی، کلائنٹ تعداد اور ڈیمون ورژن اعداد کے ساتھ لکھیں۔
کئی متوازی بہاؤ کے ساتھ رن دہرائیں۔ بہاؤ میں اضافہ فی بہاؤ ونڈو کی طرف اشارہ کرتا ہے؛ ایک کور پھنسا ہونے پر بھی ہموار رہنا پروسیسنگ کی طرف اشارہ کرتا ہے۔
پھر اختیاری کام کے بوجھ بند کر کے ایک بار مزید دہرائیں۔ اسی ہوسٹ پر بیک اپ، لاگ بھیجنے والا یا ڈیٹا بیس سرنگوں سے بے تعلق مصروف اوسط بنا سکتے ہیں۔ اگر ہوسٹ ورنہ خاموش ہے اور CPU اب بھی پھنسا ہے، تو ثبوت VPN پراسیس کی طرف اشارہ کرتے ہیں۔ اگر یہ گرے، تو آپ پڑوسی کی پیمائش کر رہے تھے، اور گیٹ وے کبھی مسئلہ نہیں تھا۔
ہارڈویئر خریدنے سے پہلے راستہ خارج کریں
بڑھتی ہوئی دوبارہ ترسیل، سکڑتی ہوئی بھیڑ کی ونڈو اور بڑھتا ہوا آنے جانے کا وقت سب پروسیسر سے دور اشارہ کرتے ہیں۔ سرنگ کے MTU کا راستے کے MTU سے موازنہ کریں، بنیادی لنک میں نقصان جانچیں، اور تصدیق کریں کہ کلائنٹ کا اپنا اپ لنک حد نہیں ہے۔ بڑا گیٹ وے پیکٹ گرانے والے لنک کی مرمت نہیں کرتا، اور صارفین دونوں خرابیوں کو ایک ہی الفاظ میں بیان کرتے ہیں۔ دوبارہ ترسیل کا کاؤنٹر انہیں منٹوں میں الگ کرتا ہے۔
ورچوئل سرور پر، فراہم کنندہ کے میٹرکس مہمان کے اپنے میٹرکس میں شامل کریں۔ چرایا گیا وقت وہ ہے کہ کس طرح زیادہ فروخت مہمان کے اندر نظر آتی ہے، اور مہمان کے اندر کوئی ٹیوننگ اسے نہیں ہٹاتی۔ مہمان کے کاؤنٹر ہوسٹ نہیں دیکھ سکتے، اس لیے صاف مہمان گراف صحت مند ہوسٹ کا ثبوت نہیں ہے۔
ایک تبدیلی، ایک پیمائش
وہ مفروضہ منتخب کریں جس کی ثبوت تائید کرتے ہیں، پھر بالکل ایک معاون ترتیب بدلیں: ورکرز کی تعداد، دستاویزی آف لوڈ آپشن، یا انسٹانس کا حجم۔ OpenVPN پروسیسنگ اور نقل و حمل کے درمیان اسی تقسیم پر کارکردگی کے مسئلے کی رہنمائی شائع کرتا ہے: OpenVPN کارکردگی مسئلہ حل۔
جھنڈے پر بھروسہ کرنے کے بجائے تصدیق کریں کہ آف لوڈ آپشن واقعی فعال ہے، پھر وہی منتقلی دوبارہ چلائیں اور مماثل کا مماثل سے موازنہ کریں۔ حقیقی بہتری کو خاموش دوپہر سے الگ کرنے کا یہی واحد طریقہ ہے۔ بحال کرنے کے قابل چیک پوائنٹ رکھیں، کیونکہ دوسری تبدیلی میں لوگ بھول جاتے ہیں کہ کس نے مدد کی۔ ہر رن میں ایک متغیر ایک دن کے لیے سست اور ایک مہینے کے لیے تیز ہے۔
گراف بہتر دکھانے کے لیے توثیق یا سائفر سیٹ کمزور نہ کریں۔ اگر CPU اب بھی علامت کی پیروی نہیں کر رہا، تو اندازے پر اپ گریڈ کرنے کے بجائے راستے اور ایپلیکیشن کی جانچ پر واپس جائیں۔