ನಿಮ್ಮ VPN ಗೇಟ್ವೇ CPU-ಸೀಮಿತವೇ? ಮೊದಲು ಪ್ರತಿ-ಕೋರ್ ಲೋಡ್ ಓದಿ
ಸರಾಸರಿಗಳು ಮುಖ್ಯವಾದ ಥ್ರೆಡ್ ಅನ್ನು ಮರೆಮಾಡುತ್ತವೆ. ನಿಯಂತ್ರಿತ ವರ್ಗಾವಣೆಯ ವಿರುದ್ಧ ಪ್ರತಿ-ಕೋರ್ ಲೋಡ್ ಓದಿ, ಮಾರ್ಗವನ್ನು ಹೊರಗಿಡಿ, ನಂತರ ಪ್ರತಿ ರನ್ನಲ್ಲಿ ಒಂದು ದಾಖಲಿತ ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸಿ.
ದೊಡ್ಡ ಇನ್ಸ್ಟಾನ್ಸ್ ಖರೀದಿಸುವ ಮೊದಲು ನೀವು ಮೂರು ಮಿತಿಗಳಲ್ಲಿ ಯಾವುದನ್ನು ತಲುಪಿದ್ದೀರಿ ಎಂದು ನಿರ್ಧರಿಸಿ. ಒಂದು ಕೋರ್ ಪೂರ್ತಿ ನಿರತವಾಗಿದ್ದು ಉಳಿದವು ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದರೆ ಅದು ಪ್ರತಿ-ಹರಿವಿನ ಕ್ರಿಪ್ಟೋ ಕೆಲಸವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಎಲ್ಲಾ ಕೋರ್ಗಳು ತುಂಬಿದ್ದರೆ ಅದು ಒಟ್ಟು ಸಾಮರ್ಥ್ಯವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಕಡಿಮೆ CPU ಮತ್ತು ಹೆಚ್ಚುತ್ತಿರುವ ಮರುಕಳುಹಿಸುವಿಕೆ ಸಂಖ್ಯೆ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಮೊದಲ ಹೆಜ್ಜೆ ಇದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ ದೊಡ್ಡ ಇನ್ಸ್ಟಾನ್ಸ್ನಿಂದ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ.
ಮೂರು ಮಿತಿಗಳು, ಒಂದು ಕೋಷ್ಟಕ, ಮೂರು ಸರಿಪಡಿಸುವಿಕೆಗಳು
| Limit | Reading during a transfer | First move |
|---|---|---|
| Single thread | one core near 100%, siblings idle | spread flows across workers |
| Aggregate CPU | every core busy, load average climbs | capacity, or less work per byte |
| Path or provider | low CPU, retransmits or steal time high | MTU, loss, host contention |
ಸಾಲುಗಳನ್ನು ಹಂತಗಳಲ್ಲ, ರೋಗನಿರ್ಣಯಗಳಾಗಿ ಓದಿ. ಒಂದು ಥ್ರೆಡ್ 100% ನಲ್ಲಿದ್ದು ಉಳಿದವು ನಿಷ್ಕ್ರಿಯವಾಗಿರುವುದು ಒಂದು ದೊಡ್ಡ ಸುರಂಗವನ್ನು ಹೊತ್ತೊಯ್ಯುವ ಗೇಟ್ವೇಯಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಫಲಿತಾಂಶ, ಏಕೆಂದರೆ ಆ ಹರಿವಿನ ಎನ್ಕ್ರಿಪ್ಷನ್ ಒಂದೇ ಕೋರ್ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ. ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಎಲ್ಲಾ ಕೋರ್ ನಿರತವಾಗಿದ್ದರೆ ಯಂತ್ರವು ಈಗಾಗಲೇ ತನ್ನ ಕೈಲಾದಷ್ಟು ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದರ್ಥ. ಕಡಿಮೆ CPU ಮತ್ತು ಹೆಚ್ಚುತ್ತಿರುವ ಮರುಕಳುಹಿಸುವಿಕೆಗಳು ಎಂದರೆ ಪ್ರೊಸೆಸರ್ ನಿರಂತರವಾಗಿ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ನೆಟ್ವರ್ಕ್ಗಾಗಿ ಕಾಯುತ್ತಿದೆ.
ಸಾಕ್ಷ್ಯದ ಅದೇ ಕ್ರಮದಲ್ಲಿ ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಿ. ಹರಿವುಗಳನ್ನು ಕೆಲಸಗಾರರಿಗೆ ಹಂಚುವುದು ಮೊದಲ ಪ್ರಕರಣಕ್ಕೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯದಕ್ಕೆ ಏನೂ ಮಾಡುವುದಿಲ್ಲ. ದೊಡ್ಡ ಇನ್ಸ್ಟಾನ್ಸ್ ಎರಡನೆಯದಕ್ಕೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ಮೊದಲನೆಯದರಲ್ಲಿ ಹಣವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. MTU ಅಥವಾ ನಷ್ಟ ಸರಿಪಡಿಸುವಿಕೆಯೇ ಮೂರನೆಯದನ್ನು ಸ್ಪರ್ಶಿಸುವ ಏಕೈಕ ಮಾರ್ಗ. ನೀವು ಯಾವ ಸಾಲಿನಲ್ಲಿದ್ದೀರಿ ಎಂದು ತಿಳಿಯುವ ಮೊದಲು ಸಾಮರ್ಥ್ಯ ಖರೀದಿಸುವುದು ಊಹೆಯ ದುಬಾರಿ ಆವೃತ್ತಿ.
ನಿಲ್ಲಿಸಿದ ಥ್ರೆಡ್ ಅನ್ನು ನಿರತ ಹೋಸ್ಟ್ನಿಂದ ಬೇರ್ಪಡಿಸಿ
ಪ್ರತಿ-ಕೋರ್ ಬಳಕೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಇದರಿಂದ ನಿಲ್ಲಿಸಿದ ಒಂದು ಕೋರ್ ಸರಾಸರಿಯೊಳಗೆ ಅಡಗಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಒಂದು ರನ್ ಲೋಡ್ ಸಮತಟ್ಟಾಗಿದೆಯೇ ಅಥವಾ ಶಿಖರಗಳಿಂದ ಕೂಡಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಎರಡೂ ಆಕಾರಗಳು ಮಾಹಿತಿಪೂರ್ಣ, ಮತ್ತು ಶಿಖರದ ಪ್ರೊಫೈಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಮಾದರಿ ವಿಂಡೋ ಎನ್ಕ್ರಿಪ್ಷನ್ ಬದಲು ಶೆಡ್ಯುಲರ್ ಚಟುವಟಿಕೆಯನ್ನು ಹಿಡಿದಿದೆ ಎಂದರ್ಥ.
mpstat -P ALL 1 5
ನಿರತ ಕೋರ್ ಅನ್ನು ಪ್ರೊಸೆಸ್ಗೆ, ನಂತರ ಥ್ರೆಡ್ಗೆ ಆರೋಪಿಸಿ. ಕೆಳಗಿನ ಮುಂದುವರಿಕೆ ರನ್ ಪೋಷಕ ಮತ್ತು ಮಗು ಥ್ರೆಡ್ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಇಡುತ್ತದೆ, ಇದು ಡೀಮನ್ ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೂ ಫೋರ್ಕ್ ಮಾಡುವಾಗ ಮುಖ್ಯ:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10
ಕರ್ನಲ್ ಕ್ರಿಪ್ಟೋ ಎಂದಿಗೂ ಬಳಕೆದಾರ-ಸ್ಥಳ ಪ್ರೊಸೆಸ್ ಕೌಂಟರ್ನಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ. ಥ್ರೆಡ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಮಾದರಿ ಮಾಡಿ ಮತ್ತು ಆ ನೋಟವನ್ನು ಪ್ರೊಸೆಸ್ ಲೆಕ್ಕಪತ್ರದೊಂದಿಗೆ ಹೋಲಿಸಿ:
top -H -b -n 1 | head -20
ಸಾಕೆಟ್ ಕೌಂಟರ್ಗಳನ್ನು ಕೊನೆಯದಾಗಿ ಓದಿ, ಏಕೆಂದರೆ ಹೆಚ್ಚು CPU ಸಹಾಯ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ಅವೇ ನಿರ್ಧರಿಸುತ್ತವೆ. CPU ಸಮತಟ್ಟಾಗಿದ್ದು ಮರುಕಳುಹಿಸುವಿಕೆಗಳು ಹೆಚ್ಚುತ್ತಿದ್ದರೆ ಅದು ಪ್ರೊಸೆಸರ್ ಸಮಸ್ಯೆ ಅಲ್ಲ. ಮಾದರಿ ಮಾಡುವಾಗ ವರ್ಗಾವಣೆಯನ್ನು ಚಾಲನೆಯಲ್ಲಿಡಿ, ಇಲ್ಲದಿದ್ದರೆ ಸಂಖ್ಯೆಗಳು ನಿಷ್ಕ್ರಿಯ ಯಂತ್ರವನ್ನು ವಿವರಿಸುತ್ತವೆ:
ss -ti | grep -E 'retrans|cwnd|rtt'
ನಿಯಂತ್ರಿತ ವರ್ಗಾವಣೆ, ಎರಡು ಬಾರಿ
ನಿಷ್ಕ್ರಿಯ ಕೌಂಟರ್ಗಳು ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಯಾದೃಚ್ಛಿಕ ಎಂಡ್ಪಾಯಿಂಟ್ ವಿರುದ್ಧದ ಬೆಂಚ್ಮಾರ್ಕ್ ತುಂಬಾ ಕಡಿಮೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಒಂದು ಕ್ಲೈಂಟ್, ಒಂದು ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಚಲಾಯಿಸಲು ಅನುಮತಿಸಲಾದ ಒಂದು ಪ್ರಾತಿನಿಧಿಕ ವರ್ಗಾವಣೆಯನ್ನು ಆರಿಸಿ, ನಂತರ ಅದೇ ವಿಂಡೋದಲ್ಲಿ ಥ್ರೂಪುಟ್ ಮತ್ತು ಸಂವಾದಾತ್ಮಕ ವಿಳಂಬವನ್ನು ದಾಖಲಿಸಿ. ಬೃಹತ್ ನಕಲು ಇನ್ನೂ ಪೂರ್ಣಗೊಳ್ಳುತ್ತಿರುವಾಗ ಗೇಟ್ವೇ ತುಂಬಬಹುದು, ಮತ್ತು ಬಳಕೆದಾರರು ನಿಜವಾಗಿ ಅನುಭವಿಸುವುದು ವಿಳಂಬದ ವಕ್ರರೇಖೆಯನ್ನೇ. ವರ್ಗಾವಣೆ, ಕ್ಲೈಂಟ್ ಸಂಖ್ಯೆ ಮತ್ತು ಡೀಮನ್ ಆವೃತ್ತಿಯನ್ನು ಸಂಖ್ಯೆಗಳ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ.
ಹಲವು ಸಮಾನಾಂತರ ಹರಿವುಗಳೊಂದಿಗೆ ರನ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಹರಿವುಗಳಾದ್ಯಂತ ಹೆಚ್ಚಳವು ಪ್ರತಿ-ಹರಿವಿನ ವಿಂಡೋಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ; ಒಂದು ಕೋರ್ ನಿಲ್ಲಿಸಿದರೂ ಸಮತಟ್ಟಾಗಿ ಉಳಿಯುವುದು ಸಂಸ್ಕರಣೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ನಂತರ ಐಚ್ಛಿಕ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ನಿಲ್ಲಿಸಿ ಇನ್ನೊಮ್ಮೆ ಪುನರಾವರ್ತಿಸಿ. ಅದೇ ಹೋಸ್ಟ್ನಲ್ಲಿ ಬ್ಯಾಕಪ್, ಲಾಗ್ ಶಿಪ್ಪರ್ ಅಥವಾ ಡೇಟಾಬೇಸ್ ಸುರಂಗಗಳಿಗೆ ಸಂಬಂಧವಿಲ್ಲದ ನಿರತ ಸರಾಸರಿಯನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಹೋಸ್ಟ್ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಶಾಂತವಾಗಿದ್ದರೂ CPU ನಿಲ್ಲಿಸಿದ್ದರೆ ಸಾಕ್ಷ್ಯವು VPN ಪ್ರೊಸೆಸ್ನತ್ತ ಸಾಗುತ್ತದೆ. ಅದು ಇಳಿದರೆ ನೀವು ನೆರೆಯವರನ್ನು ಅಳೆಯುತ್ತಿದ್ದೀರಿ, ಮತ್ತು ಗೇಟ್ವೇ ಎಂದೂ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ.
ಹಾರ್ಡ್ವೇರ್ ಖರೀದಿಸುವ ಮೊದಲು ಮಾರ್ಗವನ್ನು ಹೊರಗಿಡಿ
ಹೆಚ್ಚುತ್ತಿರುವ ಮರುಕಳುಹಿಸುವಿಕೆಗಳು, ಸಂಕೋಚಿಸುತ್ತಿರುವ ದಟ್ಟಣೆ ವಿಂಡೋ ಮತ್ತು ಹೆಚ್ಚುತ್ತಿರುವ ರೌಂಡ್-ಟ್ರಿಪ್ ಸಮಯ ಎಲ್ಲವೂ ಪ್ರೊಸೆಸರ್ನಿಂದ ದೂರ ಸೂಚಿಸುತ್ತವೆ. ಸುರಂಗದ MTU ಅನ್ನು ಮಾರ್ಗದ MTU ಜೊತೆ ಹೋಲಿಸಿ, ಆಧಾರ ಲಿಂಕ್ನಲ್ಲಿ ನಷ್ಟವಿದೆಯೇ ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಅಪ್ಲಿಂಕ್ ಮಿತಿಯಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ. ದೊಡ್ಡ ಗೇಟ್ವೇ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಬೀಳಿಸುವ ಲಿಂಕ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಬಳಕೆದಾರರು ಎರಡೂ ದೋಷಗಳನ್ನು ಒಂದೇ ಪದಗಳಲ್ಲಿ ವಿವರಿಸುತ್ತಾರೆ. ಮರುಕಳುಹಿಸುವಿಕೆ ಕೌಂಟರ್ ನಿಮಿಷಗಳಲ್ಲಿ ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ.
ವರ್ಚುವಲ್ ಸರ್ವರ್ನಲ್ಲಿ, ಪೂರೈಕೆದಾರರ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಅತಿಥಿಯ ಸ್ವಂತ ಮೆಟ್ರಿಕ್ಗಳಿಗೆ ಸೇರಿಸಿ. ಸ್ಟೀಲ್ ಟೈಮ್ ಎಂದರೆ ಅಧಿಕ ಮಾರಾಟವು ಅತಿಥಿಯೊಳಗೆ ಹೇಗೆ ಗೋಚರವಾಗುತ್ತದೆ, ಮತ್ತು ಅತಿಥಿಯೊಳಗಿನ ಯಾವುದೇ ಟ್ಯೂನಿಂಗ್ ಅದನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ. ಅತಿಥಿ ಕೌಂಟರ್ಗಳು ಹೋಸ್ಟ್ ಅನ್ನು ನೋಡಲಾರವು, ಆದ್ದರಿಂದ ಸ್ವಚ್ಛ ಅತಿಥಿ ಗ್ರಾಫ್ ಆರೋಗ್ಯಕರ ಹೋಸ್ಟ್ನ ಸಾಕ್ಷ್ಯವಲ್ಲ.
ಒಂದು ಬದಲಾವಣೆ, ಒಂದು ಮಾಪನ
ಸಾಕ್ಷ್ಯವು ಬೆಂಬಲಿಸುವ ಕಲ್ಪನೆಯನ್ನು ಆರಿಸಿ, ನಂತರ ನಿಖರವಾಗಿ ಒಂದು ಬೆಂಬಲಿತ ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸಿ: ಕೆಲಸಗಾರರ ಸಂಖ್ಯೆ, ದಾಖಲಿತ ಆಫ್ಲೋಡ್ ಆಯ್ಕೆ, ಅಥವಾ ಇನ್ಸ್ಟಾನ್ಸ್ ಗಾತ್ರ. OpenVPN ಸಂಸ್ಕರಣೆ ಮತ್ತು ಸಾಗಣೆಯ ನಡುವಿನ ಅದೇ ವಿಭಜನೆಯ ಬಗ್ಗೆ ಕಾರ್ಯಕ್ಷಮತೆ ದೋಷನಿವಾರಣೆ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ: OpenVPN ಕಾರ್ಯಕ್ಷಮತೆ ದೋಷನಿವಾರಣೆ.
ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ನಂಬುವ ಬದಲು ಆಫ್ಲೋಡ್ ಆಯ್ಕೆ ನಿಜವಾಗಿ ಸಕ್ರಿಯವಾಗಿದೆಯೇ ಖಚಿತಪಡಿಸಿ, ನಂತರ ಅದೇ ವರ್ಗಾವಣೆಯನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ ಮತ್ತು ಸಮಾನವಾದದನ್ನು ಸಮಾನವಾದದೊಂದಿಗೆ ಹೋಲಿಸಿ. ನಿಜವಾದ ಸುಧಾರಣೆಯನ್ನು ಶಾಂತ ಮಧ್ಯಾಹ್ನದಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ ಏಕೈಕ ದಾರಿ ಇದು. ಮರುಸ್ಥಾಪಿಸಬಹುದಾದ ಚೆಕ್ಪಾಯಿಂಟ್ ಇಟ್ಟುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಎರಡನೇ ಬದಲಾವಣೆಯಲ್ಲಿ ಯಾವುದು ಸಹಾಯ ಮಾಡಿತು ಎಂಬುದನ್ನು ಜನರು ಮರೆತುಬಿಡುತ್ತಾರೆ. ಪ್ರತಿ ರನ್ಗೆ ಒಂದು ವೇರಿಯೇಬಲ್ ಒಂದು ದಿನಕ್ಕೆ ನಿಧಾನ ಮತ್ತು ಒಂದು ತಿಂಗಳಿಗೆ ವೇಗ.
ಗ್ರಾಫ್ ಉತ್ತಮವಾಗಿ ಕಾಣಲು ದೃಢೀಕರಣ ಅಥವಾ ಸೈಫರ್ ಸೂಟ್ ಅನ್ನು ದುರ್ಬಲಗೊಳಿಸಬೇಡಿ. CPU ಇನ್ನೂ ಲಕ್ಷಣವನ್ನು ಅನುಸರಿಸದಿದ್ದರೆ, ಊಹೆಯ ಮೇಲೆ ಅಪ್ಗ್ರೇಡ್ ಮಾಡುವ ಬದಲು ಮಾರ್ಗ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪರಿಶೀಲನೆಗಳಿಗೆ ಹಿಂತಿರುಗಿ.