VPN ಸರ್ವರ್ ಲೋಡ್ ವಿವರಣೆ: ಬಳಕೆದಾರರು, CPU ಅಥವಾ ಅಪ್ಲಿಂಕ್?
ಕಡಿಮೆ ಲೋಡ್ ಸ್ಕೋರ್ ಎಂದರೆ ನಿಷ್ಕ್ರಿಯ ಬಳಕೆದಾರರು, ಉಳಿದ CPU ಅಥವಾ ಅಗಲವಾದ ಅಪ್ಲಿಂಕ್ ಇರಬಹುದು. ಅದನ್ನು ವೇಗ ಎಂದು ಕರೆಯುವ ಮೊದಲು loadavg, ಇಂಟರ್ಫೇಸ್ ಕೌಂಟರ್ಗಳು ಮತ್ತು ಸ್ಥಿತಿ ಫೈಲ್ ಓದಿ.
0.4 ಲೋಡ್ನಲ್ಲಿರುವ ಗೇಟ್ವೇ ತನ್ನ ಹಿಂದಿನ ಪ್ರತಿ ಬಳಕೆದಾರನಿಗೂ ಇನ್ನೂ ತೆವಳಬಹುದು. ಸರಾಸರಿ ಲೋಡ್ ಎಂಬುದು ಚಲಾಯಿಸಬಹುದಾದ ಅಥವಾ ಅಡಚಣೆಯಾಗದ ನಿದ್ರೆಯಲ್ಲಿ ಸಿಕ್ಕಿಕೊಂಡಿರುವ ಕಾರ್ಯಗಳನ್ನು ಎಣಿಸುತ್ತದೆ, ಮತ್ತು ನಾಲ್ಕು ಕೋರ್ನ ಹೋಸ್ಟ್ನಲ್ಲಿ ಒಂದೇ ಸ್ಯಾಚುರೇಟೆಡ್ ಪ್ರಕ್ರಿಯೆ ಅದನ್ನು 1.0 ಕಡೆಗೆ ತಳ್ಳಲು ಸಾಕು, ಆಗ ಮೂರು ಕೋರ್ಗಳು ನಿಷ್ಕ್ರಿಯವಾಗಿ ಕುಳಿತಿರುತ್ತವೆ. ಆ ಸಂಖ್ಯೆಯನ್ನು ಮೀಸಲು ಎಂದು ಓದುವುದು ಎಂಡ್ಪಾಯಿಂಟ್ ಆಯ್ಕೆಯಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು. ಟನೆಲ್ ಅನ್ನು ನಿಜವಾಗಿ ಮಿತಿಗೊಳಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ನಾಲ್ಕರಲ್ಲಿ ಒಂದು: ಒಂದು ಕಾರ್ಯನಿರತ ಕೋರ್, ಅಪ್ಲಿಂಕ್, ಅದರ ಮುಂದಿನ ಸರದಿ, ಅಥವಾ ಯಾರೂ ದಾಖಲಿಸದ ಪ್ರತಿ-ಅಧಿವೇಶನ ನೀತಿ.
ಸರಾಸರಿ ಲೋಡ್ ಕಾರ್ಯಗಳನ್ನು ಎಣಿಸುತ್ತದೆ, ಥ್ರೂಪುಟ್ ಅಲ್ಲ
ಕರ್ನಲ್ ರನ್ ಕ್ಯೂ ಮತ್ತು ಇನ್ಪುಟ್-ಔಟ್ಪುಟ್ಗಾಗಿ ಕಾಯುತ್ತಿರುವ ಕಾರ್ಯಗಳ ಸಂಖ್ಯೆಯ ಮಾದರಿಗಳನ್ನು ತೆಗೆದುಕೊಂಡು, ನಂತರ ಎರಡನ್ನೂ ಒಂದು, ಐದು ಮತ್ತು ಹದಿನೈದು ನಿಮಿಷಗಳಲ್ಲಿ ಮೃದುಗೊಳಿಸುತ್ತದೆ. ಆ ವ್ಯಾಖ್ಯಾನದಲ್ಲಿ ಬೈಟ್ಗಳು, ಪ್ಯಾಕೆಟ್ಗಳು ಅಥವಾ ಟನೆಲ್ಗಳ ಉಲ್ಲೇಖವಿಲ್ಲ. ಸಂಗ್ರಹಣೆ ಸಿಕ್ಕಿಕೊಂಡಿರುವ ಹೋಸ್ಟ್ ಬಹುತೇಕ ಸಂಚಾರವಿಲ್ಲದೆ ಹೆಚ್ಚಿನ ಲೋಡ್ ವರದಿ ಮಾಡಬಹುದು, ಮತ್ತು ಕರ್ನಲ್ ಡೇಟಾ ಮಾರ್ಗದ ಮೂಲಕ ಗಿಗಾಬಿಟ್ ತಳ್ಳುವ ಹೋಸ್ಟ್ ಆರಾಮದಾಯಕ ಲೋಡ್ ವರದಿ ಮಾಡಬಹುದು.
ಆದ್ದರಿಂದ ಲೋಡ್ ಅನ್ನು ಟನೆಲ್ ಕಾರ್ಯಕ್ಷಮತೆಯೊಂದಿಗೆ ಸಂಬಂಧಿಸಲು ಪ್ರತಿ ಕೋರ್ ನೋಟ ಬೇಕು. ಒಂದು ಕೋರ್ ಪೂರ್ಣವಾಗಿ ತುಂಬಿದ್ದರೆ, ಡ್ಯಾಶ್ಬೋರ್ಡ್ನ ಒಟ್ಟು ಶೇಕಡಾವಾರು ಇನ್ನೂ ಚೆನ್ನಾಗಿ ಕಾಣುತ್ತದೆ:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20
ಮೂರನೇ ಆದೇಶವೇ VPN ಹೋಸ್ಟ್ಗಳಲ್ಲಿ ಹೆಚ್ಚು ಮುಖ್ಯವಾದುದು. OpenVPN 2.x ನಲ್ಲಿ ಬಳಕೆದಾರ ಸ್ಥಳದ ಪ್ಯಾಕೆಟ್ ಸಂಸ್ಕರಣೆ ಬಹುಪಾಲು ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೆ ಅನುಕ್ರಮವಾಗಿದೆ, ಆದ್ದರಿಂದ ಒಂದೇ ಕಾರ್ಯನಿರತ ಥ್ರೆಡ್ ಮೇಲ್ಚಾವಣಿಯಾಗಬಹುದು, ಆಗ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಸಾಕಷ್ಟು ನಿಷ್ಕ್ರಿಯ ಸಾಮರ್ಥ್ಯ ವರದಿ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ ನಿಧಾನ ಅವಧಿಯಲ್ಲಿ ಒಂದು ಥ್ರೆಡ್ ಕೋರ್ನ ಬಹುಪಾಲನ್ನು ಹಿಡಿದಿದ್ದರೆ, ಹೋಸ್ಟ್ ಒಟ್ಟಾರೆಯಾಗಿ ಕಡಿಮೆ ಸಜ್ಜಾಗಿಲ್ಲ; ಅದು ಆಕಸ್ಮಿಕವಾಗಿ ಮುಖ್ಯವಾಗುವ ಆಯಾಮದಲ್ಲಿ ಮಿತಿಗೊಂಡಿದೆ.
ಸಮಯವನ್ನೂ ಗಮನಿಸಿ. ಹದಿನೈದು ನಿಮಿಷದ ಸರಾಸರಿಗಳು ಕರೆಯನ್ನು ಹಾಳುಮಾಡಿದ ಸ್ಫೋಟವನ್ನು ಮರೆಮಾಡುತ್ತವೆ, ಆದ್ದರಿಂದ ದೂರು ಬಂದ ನಂತರ ತೆಗೆದ ಸ್ಕ್ರೀನ್ಶಾಟ್ ದುರ್ಬಲ ಸಾಕ್ಷ್ಯ. ಸಮಸ್ಯೆಯ ಸಮಯದಲ್ಲೇ ಮಾದರಿ ತೆಗೆಯಿರಿ, ಮತ್ತು ಔಟ್ಪುಟ್ನೊಂದಿಗೆ ಸಮಯ ಮುದ್ರೆಯನ್ನು ಇರಿಸಿ.
ಅಪ್ಲಿಂಕ್ ಮತ್ತು ಅದರ ಮುಂದಿನ ಸರದಿ
ಇಂಟರ್ಫೇಸ್ ಕೌಂಟರ್ಗಳು CPU ಸಂಖ್ಯೆಗಳು ಉತ್ತರಿಸಲಾಗದ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ಅವು ಸಾಮರ್ಥ್ಯವನ್ನು ನಷ್ಟದಿಂದಲೂ ಬೇರ್ಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಇವು ವಿಭಿನ್ನ ಪರಿಹಾರಗಳಿರುವ ವಿಭಿನ್ನ ವೈಫಲ್ಯಗಳು:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit
ನಿಮ್ಮ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ತನಗೆ ಹಂಚಿದ ದರದ ಹತ್ತಿರವಿರುವ ಲಿಂಕ್ ಅದೇ ವಿವರಣೆ, ಮತ್ತು ಉಳಿದ CPU ನ ಯಾವುದೇ ಪ್ರಮಾಣ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. qdisc ಸಾಲು ಸಂವಾದಾತ್ಮಕ ಸಂಚಾರಕ್ಕೆ ಮುಖ್ಯವಾದ ವಿವರ ಸೇರಿಸುತ್ತದೆ: ಬ್ಯಾಕ್ಲಾಗ್ ಮತ್ತು ಡ್ರಾಪ್ಗಳು ಪ್ಯಾಕೆಟ್ಗಳು ಹೊರಡುವ ಮೊದಲು ಸರದಿಯಲ್ಲಿ ಕಾಯುತ್ತವೆಯೇ ಎಂದು ಹೇಳುತ್ತವೆ. ದೊಡ್ಡ ಅಪ್ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ತುಂಬುವ ಸರದಿ ಜನರು ದೂರದ ಸರ್ವರ್ ಮೇಲೆ ಹೊರಿಸುವ ಲಕ್ಷಣವನ್ನೇ ಉಂಟುಮಾಡುತ್ತದೆ, ಅಂದರೆ ಬೆಂಚ್ಮಾರ್ಕ್ನಲ್ಲಿ ಇನ್ನೂ ಚೆನ್ನಾಗಿ ಕಾಣುವ ಸಂಪರ್ಕದಲ್ಲಿ ನಿಧಾನ ಕರೆಗಳು.
ಮರುಪ್ರಸಾರ ಕೌಂಟರ್ಗಳು ಪ್ಯಾಕೆಟ್ಗಳು ಹೊರಟು ಆದರೆ ಎಂದಿಗೂ ಸ್ವಚ್ಛವಾಗಿ ತಲುಪದ ಪ್ರಕರಣವನ್ನು ಹಿಡಿಯುತ್ತವೆ. ನಿಧಾನ ವಿಂಡೋದಲ್ಲಿ ಮರುಪ್ರಸಾರಗಳು ಏರಿದರೆ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಸಾಮರ್ಥ್ಯದ ಹತ್ತಿರವಿಲ್ಲದಿದ್ದರೆ, ಸಮಸ್ಯೆ ಹೋಸ್ಟ್ನಲ್ಲಲ್ಲ, ಮಾರ್ಗದಲ್ಲಿದೆ, ಮತ್ತು ಅದೇ ನಗರದ ಇನ್ನೊಂದು ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಹೋಗುವುದು ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.
ಅಧಿವೇಶನ ಸಂಖ್ಯೆಗಳು ಬೇಡಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮೀಸಲು ಅಲ್ಲ
ಪ್ರತಿ ಸಾರ್ವಜನಿಕ ಡೈರೆಕ್ಟರಿ ಕೆಲವು ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಿತ ಬಳಕೆದಾರರನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಬಹುತೇಕ ಯಾವುದೂ ಆ ಬಳಕೆದಾರರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂದು ಹೇಳುವುದಿಲ್ಲ. ಸಂವಾದಾತ್ಮಕ ಕೆಲಸ ಮಾಡುವ ಇಪ್ಪತ್ತು ಅಧಿವೇಶನಗಳು ಮತ್ತು ದೊಡ್ಡ ಕಡತಗಳನ್ನು ಎಳೆಯುವ ನಾಲ್ಕು ಅಧಿವೇಶನಗಳು ಒಂದೇ ಹಾರ್ಡ್ವೇರ್ನಲ್ಲಿ ಬಹಳ ವಿಭಿನ್ನ ಲೋಡ್ಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಎರಡನೇ ಮಾದರಿ ಬಳಕೆದಾರ ಸಂಖ್ಯೆಯಲ್ಲಿ ಅಗೋಚರ, ಮತ್ತು ಅದೇ ಸಂಜೆಯನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ. ಆದ್ದರಿಂದ ಅಧಿವೇಶನ ಸಂಖ್ಯೆಯನ್ನು ಬೇಡಿಕೆಯ ಸುಳಿವಾಗಿ ಓದುವುದು ಉತ್ತಮ, ಎಂದಿಗೂ ಮೀಸಲು ಸಾಮರ್ಥ್ಯದ ಹೇಳಿಕೆಯಾಗಿ ಅಲ್ಲ.
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
ನೀವು ನಿಯಂತ್ರಿಸುವ ಹೋಸ್ಟ್ನಲ್ಲಿ, ಸ್ಥಿತಿ ಫೈಲ್ ಕಾಣೆಯಾದ ಆಯಾಮವನ್ನು ನೀಡುತ್ತದೆ. OpenVPN ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ ಬೈಟ್ ಕೌಂಟರ್ಗಳನ್ನು ಒಳಗೊಂಡ ನಿಯತಕಾಲಿಕ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಬರೆಯುತ್ತದೆ, ಮತ್ತು ಒಂದೇ ಅಧಿವೇಶನ ಇಡೀ ಅಪ್ಲಿಂಕ್ನಿಗೆ ಕಾರಣವೇ ಎಂದು ನೋಡಲು ಅದು ಸಾಕು:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status
ಹತ್ತು ಸೆಕೆಂಡುಗಳ ಅಂತರದ ಎರಡು ಮಾದರಿಗಳು ಆ ಸಂಚಿತ ಎಣಿಕೆಗಳನ್ನು ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ ದರವಾಗಿ ಬದಲಿಸುತ್ತವೆ. ಅದೇ ಬಳಕೆದಾರ ಸಂಖ್ಯೆ ನಿಂತಿರುವ ಅಳತೆ, ಮತ್ತು ಒಂದೇ ತಪ್ಪಾಗಿ ಸಂರಚಿಸಿದ ಕ್ಲೈಂಟ್ ಪ್ರತಿ ರಾತ್ರಿ ಅದೇ ಗಂಟೆಗೆ ಲಿಂಕ್ ಅನ್ನು ಸ್ಯಾಚುರೇಟ್ ಮಾಡುತ್ತದೆ ಎಂದು ಇದೇ ರೀತಿ ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ.
ಪ್ರತಿ-ಅಧಿವೇಶನ ಮಿತಿಗಳು ನೀತಿಯೊಳಗೆ ಅಡಗಿವೆ
ಸರ್ವರ್ ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದರೂ ನಿಮಗೆ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ನೀಡಲು ನಿರಾಕರಿಸಬಹುದು. ದರ ಮಿತಿಗಳು, ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಮೇಲ್ಮಿತಿಗಳು ಮತ್ತು ಸಂಚಾರ ರೂಪಿಸುವಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಸಾಮಾನ್ಯ ಹೆಸರು ಅಥವಾ ಪೂಲ್ ಮೂಲಕ ಅನ್ವಯವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಒಂದೇ ಗೇಟ್ವೇನಲ್ಲಿ ಇಬ್ಬರು ಬಳಕೆದಾರರಿಗೆ ಸಂಪೂರ್ಣ ವಿಭಿನ್ನ ಫಲಿತಾಂಶ ಸಿಗಬಹುದು. ಕಾರ್ಯವಿಧಾನ ಸೂಕ್ಷ್ಮವಲ್ಲ, ಆದರೆ ಹೊರಗಿನಿಂದ ಅಗೋಚರ, ಏಕೆಂದರೆ ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಟನೆಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಏಳುತ್ತದೆ.
ರೂಪಿಸುವಿಕೆಯನ್ನು ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಹುಡುಕಿ, ಭೌತಿಕದಲ್ಲಿ ಅಲ್ಲ. ಮಿತಿ ಬಳಕೆದಾರ, ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ವಿಳಾಸ ಪೂಲ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಖಾತೆ ಮಿತಿರಹಿತ ಪೂಲ್ಗೆ ಬಿದ್ದರೆ, ಸರ್ವರ್ ಸರಿಯಾಗಿದೆ ಮತ್ತು ದೂರು ನೀಡುವ ಬಳಕೆದಾರ ತಪ್ಪು ಎಂದು ನೀವು ತೀರ್ಮಾನಿಸುತ್ತೀರಿ. ಆ ತೀರ್ಮಾನ ಯಾವುದೇ ತೀರ್ಮಾನಕ್ಕಿಂತ ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ಅದು ಟಿಕೆಟ್ ಮುಚ್ಚುತ್ತದೆ.
ಒಂದು ಸ್ಥಿರ ಕಾರ್ಯದೊಂದಿಗೆ ಎರಡು ಎಂಡ್ಪಾಯಿಂಟ್ಗಳನ್ನು ಹೋಲಿಸಿ
ಕ್ಲೈಂಟ್ ಕಡೆಯ ಪ್ರಯೋಗವನ್ನು ಇನ್ನೂ ಮಾಡುವುದು ಯೋಗ್ಯ, ಆದರೆ ಚರಗಳು ಸ್ಥಿರವಾಗಿದ್ದರೆ ಮಾತ್ರ. ಅದೇ ಸಾಧನ, ಅದೇ ಪ್ರವೇಶ ಜಾಲ, ಅದೇ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಅದೇ ಗಮ್ಯ ಫೈಲ್ ಬಳಸಿ, ನಂತರ ಸಮಾನ ಅಂತರದಲ್ಲಿ ಎರಡನೇ ಎಂಡ್ಪಾಯಿಂಟ್ ವಿರುದ್ಧ ಪುನರಾವರ್ತಿಸಿ. ಓಟಗಳ ನಡುವೆ ಬದಲಾಗುವ ಯಾವುದೇ ವಿಷಯ, ದಿನದ ಸಮಯ ಸೇರಿದಂತೆ, ಫಲಿತಾಂಶವನ್ನು ಮಲಿನಗೊಳಿಸುತ್ತದೆ.
ವೈಫಲ್ಯಗಳನ್ನು ಯಶಸ್ಸುಗಳಷ್ಟೇ ಎಚ್ಚರಿಕೆಯಿಂದ ದಾಖಲಿಸಿ. ಮೂರು ಎಂಡ್ಪಾಯಿಂಟ್ಗಳು ಕೆಲಸ ಮಾಡಿ ಒಂದು ಸಮಯ ಮೀರಿದ ಸರಣಿ ನಾಲ್ಕು ವೇಗ ಸಂಖ್ಯೆಗಳಿಗಿಂತ ಹೆಚ್ಚು ಮಾಹಿತಿಪೂರ್ಣ, ಏಕೆಂದರೆ ಅದು ಸಾಮರ್ಥ್ಯದ ಬದಲು ಮಾರ್ಗ ಅಥವಾ ನೀತಿ ಸಮಸ್ಯೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಪ್ರತಿ ಪ್ರಕರಣವನ್ನು ಕನಿಷ್ಠ ಎರಡು ಬಾರಿ ಚಲಾಯಿಸಿ; ಹಂಚಿದ ಜಾಲದಲ್ಲಿ ಒಂದೇ ನಿಧಾನ ಮಾದರಿ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಕೊನೆಯದಾಗಿ, ನೀವು ಸಂಗ್ರಹಿಸಿದ ಸಂಖ್ಯೆಗಳನ್ನು ಅವು ಬೆಂಬಲಿಸುವ ಹೇಳಿಕೆಯೊಂದಿಗೆ ಇರಿಸಿ. "ಈ ಎಂಡ್ಪಾಯಿಂಟ್ ಇನ್ನೊಂದು ನಿಂತುಕೊಂಡ ಅದೇ ವಿಂಡೋದಲ್ಲಿ ವರ್ಗಾವಣೆಯನ್ನು ನಿರ್ವಹಿಸಿತು" ಸಮರ್ಥನೀಯ, ಆದರೆ "ಈ ಎಂಡ್ಪಾಯಿಂಟ್ ವೇಗವಾಗಿದೆ" ಮುಖಪುಟದ ಸ್ಕೋರ್ನಿಂದ ಗೆಲ್ಲಲಾಗದ ಚರ್ಚೆಗೆ ಆಹ್ವಾನ ನೀಡುತ್ತದೆ. OpenVPN 2.6 ಕೈಪಿಡಿ ಸ್ಥಿತಿ ಫೈಲ್ ಮತ್ತು ರೂಪಿಸುವಿಕೆ ಆಯ್ಕೆಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ನಿಮಗೆ ಹೋಸ್ಟ್ ಬದಿಯ ನಿಖರ ಸೂಚನೆಗಳು ಬೇಕಾದರೆ.