Carga do servidor VPN explicada: usuarios, CPU ou enlace de subida?
Unha puntuación de carga baixa pode significar usuarios inactivos, CPU de sobra ou un enlace de subida amplo. Le loadavg, os contadores de interface e o ficheiro de estado antes de chamalo rápido.
Unha pasarela cunha carga de 0.4 aínda pode arrastrarse para cada usuario que ten detrás. A carga media conta as tarefas executables ou atascadas nun soño ininterrompible, e nun host de catro núcleos abonda un só proceso saturado para empurrala cara a 1.0 mentres tres núcleos están ociosos. Ler esa cifra como marxe dispoñible é o erro máis común ao escoller un punto final. O que realmente limita un túnel adoita ser unha de catro cousas: un núcleo ocupado, o enlace de subida, a cola que ten diante ou unha política por sesión que ninguén documentou.
A carga media conta tarefas, non caudal
O núcleo mostra a cola de execución e o número de tarefas que esperan entrada e saída, e despois suaviza ambos ao longo dun, cinco e quince minutos. Nada nesa definición menciona bytes, paquetes nin túneles. Un host co almacenamento atascado pode informar dunha carga alta con case ningún tráfico, e un host que empurra un gigabit por unha ruta de datos do núcleo pode informar dunha carga cómoda.
Por tanto, correlacionar a carga co rendemento do túnel esixe unha visión por núcleo. Se un núcleo está saturado, a porcentaxe agregada do panel seguirá parecendo correcta:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20O terceiro comando é o que máis importa nos hosts VPN. O procesamento de paquetes en espazo de usuario de OpenVPN 2.x está en gran medida serializado por proceso, así que un só fío ocupado pode converterse no teito mentres o panel informa de abundante capacidade ociosa. Se un fío acapara a maior parte dun núcleo durante o teu período lento, o host non está infradimensionado no conxunto; está limitado na dimensión que resulta ser a que importa.
Fíxate tamén no momento. As medias de quince minutos agochan o pico que arruinou unha chamada, así que unha captura tomada despois da queixa é unha proba débil. Toma mostras durante o problema e garda a marca de tempo xunto coa saída.
O enlace de subida e a cola que ten diante
Os contadores de interface responden á pregunta do ancho de banda que as cifras de CPU non poden. Tamén separan a capacidade da perda, que son fallos distintos con solucións distintas:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitUn enlace que durante a túa proba está preto da súa velocidade asignada é a explicación, e ningunha cantidade de CPU libre o cambia. A liña de qdisc engade o detalle que importa para o tráfico interactivo: a acumulación e as perdas dinche se os paquetes esperan nunha cola antes de saír. Unha cola que se enche baixo unha subida masiva produce exactamente o síntoma que a xente atribúe ao servidor remoto, chamadas lentas nunha conexión que aínda dá bo resultado nas probas.
Os contadores de retransmisión capturan o caso no que os paquetes saen pero nunca chegan limpos. Se as retransmisións soben durante a xanela lenta e a interface está moi lonxe da capacidade, o problema está na ruta e non no host, e cambiarse a outro punto final na mesma cidade non axudará.
Os recontos de sesións describen a demanda, non a marxe
Cada directorio público mostra un número de usuarios conectados, e case ningún che di que fan eses usuarios. Vinte sesións facendo traballo interactivo e catro sesións baixando ficheiros grandes producen cargas moi distintas no mesmo hardware. O segundo patrón é invisible nun reconto de usuarios, e é o que arruína unha tarde. Así que un número de sesións lese mellor como unha pista sobre a demanda, nunca como unha afirmación sobre a capacidade libre.
| 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 |
Nun host que controlas, o ficheiro de estado dá a dimensión que falta. OpenVPN escribe unha instantánea periódica que inclúe contadores de bytes por cliente, o que abonda para ver se unha soa sesión é responsable de todo o enlace de subida:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusDúas mostras separadas dez segundos converten eses contadores acumulados nunha taxa por cliente. Esa é a medición que suple un reconto de usuarios, e tamén é como descobres que un só cliente mal configurado satura o enlace cada noite á mesma hora.
Os límites por sesión escóndense na política
Un servidor pode estar ocioso e aínda así negarche ancho de banda. Os límites de taxa, os topes de ancho de banda por cliente e a modelaxe de tráfico adoitan aplicarse por nome común ou por grupo, así que dous usuarios na mesma pasarela poden obter resultados moi distintos. O mecanismo non é sutil, pero é invisible desde fóra porque o túnel levanta con normalidade en ambos os casos.
Busca a modelaxe na interface do túnel e non na física. Comproba se o límite segue o usuario, o certificado ou o grupo de enderezos. Se a túa conta de proba cae no grupo sen tope, concluirás que o servidor está ben e que o usuario que se queixa se equivoca. Esa conclusión é peor que ningunha, porque pecha o ticket.
Compara dous puntos finais cunha mesma tarefa fixa
O experimento do lado do cliente aínda paga a pena, pero só se as variables están fixadas. Usa o mesmo dispositivo, a mesma rede de acceso, o mesmo protocolo e o mesmo ficheiro de destino, e despois repite contra un segundo punto final a unha distancia similar. Calquera cousa que cambie entre execucións, incluída a hora do día, contamina o resultado.
Rexistra os fallos con tanto coidado coma os éxitos. Unha serie na que tres puntos finais funcionan e un esgota por tempo é máis informativa que catro cifras de velocidade, porque apunta a un problema de ruta ou de política e non de capacidade. Executa cada caso polo menos dúas veces; unha soa mostra lenta non demostra nada nunha rede compartida.
Por último, garda as cifras que reuniste xunto coa afirmación que apoian. "Este punto final completou a transferencia na mesma xanela na que o outro se atascou" é defendible, mentres que "este punto final é máis rápido" invita a unha discusión que non podes gañar cunha puntuación de portada. O manual de OpenVPN 2.6 documenta o ficheiro de estado e as opcións de modelaxe se necesitas as directivas exactas do lado do host.