Прапусціце вялікі файл праз тунэль — і лічыльнік інтэрфейса вырасце на памер файла. Нішто ў гэтым ліку не азначае, што той жа аб’ём дасягнуў дыска. У такіх размовах параўноўваюць тры розныя вымярэнні, і яны адказваюць на тры розныя пытанні: колькі трафіку перасекла сеткавы ўзровень, колькі байтаў працэс прачытаў і запісаў праз сістэмныя выклікі, і колькі працы дасягнула ўзроўню захоўвання.

Параўнанне першага з трэцім — звычайная памылка, і яна спараджае альбо фантомную дыскавую праблему, альбо план ёмістасці, які ігнаруе запісы, што сапраўды адбываюцца. Гэтыя тры падзельныя, і кожнае мае правільнае ўжыванне.

Тры лікі, якія змешваюць

Лічыльнікі інтэрфейса апісваюць трафік, які апрацоўваецца на сеткавым узроўні. Яны — правільны лік для прапускной здольнасці, для памеру тунэля і для мадэляў білінгу, якія ацэньваюць транзіт.

Лічыльнікі сімвалаў працэсу апісваюць байты, перанесеныя праз выклікі чытання і запісу на любым дэскрыптары, уключаючы каналы, тэрміналы і сімвальныя прылады. Яны — правільны лік, каб спытаць, наколькі заняты працэс на мяжы сістэмнага выкліку, і яны не дыскавы рахунак.

Лічыльнікі захоўвання апісваюць байты, якія ядро спрабавала перанесці ў блочную прыладу або з яе. Яны — правільны лік для планавання ёмістасці, з агаворкай, што ядро дакументуе ўласныя межы ўліку: кэшаваныя чытанні не становяцца чытаннямі захоўвання, а запіс, які пазней скасавалі, не становіцца завершаным запісам на прыладу.

MeasurementQuestion it answers
Interface bytesHow much traffic crossed this layer
rchar and wcharHow much data the process moved through system calls
read_bytes and write_bytesHow much work reached the storage layer

Чаму дэскрыптар файла — не запіс на дыск

VPN у прасторы карыстальніка абменьваецца пакетамі з ядром праз прыладу TUN, якая з’яўляецца сімвальнай, а не звычайным файлам. Чытанне з яе перадае пакет; запіс у яе ўводзіць пакет. Ніякая старонка змесціва файла не рыхтуецца да захоўвання, і ніякі шлях файлавай сістэмы тут не задзейнічаны.

Таму заняты тунэль можа паказваць велізарныя лічыльнікі сімвалаў практычна без лічыльнікаў захоўвання. Працэс сапраўды перамясціў гэтыя байты, і ядру сапраўды не патрэбен быў дыск, каб гэта зрабіць.

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

Чытайце першы вывад як назапашаны з моманту запуску працэсу, а не як хуткасць. Другі дае від інтэрфейса на той жа трафік. Вялікая розніца паміж імі чаканая і не сведчыць пра ўцечку, чаргу або няправільную наладку.

Адкуль байты насамрэч бяруцца

У пастаяннага вываду свой бюджэт, і ім кіруюць аперацыі, а не карысная нагрузка. Шматслоўны ўзровень журнала, спіс кліентаў, які часта змяняецца, або памылка, што паўтараецца ў шчыльным цыкле, могуць ствараць істотныя запісы, пакуль тунэль пераносіць вельмі мала.

Файл стану — гэта здымак, які перазапісваецца праз інтэрвал, таму яго кошт залежыць ад інтэрвалу і ад колькасці запісаў у ім. Гэта не працоўная копія трафіку кожнага кліента, і скарачэнне інтэрвалу змяняе аб’ём запісу, не змяняючы аб’ём трафіку.

Уласнасць важная, калі вы шукаеце гэтыя запісы. Калі служба перадае паведамленні дэману журнала, то журнал або файл запісвае гэты дэман, і байты з’яўляюцца ў яго ўліку, а не ва ўласных лічыльніках працэсу VPN. Позірк толькі на працэс VPN не тлумачыць ні дыскавую актыўнасць, ні яе адсутнасць.

Іншых удзельнікаў лёгка не заўважыць: чытанне сертыфікатаў і канфігурацыі пры запуску, хуткія дзеянні, што пішуць уласныя запісы, плагіны ўліку, дампы падзенняў і незвязаныя нагрузкі на тым жа хасце. Ніводзін з іх не варта ацэньваць, прыраўноўваючы трафік тунэля да запісаных байтаў.

Як чытаць кожны лічыльнік правільна

Тры дэталі вырашаюць, ці нешта значыць параўнанне. Ідэнтычнасць працэсу важная, бо перазапушчаная служба скідвае свае лічыльнікі. Часавы інтэрвал важны, бо назапашаная лічба і графік за секунду — розныя вымярэнні. І адзінка важная, бо бягучы памер файла журнала таксама не хуткасць.

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

Калі вы падазраяце сапраўдныя запісы карыснай нагрузкі, шукайце кампанент, чыя праца — захоўваць нагрузку: сродак перахопу пакетаў, проксі, які кэшуе целы, плагін, што архівуе. Яны ствараюць дыскавы трафік, які маштабуецца з тым, што іх просяць запісаць, і належаць да асобнага палітычнага рашэння пра захаванне і доступ.

Планаванне ёмістасці правільным лікам

Памерыце шлях пакетаў сеткавымі лічбамі: прапускная здольнасць, крыптаграфічная апрацоўка і рух памяці. Памерыце захоўванне тымі выбарамі назіральнасці, якія вы сапраўды зрабілі: узровень журнала, захаванне, інтэрвал стану і любы перахоп, які свядома ўключаны.

Трыманне двух бюджэтаў асобна таксама палягчае чытанне інцыдэнтаў. Поўны дыск пры сціплым трафіку тунэля паказвае на журналы, перахопы або нешта незвязанае, і лічыльнік інтэрфейса ніколі гэтага не патлумачыць. Перапоўнены канал з ціхім журналам паказвае ў іншы бок.

Вартае параўнанне — паміж вымярэннямі аднаго віду. Байты інтэрфейса супраць байтаў інтэрфейса ў часе раскажуць пра шлях. Запісы на дыск супраць ёмістасці захоўвання раскажуць пра захаванне. Перакрыжаванае параўнанне, трафік супраць дыска, толькі выглядае значным і ніколі такім не бывае.

Падобныя артыкулы