ಕುಬರ್ನೆಟ್ಸ್: CPU ಮಿತಿಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ನಿಮ್ಮ ಸೇವೆಗಳನ್ನು ವೇಗಗೊಳಿಸಿ

2016 ರಲ್ಲಿ ನಾವು ಬಫರ್‌ಗೆ ಹಿಂತಿರುಗಿದ್ದೇವೆ ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಬದಲಾಯಿಸಿದರು, ಮತ್ತು ಈಗ ಸುಮಾರು 60 ನೋಡ್‌ಗಳು (AWS ನಲ್ಲಿ) ಮತ್ತು 1500 ಕಂಟೈನರ್‌ಗಳು ನಿರ್ವಹಿಸುತ್ತಿರುವ ನಮ್ಮ k8s ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ ಕಿಕ್. ಆದಾಗ್ಯೂ, ನಾವು ಪ್ರಯೋಗ ಮತ್ತು ದೋಷದ ಮೂಲಕ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗೆ ತೆರಳಿದ್ದೇವೆ ಮತ್ತು ಹಲವಾರು ವರ್ಷಗಳ k8s ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ ನಂತರವೂ ನಾವು ಇನ್ನೂ ಹೊಸ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿದ್ದೇವೆ. ಈ ಪೋಸ್ಟ್ನಲ್ಲಿ ನಾವು ಮಾತನಾಡುತ್ತೇವೆ ಪ್ರೊಸೆಸರ್ ಮಿತಿಗಳು: ಅವು ಒಳ್ಳೆಯ ಅಭ್ಯಾಸ ಎಂದು ನಾವು ಏಕೆ ಭಾವಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವು ಏಕೆ ಉತ್ತಮವಾಗಿಲ್ಲ ಎಂದು ಕೊನೆಗೊಂಡಿತು.

ಪ್ರೊಸೆಸರ್ ಮಿತಿಗಳು ಮತ್ತು ಥ್ರೊಟ್ಲಿಂಗ್

ಇತರ ಕುಬರ್ನೆಟ್ ಬಳಕೆದಾರರಂತೆ, CPU ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸಲು Google ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ. ಅಂತಹ ಸೆಟ್ಟಿಂಗ್ ಇಲ್ಲದೆ, ನೋಡ್‌ನಲ್ಲಿರುವ ಕಂಟೈನರ್‌ಗಳು ಎಲ್ಲಾ ಪ್ರೊಸೆಸರ್ ಶಕ್ತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಇದು ಪ್ರಮುಖ ಕುಬರ್ನೆಟ್ಸ್ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ (ಉದಾಹರಣೆಗೆ. kubelet) ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, CPU ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸುವುದು ನಿಮ್ಮ ನೋಡ್‌ಗಳನ್ನು ರಕ್ಷಿಸಲು ಉತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ.

ಪ್ರೊಸೆಸರ್ ಮಿತಿಗಳು ಧಾರಕವನ್ನು ನಿರ್ದಿಷ್ಟ ಅವಧಿಗೆ ಬಳಸಬಹುದಾದ ಗರಿಷ್ಠ CPU ಸಮಯಕ್ಕೆ ಹೊಂದಿಸುತ್ತದೆ (ಡೀಫಾಲ್ಟ್ 100ms), ಮತ್ತು ಕಂಟೇನರ್ ಈ ಮಿತಿಯನ್ನು ಮೀರುವುದಿಲ್ಲ. ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಥ್ರೊಟ್ಲಿಂಗ್ ಕಂಟೇನರ್ ಮತ್ತು ಮಿತಿಯನ್ನು ಮೀರದಂತೆ ತಡೆಯಿರಿ, ವಿಶೇಷ ಸಾಧನವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ CFS ಕೋಟಾ, ಆದರೆ ಈ ಕೃತಕ CPU ಮಿತಿಗಳು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೋಯಿಸುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ಕಂಟೈನರ್‌ಗಳ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ.

ನಾವು ಪ್ರೊಸೆಸರ್ ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸದಿದ್ದರೆ ಏನಾಗಬಹುದು?

