OpenVPN ట్రాఫిక్ కౌంటర్లు మరియు డిస్క్ I/O: మూడు వేర్వేరు సంఖ్యలు
ఇంటర్ఫేస్ బైట్లు, ప్రక్రియ అక్షర కౌంటర్లు మరియు నిల్వ రాతలు వేర్వేరు పనిని కొలుస్తాయి. సొరంగ పరిమాణం నుంచి డిస్క్లను అంచనా వేసే ముందు వాటిని పోల్చండి.
పెద్ద ఫైల్ను సొరంగం ద్వారా పంపండి; ఇంటర్ఫేస్ కౌంటర్ ఫైల్ పరిమాణం మేరకు పెరుగుతుంది. ఆ సంఖ్యలో అదే పరిమాణం డిస్క్కు చేరిందని చెప్పేది ఏమీ లేదు. ఈ చర్చల్లో మూడు వేర్వేరు కొలతలు పోల్చబడతాయి, అవి మూడు వేర్వేరు ప్రశ్నలకు జవాబిస్తాయి: ఎంత ట్రాఫిక్ నెట్వర్క్ పొరను దాటింది, ఒక ప్రక్రియ సిస్టమ్ కాల్స్ ద్వారా ఎన్ని బైట్లు చదివింది మరియు రాసింది, మరియు ఎంత పని నిల్వ పొరకు చేరింది.
మొదటిదాన్ని మూడవదానితో పోల్చడం సాధారణ పొరపాటు, అది నకిలీ డిస్క్ సమస్యను లేదా నిజంగా జరిగే రాతలను పట్టించుకోని సామర్థ్య ప్రణాళికను సృష్టిస్తుంది. మూడూ వేరు చేయగలిగేవి, ప్రతిదానికీ సరైన వినియోగం ఉంది.
గందరగోళపరిచే మూడు సంఖ్యలు
ఇంటర్ఫేస్ కౌంటర్లు నెట్వర్క్ పొరలో నిర్వహించే ట్రాఫిక్ను వివరిస్తాయి. బ్యాండ్విడ్త్, సొరంగ పరిమాణం మరియు ప్రయాణానికి ధర విధించే బిల్లింగ్ నమూనాలకు ఇదే సరైన సంఖ్య.
ప్రక్రియ అక్షర కౌంటర్లు పైపులు, టెర్మినల్స్ మరియు అక్షర పరికరాలతో సహా ఏ డిస్క్రిప్టర్పైనా చదవడం మరియు రాయడం కాల్స్ ద్వారా కదిలిన బైట్లను వివరిస్తాయి. సిస్టమ్ కాల్ సరిహద్దులో ప్రక్రియ ఎంత బిజీగా ఉందో అడగడానికి ఇదే సరైన సంఖ్య, ఇది నిల్వ బిల్లు కాదు.
నిల్వ కౌంటర్లు కెర్నల్ బ్లాక్ పరికరంలోకి లేదా దాని నుంచి కదిలించడానికి ప్రయత్నించిన బైట్లను వివరిస్తాయి. సామర్థ్య ప్రణాళికకు ఇదే సరైన సంఖ్య, అయితే కెర్నల్ తన సొంత లెక్కింపు పరిమితులను నమోదు చేస్తుంది అనే షరతుతో: కాష్లో ఉన్న చదవడాలు నిల్వ చదవడాలు కావు, తర్వాత రద్దయ్యే రాత పూర్తయిన పరికర రాత కాదు.
| Measurement | Question it answers |
|---|---|
| Interface bytes | How much traffic crossed this layer |
rchar and wchar | How much data the process moved through system calls |
read_bytes and write_bytes | How 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
నిజమైన పేలోడ్ రాతలు అనుమానిస్తే, పేలోడ్ను నిల్వ చేయడం పని అయిన ఒక భాగాన్ని వెతకండి: ప్యాకెట్ క్యాప్చర్ సాధనం, బాడీలను కాష్ చేసే ప్రాక్సీ, ఆర్కైవ్ చేసే ప్లగిన్. ఇవి రికార్డు చేయమని అడిగిన దాని ప్రకారం పెరిగే నిల్వ ట్రాఫిక్ను సృష్టిస్తాయి, అవి నిల్వ మరియు ప్రవేశం గురించిన ప్రత్యేక విధాన నిర్ణయానికి చెందుతాయి.
సరైన సంఖ్యతో సామర్థ్య ప్రణాళిక
ప్యాకెట్ మార్గాన్ని నెట్వర్క్ సంఖ్యలతో కొలవండి: థ్రూపుట్, గూఢలిపి ప్రాసెసింగ్ మరియు మెమొరీ కదలిక. నిల్వను మీరు నిజంగా తీసుకున్న పర్యవేక్షణ నిర్ణయాలతో కొలవండి: లాగ్ స్థాయి, నిల్వ కాలం, స్థితి విరామం, మరియు ఉద్దేశపూర్వకంగా ప్రారంభించిన ఏదైనా క్యాప్చర్.
ఈ రెండు బడ్జెట్లను వేరుగా ఉంచడం సంఘటనలను చదవడాన్ని కూడా సులభతరం చేస్తుంది. మితమైన సొరంగ ట్రాఫిక్తో నిండిన డిస్క్ లాగ్లు, క్యాప్చర్లు లేదా సంబంధం లేని ఏదో వైపు చూపిస్తుంది, ఇంటర్ఫేస్ కౌంటర్ దానిని ఎప్పటికీ వివరించదు. ప్రశాంతమైన లాగ్తో నిండిన లింక్ వ్యతిరేక దిశను చూపిస్తుంది.
చేయదగిన పోలిక ఒకే రకమైన కొలతల మధ్యది. కాలక్రమేణా ఇంటర్ఫేస్ బైట్లు ఇంటర్ఫేస్ బైట్లకు వ్యతిరేకంగా మార్గం గురించి చెబుతాయి. నిల్వ రాతలు నిల్వ సామర్థ్యానికి వ్యతిరేకంగా నిల్వ కాలం గురించి చెబుతాయి. అడ్డం పోలిక, ట్రాఫిక్ డిస్క్కు వ్యతిరేకంగా, అర్థవంతంగా కనిపిస్తుంది మాత్రమే, ఎప్పటికీ అలా ఉండదు.