Lav gjennomstrømning gjennom en tunnel og en maskin som henger og venter på tilfeldige tall gir svært forskjellige opplevelser, men de registreres likevel under samme klage. Det ene viser seg som en pause før noe virker. Det andre viser seg som en forbindelse som virker og flytter data sakte så lenge du ser på. Å avgjøre hvilken du har tar ti minutter og sparer en uke med gjetting.

To symptomer som ser like ut

En tjeneste som henger etter en fersk oppstart, før den godtar en eneste forbindelse, venter på noe. En tunnel som etableres raskt og deretter overfører med en brøkdel av forventet hastighet, begrenses av noe annet. Ordet kryptering dukker opp i begge historiene, og derfor slås de sammen. Skill dem før du rører en konfigurasjonsfil.

Sett tidsstempler rundt oppstart, autentisering, ny forhandling av nøkler og selve overføringen. En lang forsinkelse før tunnelen er brukbar er ikke en lav jevn hastighet, og å gjennomsnittliggjøre de to til ett tall ødelegger beviset.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

De to første kommandoene setter oppstartsarbeidet på en tidslinje. Den tredje skriver ut kjernens entropiregnskapsverdi, som er nyttig som ett datapunkt og ubrukelig som båndbreddemåler.

Hvordan en venting på tilfeldige tall faktisk ser ut

En forespørsel om sikre tilfeldige byte kan blokkere til kjernen har initialisert sin tilfeldige kilde. Det betyr mest på virtuelle maskiner og små innebygde kort tidlig i oppstarten, når lite miljøstøy er samlet. Det følger ikke at hver kryptert byte bruker fersk entropi.

Moderne generatorer seeds én gang og produserer deretter utdata fra en deterministisk konstruksjon, og reseeder etter sin egen plan. Bulkoverføring tømmer ikke en pool byte for byte, så en lav poolverdi under en treg overføring beviser ingenting om årsaken.

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

Den første kommandoen viser om prosessen sitter i et tilfeldigtall-kall mens du ser på. Den andre viser kjernens egne initialiseringsmeldinger, og det er der en tidlig oppstartsforsinkelse blir synlig.

Noter kjerneversjonen og biblioteket tjenesten faktisk lenker mot, fordi atferden varierer mellom implementasjoner og mellom utgivelser. Et trace tatt etter gjenoppretting misser vanligvis pausen helt.

Hvordan vedvarende treghet faktisk ser ut

En tunnel som overfører sakte hele tiden, begrenses av datastien. Én mettet tråd, tap av ytre pakker, retransmisjoner eller fulle socketkøer produserer hver det mønsteret, og hver har sin egen rettelse. Samlet CPU-prosent skjuler én opptatt tråd, og det er den vanligste feillesningen. Se på tid per tråd før du ser på total belastning.

Mål i begge retninger med en sammenlignbar grunnlinje, og følg med på grensesnittets tellere i stedet for applikasjonens egen rapport.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

Den første kommandoen viser kø- og overbelastningstilstand for én peer. Den andre og tredje rapporterer dropp og retransmisjoner i stakken og på grensesnittet, der årsaken vanligvis dukker opp først.

Velg rettelsen for flaskehalsen du målte

Hvis bevisene peker på tidlig oppstartsinitialisering, se på plattformens støttede seeding-sti, som på en virtuell maskin kan omfatte en vertslevert tilfeldig enhet. Et seed-bilde kopiert uendret til mange gjester er ikke en erstatning for uavhengig initialisering.

Hvis bevisene peker på datastien, juster det tellerne peker på. Bufferstørrelser hjelper når køer flyter over, og gjør ingenting når én tråd er mettet. Å installere en entropi-demon for å heve en teller er ingen gjennomstrømningsreparasjon, og å endre seeding-antakelser for å få en graf til å se bedre ut bytter en sikkerhetsegenskap mot et tall.

Godta endringen bare når samme måling blir bedre under samme forhold. En større teller er ikke et resultat; en kortere målt ventetid eller en raskere overføring med identifisert årsak er det.

Relaterte artikler