ದುರದೃಷ್ಟವಶಾತ್, ನಾವೇ ಈ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಬೇಕಾಯಿತು. ಪ್ರತಿಯೊಂದು ನೋಡ್ ಧಾರಕಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಜವಾಬ್ದಾರಿಯುತ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೊಂದಿದೆ kubelet, ಮತ್ತು ಅವರು ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದರು. ನೋಡ್, ಇದು ಸಂಭವಿಸಿದಾಗ, ರಾಜ್ಯಕ್ಕೆ ಹೋಗುತ್ತದೆ NotReady, ಮತ್ತು ಅದರಿಂದ ಕಂಟೈನರ್‌ಗಳನ್ನು ಬೇರೆಡೆಗೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ನೋಡ್‌ಗಳಲ್ಲಿ ಅದೇ ಸಮಸ್ಯೆಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ. ಕನಿಷ್ಠ ಹೇಳಲು ಆದರ್ಶ ಸನ್ನಿವೇಶವಲ್ಲ.

ಥ್ರೊಟ್ಲಿಂಗ್ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಸ್ಯೆಯ ಅಭಿವ್ಯಕ್ತಿ

ಕಂಟೇನರ್ ಟ್ರ್ಯಾಕಿಂಗ್‌ನ ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್ ಆಗಿದೆ trottling, ನಿಮ್ಮ ಕಂಟೇನರ್ ಅನ್ನು ಎಷ್ಟು ಬಾರಿ ಥ್ರೊಟಲ್ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ಇದು ತೋರಿಸುತ್ತದೆ. ಪ್ರೊಸೆಸರ್ ಲೋಡ್ ವಿಪರೀತವಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ ಕೆಲವು ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಥ್ರೊಟ್ಲಿಂಗ್ ಇರುವಿಕೆಯನ್ನು ನಾವು ಆಸಕ್ತಿಯಿಂದ ಗಮನಿಸಿದ್ದೇವೆ. ಉದಾಹರಣೆಯಾಗಿ, ನಮ್ಮ ಮುಖ್ಯ API ಗಳಲ್ಲಿ ಒಂದನ್ನು ನೋಡೋಣ:

ನೀವು ಕೆಳಗೆ ನೋಡುವಂತೆ, ನಾವು ಮಿತಿಯನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ 800m (0.8 ಅಥವಾ 80% ಕೋರ್), ಮತ್ತು ಗರಿಷ್ಠ ಮೌಲ್ಯಗಳು ಅತ್ಯುತ್ತಮವಾಗಿ ತಲುಪುತ್ತವೆ 200m (20% ಕೋರ್). ಸೇವೆಯನ್ನು ಥ್ರೊಟಲ್ ಮಾಡುವ ಮೊದಲು ನಾವು ಇನ್ನೂ ಸಾಕಷ್ಟು ಪ್ರೊಸೆಸರ್ ಶಕ್ತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದಾಗ್ಯೂ...

ಪ್ರೊಸೆಸರ್ ಲೋಡ್ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮಿತಿಗಳಿಗಿಂತ ಕಡಿಮೆಯಿದ್ದರೂ ಸಹ - ಗಮನಾರ್ಹವಾಗಿ ಕೆಳಗೆ - ಥ್ರೊಟ್ಲಿಂಗ್ ಇನ್ನೂ ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ನೀವು ಗಮನಿಸಿರಬಹುದು.

ಇದನ್ನು ಎದುರಿಸಿದ ನಾವು ಶೀಘ್ರದಲ್ಲೇ ಹಲವಾರು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ (ಗಿಥಬ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆ, ಝಡಾನೋದಲ್ಲಿ ಪ್ರಸ್ತುತಿ, omio ನಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡಿ) ಥ್ರೊಟ್ಲಿಂಗ್‌ನಿಂದಾಗಿ ಸೇವೆಗಳ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯದ ಕುಸಿತದ ಬಗ್ಗೆ.

