د 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 لارښود د حالت فایل او د جوړونې اختیارونه مستند کوي، که د هوسټ اړخ لپاره دقیق لارښوونې ته اړتیا ولرئ۔