OpenVPN trafika skaitītāji pret diska I/O: trīs dažādi skaitļi

Izlaidiet lielu failu caur tuneli, un interfeisa skaitītājs pieaug par faila lielumu. Nekas šajā skaitlī nenozīmē, ka tas pats apjoms sasniedza disku. Šajās diskusijās tiek salīdzināti trīs dažādi mērījumi, un tie atbild uz trim dažādiem jautājumiem: cik daudz trafika šķērsoja tīkla slāni, cik baitu process nolasīja un ierakstīja ar sistēmas izsaukumiem, un cik daudz darba sasniedza glabāšanas slāni.

Pirmo salīdzināt ar trešo ir ierasta kļūda, un tā rada vai nu fiktīvu diska problēmu, vai arī ietilpības plānu, kas ignorē ierakstus, kuri patiešām notiek. Visi trīs ir atdalāmi, un katram ir pareizs lietojums.

Trīs skaitļi, kas tiek sajaukti

Interfeisa skaitītāji apraksta trafiku, kas tiek apstrādāts tīkla slānī. Tie ir pareizais skaitlis joslas platumam, tuneļa izmēram un norēķinu modeļiem, kas nosaka cenu tranzītam.

Procesa rakstzīmju skaitītāji apraksta baitus, kas pārvietoti ar lasīšanas un rakstīšanas izsaukumiem jebkurā deskriptorā, tostarp caurulēs, termināļos un rakstzīmju ierīcēs. Tie ir pareizais skaitlis, lai jautātu, cik aizņemts ir process pie sistēmas izsaukuma robežas, un tie nav glabāšanas rēķins.

Glabāšanas skaitītāji apraksta baitus, ko kodols mēģināja pārvietot uz bloka ierīci vai no tās. Tie ir pareizais skaitlis ietilpības plānošanai, ar nosacījumu, ka kodols dokumentē savas uzskaites robežas: kešatmiņā saglabātas lasīšanas nekļūst par glabāšanas lasīšanām, un vēlāk atcelts ieraksts nekļūst par pabeigtu ierīces ierakstu.

Kāpēc faila deskriptors nav ieraksts diskā

Lietotāja telpas VPN apmainās ar paketēm ar kodolu caur TUN ierīci, kas ir rakstzīmju ierīce, nevis parasts fails. Lasīšana no tās nodod paketi; rakstīšana tajā ievada paketi. Nav nevienas faila satura lapas, kas tiktu sagatavota glabāšanai, un nav iesaistīts neviens failu sistēmas ceļš.

Tāpēc aizņemts tunelis var rādīt milzīgus rakstzīmju skaitītājus gandrīz bez glabāšanas skaitītājiem. Process patiešām pārvietoja šos baitus, un kodolam patiešām nebija vajadzīgs disks, lai to izdarītu.

cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0

Lasiet pirmo izvadi kā uzkrātu kopš procesa palaišanas, nevis kā ātrumu. Otrais dod tā paša trafika interfeisa skatu. Liela atstarpe starp abiem ir gaidāma un neliecina par noplūdi, rindu vai nepareizu konfigurāciju.

No kurienes baiti patiešām nāk

Pastāvīgajai izvadei ir savs budžets, un to virza darbības, nevis lietderīgā slodze. Detalizēts žurnāla līmenis, bieži mainīgs klientu saraksts vai kļūda, kas atkārtojas ciešā cilpā, var radīt ievērojamus ierakstus, kamēr tunelis pārvieto ļoti maz.

Statusa fails ir momentuzņēmums, kas tiek pārrakstīts ar noteiktu intervālu, tāpēc tā izmaksas ir atkarīgas no intervāla un no tajā esošo ierakstu skaita. Tas nav katra klienta trafika tekoša kopija, un intervāla saīsināšana maina ierakstu apjomu, nemainot trafika apjomu.

Īpašumtiesības ir svarīgas, kad meklējat šos ierakstus. Ja pakalpojums nodod ziņojumus žurnāla dēmonam, žurnālu vai žurnāla failu raksta tas dēmons, un baiti parādās dēmona uzskaitē, nevis paša VPN procesa skaitītājos. Skatīšanās tikai uz VPN procesu neizskaidro ne diska aktivitāti, ne tās neesamību.

Citus devējus ir viegli nepamanīt: sertifikātu un konfigurācijas lasīšana palaišanas laikā, āķi, kas raksta savus ierakstus, uzskaites spraudņi, avārijas atmiņas izgāztuves un nesaistītas darba slodzes tajā pašā resursdatorā. Nevienu no tiem nevajadzētu novērtēt, pielīdzinot tuneļa trafiku ierakstītajiem baitiem.

Korekti lasīt katru skaitītāju

Trīs detaļas nosaka, vai salīdzinājumam ir jēga. Procesa identitāte ir svarīga, jo restartēts pakalpojums atiestata savus skaitītājus. Laika intervāls ir svarīgs, jo uzkrātais skaitlis un grafiks sekundē ir dažādi mērījumi. Un mērvienība ir svarīga, jo arī žurnāla faila pašreizējais lielums nav ātrums.

grep -E 'rchar|wchar|read_bytes|write_bytes' /proc/$(pgrep -n openvpn)/io
du -sh /var/log/openvpn 2>/dev/null
journalctl --disk-usage

Ja jums ir aizdomas par īstiem lietderīgās slodzes ierakstiem, meklējiet komponentu, kura uzdevums ir glabāt lietderīgo slodzi: pakešu tveršanas rīku, starpniekserveri, kas kešatmiņā glabā saturu, spraudni, kas arhivē. Tie rada glabāšanas trafiku, kas pieaug atbilstoši tam, ko tiem lūdz ierakstīt, un tie pieder pie atsevišķa politikas lēmuma par glabāšanas laiku un piekļuvi.

Ietilpības plānošana ar pareizo skaitli

Mēriet pakešu ceļu ar tīkla skaitļiem: caurlaidspēju, kriptogrāfisko apstrādi un atmiņas kustību. Mēriet glabāšanu ar tiem novērojamības lēmumiem, kurus jūs patiešām pieņēmāt: žurnāla līmeni, glabāšanas laiku, statusa intervālu un jebkuru apzināti iespējotu tveršanu.

Šo divu budžetu šķiršana atvieglo arī incidentu lasīšanu. Pilns disks ar pieticīgu tuneļa trafiku norāda uz žurnāliem, tveršanām vai kaut ko nesaistītu, un interfeisa skaitītājs to nekad neizskaidros. Piesātināta saite ar klusu žurnālu norāda pretējā virzienā.

Salīdzinājums, ko ir vērts veikt, ir starp viena veida mērījumiem. Interfeisa baiti pret interfeisa baitiem laika gaitā stāsta par ceļu. Glabāšanas ieraksti pret glabāšanas ietilpību stāsta par glabāšanas laiku. Šķērssalīdzinājums, trafiks pret disku, tikai izskatās jēgpilns un nekad tāds nav.