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ನಿಜವಾದ ಪೇಲೋಡ್ ಬರವಣಿಗೆಗಳನ್ನು ನೀವು ಸಂಶಯಿಸಿದರೆ, ಪೇಲೋಡ್ ಸಂಗ್ರಹಿಸುವುದೇ ಕೆಲಸವಾಗಿರುವ ಘಟಕವನ್ನು ಹುಡುಕಿ: ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವ ಸಾಧನ, ದೇಹಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವ ಪ್ರಾಕ್ಸಿ, ಆರ್ಕೈವ್ ಮಾಡುವ ಪ್ಲಗಿನ್. ಇವು ತಮ್ಮಿಂದ ದಾಖಲಿಸಲು ಕೇಳಿದ ಪ್ರಮಾಣಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಬೆಳೆಯುವ ಸಂಗ್ರಹಣಾ ಸಂಚಾರವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ, ಮತ್ತು ಅವು ಧಾರಣೆ ಮತ್ತು ಪ್ರವೇಶದ ಬಗ್ಗೆ ಪ್ರತ್ಯೇಕ ನೀತಿ ನಿರ್ಣಯಕ್ಕೆ ಸೇರುತ್ತವೆ.
ಸರಿಯಾದ ಸಂಖ್ಯೆಯಿಂದ ಸಾಮರ್ಥ್ಯ ಯೋಜನೆ
ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗವನ್ನು ನೆಟ್ವರ್ಕ್ ಸಂಖ್ಯೆಗಳಿಂದ ಅಳೆಯಿರಿ: ಥ್ರೂಪುಟ್, ಗೂಢಲಿಪೀಕರಣ ಸಂಸ್ಕರಣೆ ಮತ್ತು ಮೆಮೊರಿ ಚಲನೆ. ಸಂಗ್ರಹಣೆಯನ್ನು ನೀವು ನಿಜವಾಗಿ ತೆಗೆದುಕೊಂಡ ವೀಕ್ಷಣೀಯತೆಯ ನಿರ್ಣಯಗಳಿಂದ ಅಳೆಯಿರಿ: ಲಾಗ್ ಮಟ್ಟ, ಧಾರಣೆ, ಸ್ಥಿತಿ ಮಧ್ಯಂತರ, ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಿದ ಯಾವುದೇ ಸೆರೆಹಿಡಿಯುವಿಕೆ.
ಈ ಎರಡು ಬಜೆಟ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುವುದು ಘಟನೆಗಳನ್ನು ಓದಲು ಸುಲಭವಾಗಿಸುತ್ತದೆ. ಸಾಧಾರಣ ಸುರಂಗ ಸಂಚಾರದೊಂದಿಗೆ ತುಂಬಿದ ಡಿಸ್ಕ್ ಲಾಗ್ಗಳು, ಸೆರೆಹಿಡಿಯುವಿಕೆಗಳು ಅಥವಾ ಅಸಂಬಂಧಿತ ಯಾವುದೋ ಕಡೆಗೆ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಕೌಂಟರ್ ಅದನ್ನು ಎಂದಿಗೂ ವಿವರಿಸುವುದಿಲ್ಲ. ಶಾಂತ ಲಾಗ್ನೊಂದಿಗೆ ಸ್ಯಾಚುರೇಟೆಡ್ ಲಿಂಕ್ ಇನ್ನೊಂದು ದಿಕ್ಕಿಗೆ ತೋರಿಸುತ್ತದೆ.
ಮಾಡಲು ಯೋಗ್ಯವಾದ ಹೋಲಿಕೆ ಒಂದೇ ರೀತಿಯ ಅಳತೆಗಳ ನಡುವಿನದು. ಕಾಲಾನಂತರದಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಬೈಟ್ಗಳು ಇಂಟರ್ಫೇಸ್ ಬೈಟ್ಗಳಿಗೆ ಎದುರಾಗಿ ಮಾರ್ಗದ ಬಗ್ಗೆ ಹೇಳುತ್ತವೆ. ಸಂಗ್ರಹಣಾ ಬರವಣಿಗೆಗಳು ಸಂಗ್ರಹಣಾ ಸಾಮರ್ಥ್ಯಕ್ಕೆ ಎದುರಾಗಿ ಧಾರಣೆಯ ಬಗ್ಗೆ ಹೇಳುತ್ತವೆ. ಅಡ್ಡ ಹೋಲಿಕೆ, ಸಂಚಾರ ಡಿಸ್ಕ್ಗೆ ಎದುರಾಗಿ, ಅರ್ಥಪೂರ್ಣವಾಗಿ ಕಾಣುತ್ತದೆ ಅಷ್ಟೇ ಮತ್ತು ಎಂದಿಗೂ ಹಾಗಿರುವುದಿಲ್ಲ.