ಕಡಿಮೆ CPU ಲೋಡ್‌ನಲ್ಲಿ ನಾವು ಥ್ರೊಟ್ಲಿಂಗ್ ಅನ್ನು ಏಕೆ ನೋಡುತ್ತೇವೆ? ಚಿಕ್ಕ ಆವೃತ್ತಿಯು ಹೀಗಿದೆ: "Linux ಕರ್ನಲ್‌ನಲ್ಲಿ ಒಂದು ದೋಷವಿದೆ ಅದು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಪ್ರೊಸೆಸರ್ ಮಿತಿಗಳೊಂದಿಗೆ ಕಂಟೇನರ್‌ಗಳ ಅನಗತ್ಯ ಥ್ರೊಟ್ಲಿಂಗ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ." ಸಮಸ್ಯೆಯ ಸ್ವರೂಪದಲ್ಲಿ ನೀವು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ನೀವು ಪ್ರಸ್ತುತಿಯನ್ನು ಓದಬಹುದು (видео и ಪಠ್ಯ ಆಯ್ಕೆಗಳು) ಡೇವ್ ಚಿಲುಕ್ ಅವರಿಂದ.

CPU ನಿರ್ಬಂಧಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತಿದೆ (ತೀವ್ರ ಎಚ್ಚರಿಕೆಯೊಂದಿಗೆ)

ಸುದೀರ್ಘ ಚರ್ಚೆಗಳ ನಂತರ, ನಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ನಿರ್ಣಾಯಕ ಕಾರ್ಯವನ್ನು ನೇರವಾಗಿ ಅಥವಾ ಪರೋಕ್ಷವಾಗಿ ಪರಿಣಾಮ ಬೀರುವ ಎಲ್ಲಾ ಸೇವೆಗಳಿಂದ ಪ್ರೊಸೆಸರ್ ನಿರ್ಬಂಧಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಿರತೆಯನ್ನು ನಾವು ಹೆಚ್ಚು ಗೌರವಿಸುವ ಕಾರಣ ನಿರ್ಧಾರವು ಸುಲಭವಲ್ಲ. ಹಿಂದೆ, ನಾವು ಈಗಾಗಲೇ ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನ ಅಸ್ಥಿರತೆಯನ್ನು ಪ್ರಯೋಗಿಸಿದ್ದೇವೆ ಮತ್ತು ನಂತರ ಸೇವೆಗಳು ಹಲವಾರು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇವಿಸಿದವು ಮತ್ತು ಅವುಗಳ ಸಂಪೂರ್ಣ ನೋಡ್‌ನ ಕೆಲಸವನ್ನು ನಿಧಾನಗೊಳಿಸಿದವು. ಈಗ ಎಲ್ಲವೂ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿದೆ: ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗಳಿಂದ ನಾವು ಏನನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ ಎಂಬುದರ ಬಗ್ಗೆ ನಮಗೆ ಸ್ಪಷ್ಟವಾದ ತಿಳುವಳಿಕೆ ಇತ್ತು, ಜೊತೆಗೆ ಯೋಜಿತ ಬದಲಾವಣೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಉತ್ತಮ ತಂತ್ರವಾಗಿದೆ.

ಒತ್ತುವ ಸಮಸ್ಯೆಯ ಮೇಲೆ ವ್ಯಾಪಾರ ಪತ್ರವ್ಯವಹಾರ.

ನಿರ್ಬಂಧಗಳನ್ನು ತೆಗೆದುಹಾಕಿದಾಗ ನಿಮ್ಮ ನೋಡ್‌ಗಳನ್ನು ಹೇಗೆ ರಕ್ಷಿಸುವುದು?

"ಅನಿರ್ಬಂಧಿತ" ಸೇವೆಗಳ ಪ್ರತ್ಯೇಕತೆ:

ಹಿಂದೆ, ಕೆಲವು ನೋಡ್‌ಗಳು ಸ್ಥಿತಿಗೆ ಬರುವುದನ್ನು ನಾವು ಈಗಾಗಲೇ ನೋಡಿದ್ದೇವೆ notReady, ಪ್ರಾಥಮಿಕವಾಗಿ ಹಲವಾರು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇವಿಸಿದ ಸೇವೆಗಳಿಂದಾಗಿ.

