Ձեր VPN դարպասը սահմանափակվա՞ծ է պրոցեսորով։ Սկզբում կարդացեք բեռը միջուկով
Միջինները թաքցնում են կարևոր թելը։ Կարդացեք բեռը միջուկով վերահսկվող փոխանցման ընթացքում, բացառեք ուղին, ապա յուրաքանչյուր վազքում փոխեք մեկ փաստաթղթավորված կարգավորում։
Որոշեք, թե երեք սահմաններից որին եք հասել, նախքան ավելի մեծ ինստանս գնելը։ Մեկ միջուկը լրիվ զբաղված, իսկ մնացածը՝ պարապ, վկայում է հոսքով մեկ ծպտյալ աշխատանքի մասին։ Փոխանցման ընթացքում բոլոր միջուկների հագեցվածությունը վկայում է ընդհանուր հզորության մասին։ Ցածր պրոցեսոր և ավելացող վերահաղորդումների քանակը վկայում են ուղու մասին։ Յուրաքանչյուրն ունի տարբեր առաջին քայլ, և դրանցից միայն մեկն է լուծվում ավելի մեծ ինստանսով։
Երեք սահման, մեկ աղյուսակ, երեք ուղղում
| 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%-ով, մինչ մյուսները պարապ են, ամենատարածված արդյունքն է մեկ մեծ թունել կրող դարպասի վրա, որովհետև այդ հոսքի գաղտնագրումը աշխատում է մեկ միջուկի վրա։ Փոխանցման ընթացքում բոլոր միջուկների զբաղված լինելը նշանակում է, որ մեքենան արդեն անում է այնքան աշխատանք, որքան կարող է։ Ցածր պրոցեսոր և աճող վերահաղորդումներ նշանակում են, որ պրոցեսորը սպասում է ցանցի, որը շարունակ տվյալներ է կորցնում։
Ուղղեք դրանք ապացույցների այդ հերթականությամբ։ Հոսքերը աշխատողների միջև բաշխելը օգնում է առաջին դեպքին և ոչինչ չի անում երկրորդի համար։ Ավելի մեծ ինստանսը օգնում է երկրորդին և փող է վատնում առաջինի վրա։ MTU-ի կամ կորստի ուղղումը միակն է, որը դիպչում է երրորդին։ Հզորություն գնել նախքան իմանալը, թե որ տողում եք գուշակելու թանկ տարբերակն է։
Առանձնացրեք ամրացված թելը զբաղված հոսթից
Սկսեք միջուկով մեկ օգտագործումից, որպեսզի մեկ ամրացված միջուկը չկարողանա թաքնվել միջինի մեջ։ Փոխանցման ընթացքում մեկ վազքը ցույց է տալիս՝ բեռը հարթ է, թե գագաթներով։ Երկու ձևերն էլ տեղեկատվական են, և գագաթներով պրոֆիլը հաճախ նշանակում է, որ նմուշառման պատուհանը բռնել է պլանավորողի ակտիվությունը, այլ ոչ գաղտնագրումը։
mpstat -P ALL 1 5Վերագրեք զբաղված միջուկը պրոցեսին, ապա թելին։ Ստորև բերված հետևող վազքը միասին է պահում ծնող և զավակ թելերը, ինչը կարևոր է, երբ դեմոնը ճյուղավորվում է յուրաքանչյուր կապի համար:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10Միջուկի գաղտնագրումը երբեք չի երևում օգտվողի տարածության պրոցեսի հաշվիչում։ Նմուշառեք թելերը առանձին և համեմատեք այդ տեսքը պրոցեսի հաշվառման հետ:
top -H -b -n 1 | head -20Սոկետների հաշվիչները կարդացեք վերջինը, որովհետև դրանք որոշում են՝ ավելի շատ պրոցեսորը ընդհանրապես կօգնի՞։ Հարթ պրոցեսորի դեպքում աճող վերահաղորդումները պրոցեսորի խնդիր չեն։ Նմուշառելիս թողեք փոխանցումը աշխատի, այլապես թվերը կնկարագրեն պարապ մեքենա:
ss -ti | grep -E 'retrans|cwnd|rtt'Վերահսկվող փոխանցում, կատարված երկու անգամ
Պարապ հաշվիչները ոչինչ չեն ապացուցում, և պատահական վերջնակետի դեմ չափումը շատ քիչ բան է ապացուցում։ Ընտրեք մեկ հաճախորդ, մեկ նպատակակետ և մեկ ներկայացուցչական փոխանցում, որը ձեզ թույլատրված է կատարել, ապա նույն պատուհանում գրանցեք թողունակությունը և ինտերակտիվ ուշացումը։ Դարպասը կարող է հագենալ, մինչ զանգվածային պատճենումը դեռ ավարտվում է, և ուշացման կորը հենց այն է, ինչ օգտվողները իրականում զգում են։ Փոխանցումը, հաճախորդների քանակը և դեմոնի տարբերակը գրեք թվերի կողքին։
Կրկնեք վազքը մի քանի զուգահեռ հոսքերով։ Հոսքերի միջով աճը հուշում է հոսքով մեկ պատուհաններ; մեկ ամրացված միջուկի դեպքում հարթ մնալը հուշում է մշակում։
Ապա ևս մեկ անգամ կրկնեք՝ անջատված լրացուցիչ աշխատանքային բեռներով։ Նույն հոսթի վրա պահուստավորումը, մատյան ուղարկիչը կամ տվյալների բազան կարող են ստեղծել զբաղված միջին, որը կապ չունի թունելների հետ։ Եթե պրոցեսորը դեռ ամրացված է, իսկ հոսթը հակառակ դեպքում հանգիստ է, ապացույցները ցույց են տալիս VPN պրոցեսին։ Եթե այն ընկնում է, դուք չափում էիք հարևանին, և դարպասը երբեք խնդիրը չի եղել։
Բացառեք ուղին նախքան սարքավորում գնելը
Աճող վերահաղորդումները, նեղացող գերբեռնվածության պատուհանը և աճող շրջագայության ժամանակը բոլորը ցույց են տալիս հեռու պրոցեսորից։ Համեմատեք թունելի MTU-ն ուղու MTU-ի հետ, ստուգեք հիմքում ընկած կապը կորստի համար և հաստատեք, որ հաճախորդի սեփական uplink-ը սահմանը չէ։ Ավելի մեծ դարպասը չի վերանորոգում փաթեթներ կորցնող կապը, և օգտվողները երկու անսարքություններն էլ նկարագրում են նույն բառերով։ Վերահաղորդումների հաշվիչը դրանք բաժանում է րոպեների ընթացքում։
Վիրտուալ սերվերի վրա ավելացրեք մատակարարի չափիչները հյուրի սեփականին։ Գողացված ժամանակը այն է, թե ինչպես է գերավաճառքը տեսանելի դառնում հյուրի ներսում, և հյուրի ներսում ոչ մի կարգավորում այն չի հեռացնում։ Հյուրի հաշվիչները չեն տեսնում հոսթը, ուստի մաքուր հյուրի գրաֆիկը առողջ հոսթի ապացույց չէ։
Մեկ փոփոխություն, մեկ չափում
Ընտրեք այն վարկածը, որն ապացույցները պաշտպանում են, ապա փոխեք ճիշտ մեկ աջակցվող կարգավորում՝ աշխատողների քանակը, փաստաթղթավորված offload տարբերակը կամ ինստանսի չափը։ OpenVPN-ը հրապարակում է աշխատանքի խափանումների վերացման ուղեցույց մշակման և տրանսպորտի նույն բաժանման մասին:OpenVPN աշխատանքի խափանումների վերացում։
Հաստատեք, որ offload տարբերակն իսկապես ակտիվ է՝ դրոշակին վստահելու փոխարեն, ապա նորից գործարկեք նույն փոխանցումը և համեմատեք նմանը նմանով։ Սա միակ միջոցն է իրական բարելավումը հանգիստ կեսօրից տարբերելու։ Պահեք վերականգնվող ստուգման կետ, որովհետև երկրորդ փոփոխության ժամանակ մարդիկ կորցնում են հետքը, թե որն օգնեց։ Վազքով մեկ փոփոխականը դանդաղ է մեկ օրվա և արագ՝ մեկ ամսվա համար։
Մի թուլացրեք նույնականացումը կամ ծածկագրերի հավաքածուն, որպեսզի գրաֆիկը ավելի լավ երևա։ Եթե պրոցեսորը դեռ չի հետևում ախտանիշին, վերադարձեք ուղու և հավելվածի ստուգումներին՝ գուշակությամբ թարմացնելու փոխարեն։