Објаснето оптоварување на 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 ги документира статусната датотека и опциите за обликување ако ви требаат точните директиви за страната на домаќинот.