ಅಂತಹ ಸೇವೆಗಳನ್ನು ಪ್ರತ್ಯೇಕ ("ಲೇಬಲ್") ನೋಡ್‌ಗಳಲ್ಲಿ ಇರಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಇದರಿಂದ ಅವರು "ಸಂಬಂಧಿತ" ಸೇವೆಗಳಲ್ಲಿ ಮಧ್ಯಪ್ರವೇಶಿಸುವುದಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ಕೆಲವು ನೋಡ್‌ಗಳನ್ನು ಗುರುತಿಸುವ ಮೂಲಕ ಮತ್ತು "ಸಂಬಂಧವಿಲ್ಲದ" ಸೇವೆಗಳಿಗೆ ಸಹಿಷ್ಣುತೆಯ ನಿಯತಾಂಕವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ, ನಾವು ಕ್ಲಸ್ಟರ್‌ನ ಮೇಲೆ ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣವನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ ಮತ್ತು ನೋಡ್‌ಗಳೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಲು ನಮಗೆ ಸುಲಭವಾಯಿತು. ಇದೇ ರೀತಿಯ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನೀವೇ ಕೈಗೊಳ್ಳಲು, ನೀವೇ ಪರಿಚಿತರಾಗಬಹುದು ದಸ್ತಾವೇಜನ್ನು.

ಸರಿಯಾದ ಪ್ರೊಸೆಸರ್ ಮತ್ತು ಮೆಮೊರಿ ವಿನಂತಿಯನ್ನು ನಿಯೋಜಿಸಲಾಗುತ್ತಿದೆ:

ಪ್ರಕ್ರಿಯೆಯು ಹಲವಾರು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ನೋಡ್ ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಎಂಬುದು ನಮ್ಮ ದೊಡ್ಡ ಭಯವಾಗಿತ್ತು. ಇಂದಿನಿಂದ (ಡೇಟಾಡಾಗ್‌ಗೆ ಧನ್ಯವಾದಗಳು) ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ನಾವು ಸ್ಪಷ್ಟವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು, ನಾವು "ಸಂಬಂಧವಿಲ್ಲದ" ಎಂದು ಗೊತ್ತುಪಡಿಸಲು ಯೋಜಿಸಿರುವ ಹಲವಾರು ತಿಂಗಳ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಾನು ವಿಶ್ಲೇಷಿಸಿದೆ. ನಾನು ಗರಿಷ್ಠ CPU ಬಳಕೆಯನ್ನು 20% ಅಂಚುಗಳೊಂದಿಗೆ ಹೊಂದಿಸಿದ್ದೇನೆ ಮತ್ತು k8s ಇತರ ಸೇವೆಗಳನ್ನು ನೋಡ್‌ಗೆ ನಿಯೋಜಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ ನೋಡ್‌ನಲ್ಲಿ ಜಾಗವನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ.

ಗ್ರಾಫ್ನಲ್ಲಿ ನೀವು ನೋಡುವಂತೆ, ಪ್ರೊಸೆಸರ್ನಲ್ಲಿ ಗರಿಷ್ಠ ಲೋಡ್ ತಲುಪಿದೆ 242m CPU ಕೋರ್ಗಳು (0.242 ಪ್ರೊಸೆಸರ್ ಕೋರ್ಗಳು). ಪ್ರೊಸೆಸರ್ ವಿನಂತಿಗಾಗಿ, ಈ ಮೌಲ್ಯಕ್ಕಿಂತ ಸ್ವಲ್ಪ ದೊಡ್ಡ ಸಂಖ್ಯೆಯನ್ನು ತೆಗೆದುಕೊಂಡರೆ ಸಾಕು. ಸೇವೆಗಳು ಬಳಕೆದಾರ ಕೇಂದ್ರಿತವಾಗಿರುವುದರಿಂದ, ಗರಿಷ್ಠ ಲೋಡ್ ಮೌಲ್ಯಗಳು ದಟ್ಟಣೆಯೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ.

ಮೆಮೊರಿ ಬಳಕೆ ಮತ್ತು ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ಅದೇ ರೀತಿ ಮಾಡಿ, ಮತ್ತು voila - ನೀವು ಎಲ್ಲವನ್ನೂ ಹೊಂದಿಸಿರುವಿರಿ! ಹೆಚ್ಚಿನ ಭದ್ರತೆಗಾಗಿ, ನೀವು ಅಡ್ಡಲಾಗಿರುವ ಪಾಡ್ ಆಟೋಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಸೇರಿಸಬಹುದು. ಹೀಗಾಗಿ, ಪ್ರತಿ ಬಾರಿ ಸಂಪನ್ಮೂಲ ಲೋಡ್ ಹೆಚ್ಚಾದಾಗ, ಆಟೋಸ್ಕೇಲಿಂಗ್ ಹೊಸ ಪಾಡ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳು ಅವುಗಳನ್ನು ಮುಕ್ತ ಸ್ಥಳದೊಂದಿಗೆ ನೋಡ್‌ಗಳಿಗೆ ವಿತರಿಸುತ್ತವೆ. ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿಯೇ ಯಾವುದೇ ಸ್ಥಳಾವಕಾಶವಿಲ್ಲದಿದ್ದರೆ, ನೀವೇ ಎಚ್ಚರಿಕೆಯನ್ನು ಹೊಂದಿಸಬಹುದು ಅಥವಾ ಅವುಗಳ ಸ್ವಯಂ ಸ್ಕೇಲಿಂಗ್ ಮೂಲಕ ಹೊಸ ನೋಡ್‌ಗಳ ಸೇರ್ಪಡೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.

ಮೈನಸಸ್‌ಗಳಲ್ಲಿ, ನಾವು ಕಳೆದುಕೊಂಡಿರುವುದು ಗಮನಿಸಬೇಕಾದ ಸಂಗತಿ "ಕಂಟೇನರ್ ಸಾಂದ್ರತೆ", ಅಂದರೆ ಒಂದು ನೋಡ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಧಾರಕಗಳ ಸಂಖ್ಯೆ. ಕಡಿಮೆ ಟ್ರಾಫಿಕ್ ಸಾಂದ್ರತೆಯಲ್ಲಿ ನಾವು ಸಾಕಷ್ಟು "ವಿಶ್ರಾಂತಿಗಳನ್ನು" ಹೊಂದಿರಬಹುದು ಮತ್ತು ನೀವು ಹೆಚ್ಚಿನ ಪ್ರೊಸೆಸರ್ ಲೋಡ್ ಅನ್ನು ತಲುಪುವ ಅವಕಾಶವೂ ಇದೆ, ಆದರೆ ಆಟೋಸ್ಕೇಲಿಂಗ್ ನೋಡ್‌ಗಳು ಎರಡನೆಯದಕ್ಕೆ ಸಹಾಯ ಮಾಡಬೇಕು.

ರೆಸೆಲ್ಯೂಟ್ಸ್

ಕಳೆದ ಕೆಲವು ವಾರಗಳಲ್ಲಿ ಪ್ರಯೋಗಗಳಿಂದ ಈ ಅತ್ಯುತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರಕಟಿಸಲು ನನಗೆ ಸಂತೋಷವಾಗಿದೆ; ಎಲ್ಲಾ ಮಾರ್ಪಡಿಸಿದ ಸೇವೆಗಳಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ನಾವು ಈಗಾಗಲೇ ಗಮನಾರ್ಹ ಸುಧಾರಣೆಗಳನ್ನು ನೋಡಿದ್ದೇವೆ:

ನಮ್ಮ ಮುಖಪುಟದಲ್ಲಿ ನಾವು ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ (buffer.com), ಅಲ್ಲಿ ಸೇವೆಯು ವೇಗಗೊಂಡಿತು ಇಪ್ಪತ್ತೆರಡು ಬಾರಿ!

ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ದೋಷವನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆಯೇ?

ಹೌದು, ದೋಷವನ್ನು ಈಗಾಗಲೇ ಸರಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಫಿಕ್ಸ್ ಅನ್ನು ಕರ್ನಲ್‌ಗೆ ಸೇರಿಸಲಾಗಿದೆ ವಿತರಣೆಗಳ ಆವೃತ್ತಿ 4.19 ಮತ್ತು ಹೆಚ್ಚಿನದು.

ಆದಾಗ್ಯೂ, ಓದಿದ ಮೇಲೆ ಗಿಥಬ್‌ನಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಸಮಸ್ಯೆಗಳು ಸೆಪ್ಟೆಂಬರ್ 2020 ರ ಎರಡನೇ ವರೆಗೆ ಇದೇ ರೀತಿಯ ದೋಷವಿರುವ ಕೆಲವು ಲಿನಕ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳ ಉಲ್ಲೇಖಗಳನ್ನು ನಾವು ಇನ್ನೂ ಕಾಣುತ್ತೇವೆ. ಕೆಲವು ಲಿನಕ್ಸ್ ವಿತರಣೆಗಳು ಇನ್ನೂ ಈ ದೋಷವನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಅದನ್ನು ಸರಿಪಡಿಸಲು ಕೆಲಸ ಮಾಡುತ್ತಿವೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ.

ನಿಮ್ಮ ವಿತರಣಾ ಆವೃತ್ತಿಯು 4.19 ಕ್ಕಿಂತ ಕಡಿಮೆಯಿದ್ದರೆ, ಇತ್ತೀಚಿನದಕ್ಕೆ ನವೀಕರಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ, ಆದರೆ ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ನೀವು ಪ್ರೊಸೆಸರ್ ನಿರ್ಬಂಧಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಪ್ರಯತ್ನಿಸಬೇಕು ಮತ್ತು ಥ್ರೊಟ್ಲಿಂಗ್ ಮುಂದುವರಿದಿದೆಯೇ ಎಂದು ನೋಡಬೇಕು. ಕೆಳಗೆ ನೀವು Kubernetes ನಿರ್ವಹಣಾ ಸೇವೆಗಳು ಮತ್ತು Linux ವಿತರಣೆಗಳ ಭಾಗಶಃ ಪಟ್ಟಿಯನ್ನು ನೋಡಬಹುದು:

• ಡೆಬಿಯನ್: ವಿತರಣೆಯ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗೆ ಸಂಯೋಜಿತವಾದ ಫಿಕ್ಸ್, ಬಸ್ಟರ್, ಮತ್ತು ಸಾಕಷ್ಟು ತಾಜಾ ಕಾಣುತ್ತದೆ (ಆಗಸ್ಟ್ 2020) ಕೆಲವು ಹಿಂದಿನ ಆವೃತ್ತಿಗಳನ್ನು ಸಹ ಸರಿಪಡಿಸಬಹುದು.
• ಉಬುಂಟು: ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ ಸರಿಪಡಿಸಿ ಉಬುಂಟು ಫೋಕಲ್ ಫೊಸಾ 20.04
• EKS ಗೆ ಇನ್ನೂ ಪರಿಹಾರ ಸಿಕ್ಕಿದೆ ಡಿಸೆಂಬರ್ 2019 ರಲ್ಲಿ. ನಿಮ್ಮ ಆವೃತ್ತಿಯು ಇದಕ್ಕಿಂತ ಕಡಿಮೆಯಿದ್ದರೆ, ನೀವು AMI ಅನ್ನು ನವೀಕರಿಸಬೇಕು.
• ಕಾಪ್ಸ್: ಜೂನ್ 2020 ರಿಂದ у kops 1.18+ ಮುಖ್ಯ ಹೋಸ್ಟ್ ಚಿತ್ರವು ಉಬುಂಟು 20.04 ಆಗಿರುತ್ತದೆ. ನಿಮ್ಮ ಕಾಪ್ಸ್ ಆವೃತ್ತಿಯು ಹಳೆಯದಾಗಿದ್ದರೆ, ನೀವು ಸರಿಪಡಿಸಲು ಕಾಯಬೇಕಾಗಬಹುದು. ನಾವೇ ಈಗ ಕಾಯುತ್ತಿದ್ದೇವೆ.
• GKE (ಗೂಗಲ್ ಕ್ಲೌಡ್): ಫಿಕ್ಸ್ ಇಂಟಿಗ್ರೇಟೆಡ್ ಜನವರಿ 2020 ರಲ್ಲಿ, ಆದಾಗ್ಯೂ ಥ್ರೊಟ್ಲಿಂಗ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿವೆ ಈಗಲೂ ಗಮನಿಸಲಾಗುತ್ತದೆ.

ಪರಿಹಾರವು ಥ್ರೊಟ್ಲಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದರೆ ಏನು ಮಾಡಬೇಕು?

ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸಲಾಗಿದೆ ಎಂದು ನನಗೆ ಖಚಿತವಿಲ್ಲ. ನಾವು ಸರಿಪಡಿಸುವಿಕೆಯೊಂದಿಗೆ ಕರ್ನಲ್ ಆವೃತ್ತಿಗೆ ಬಂದಾಗ, ನಾನು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತೇನೆ ಮತ್ತು ಪೋಸ್ಟ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತೇನೆ. ಯಾರಾದರೂ ಈಗಾಗಲೇ ನವೀಕರಿಸಿದ್ದರೆ, ನಿಮ್ಮ ಫಲಿತಾಂಶಗಳನ್ನು ಓದಲು ನಾನು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ.

ತೀರ್ಮಾನಕ್ಕೆ

• ನೀವು Linux ಅಡಿಯಲ್ಲಿ ಡಾಕರ್ ಕಂಟೈನರ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ (ಕುಬರ್ನೆಟ್ಸ್, ಮೆಸೊಸ್, ಸಮೂಹ ಅಥವಾ ಇತರವುಗಳು ಪರವಾಗಿಲ್ಲ), ನಿಮ್ಮ ಕಂಟೇನರ್‌ಗಳು ಥ್ರೊಟ್ಲಿಂಗ್‌ನಿಂದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು;
• ದೋಷವನ್ನು ಈಗಾಗಲೇ ಸರಿಪಡಿಸಲಾಗಿದೆ ಎಂಬ ಭರವಸೆಯಲ್ಲಿ ನಿಮ್ಮ ವಿತರಣೆಯ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗೆ ನವೀಕರಿಸಲು ಪ್ರಯತ್ನಿಸಿ;
• ಪ್ರೊಸೆಸರ್ ಮಿತಿಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಆದರೆ ಇದು ಅತ್ಯಂತ ಎಚ್ಚರಿಕೆಯಿಂದ ಬಳಸಬೇಕಾದ ಅಪಾಯಕಾರಿ ತಂತ್ರವಾಗಿದೆ (ಮೊದಲು ಕರ್ನಲ್ ಅನ್ನು ನವೀಕರಿಸುವುದು ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಹೋಲಿಸುವುದು ಉತ್ತಮ);
• ನೀವು CPU ಮಿತಿಗಳನ್ನು ತೆಗೆದುಹಾಕಿದ್ದರೆ, ನಿಮ್ಮ CPU ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ ಮತ್ತು ನಿಮ್ಮ CPU ಸಂಪನ್ಮೂಲಗಳು ನಿಮ್ಮ ಬಳಕೆಯನ್ನು ಮೀರುತ್ತಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ;
• ಹೆಚ್ಚಿನ ಹಾರ್ಡ್‌ವೇರ್ ಲೋಡ್ ಸಂದರ್ಭದಲ್ಲಿ ಹೊಸ ಪಾಡ್‌ಗಳನ್ನು ರಚಿಸಲು ಪಾಡ್‌ಗಳನ್ನು ಸ್ವಯಂ-ಸ್ಕೇಲ್ ಮಾಡುವುದು ಸುರಕ್ಷಿತ ಆಯ್ಕೆಯಾಗಿದೆ, ಇದರಿಂದಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಅವುಗಳನ್ನು ಉಚಿತ ನೋಡ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸುತ್ತದೆ.

ನಿಮ್ಮ ಕಂಟೇನರ್ ಸಿಸ್ಟಂಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಈ ಪೋಸ್ಟ್ ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಪಿಎಸ್ ಇದು ಲೇಖಕರು ಓದುಗರು ಮತ್ತು ವ್ಯಾಖ್ಯಾನಕಾರರೊಂದಿಗೆ (ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿ) ಅನುರೂಪವಾಗಿದೆ.


ಮೂಲ: www.habr.com