ಅನೇಕ ಜನರು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದೊಂದಿಗೆ ಹೋರಾಡುತ್ತಾರೆ. ಆದರೆ ಲಾಗ್‌ಗಳನ್ನು "ನಿರ್ದಿಷ್ಟವಾಗಿ ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ" ಸಂಗ್ರಹಿಸಲು ನೀವು ಅದನ್ನು ಬಳಸಲು ಬಯಸಿದಾಗ ಏನಾಗುತ್ತದೆ? ಮತ್ತು ಹಲವಾರು ಡೇಟಾ ಸೆಂಟರ್‌ಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ವೈಫಲ್ಯವನ್ನು ಅನುಭವಿಸಲು ನೋವುರಹಿತವಾಗಿದೆಯೇ? ನೀವು ಯಾವ ರೀತಿಯ ವಾಸ್ತುವನ್ನು ಮಾಡಬೇಕು, ಮತ್ತು ನೀವು ಯಾವ ಅಪಾಯಗಳನ್ನು ಎದುರಿಸುತ್ತೀರಿ?
Odnoklassniki ನಲ್ಲಿ ನಾವು ಲಾಗ್ ನಿರ್ವಹಣೆಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟವನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಈಗ ನಾವು ನಮ್ಮ ಅನುಭವವನ್ನು Habr ನೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ: ವಾಸ್ತುಶಿಲ್ಪದ ಬಗ್ಗೆ ಮತ್ತು ಮೋಸಗಳ ಬಗ್ಗೆ.
ನಾನು ಪಯೋಟರ್ ಜೈಟ್ಸೆವ್, ನಾನು ಓಡ್ನೋಕ್ಲಾಸ್ನಿಕಿಯಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ಅದಕ್ಕೂ ಮೊದಲು, ನಾನು ನಿರ್ವಾಹಕನಾಗಿದ್ದೆ, ಮ್ಯಾಂಟಿಕೋರ್ ಹುಡುಕಾಟ, ಸಿಂಹನಾರಿ ಹುಡುಕಾಟ, ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ. ಬಹುಶಃ, ಇನ್ನೊಂದು ... ಹುಡುಕಾಟ ಕಾಣಿಸಿಕೊಂಡರೆ, ನಾನು ಬಹುಶಃ ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ನಾನು ಸ್ವಯಂಪ್ರೇರಿತ ಆಧಾರದ ಮೇಲೆ ಹಲವಾರು ಮುಕ್ತ ಮೂಲ ಯೋಜನೆಗಳಲ್ಲಿ ಭಾಗವಹಿಸುತ್ತೇನೆ.
ನಾನು ಓಡ್ನೋಕ್ಲಾಸ್ನಿಕಿಗೆ ಬಂದಾಗ, ನಾನು ಎಲಾಸ್ಟಿಕ್ ಸರ್ಚ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದೆಂದು ಸಂದರ್ಶನದಲ್ಲಿ ಅಜಾಗರೂಕತೆಯಿಂದ ಹೇಳಿದೆ. ನಾನು ಅದರ ಹ್ಯಾಂಗ್ ಅನ್ನು ಪಡೆದುಕೊಂಡು ಕೆಲವು ಸರಳ ಕಾರ್ಯಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ ನಂತರ, ಆ ಸಮಯದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ಲಾಗ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸುಧಾರಿಸುವ ದೊಡ್ಡ ಕೆಲಸವನ್ನು ನನಗೆ ನೀಡಲಾಯಿತು.
ಅವಶ್ಯಕತೆಗಳನ್ನು
ಸಿಸ್ಟಮ್ ಅವಶ್ಯಕತೆಗಳನ್ನು ಈ ಕೆಳಗಿನಂತೆ ರೂಪಿಸಲಾಗಿದೆ:
- ಗ್ರೇಲಾಗ್ ಅನ್ನು ಮುಂಭಾಗವಾಗಿ ಬಳಸಬೇಕಾಗಿತ್ತು. ಕಂಪನಿಯು ಈಗಾಗಲೇ ಈ ಉತ್ಪನ್ನವನ್ನು ಬಳಸುವ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದರಿಂದ, ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಮತ್ತು ಪರೀಕ್ಷಕರು ಅದನ್ನು ತಿಳಿದಿದ್ದರು, ಇದು ಅವರಿಗೆ ಪರಿಚಿತ ಮತ್ತು ಅನುಕೂಲಕರವಾಗಿದೆ.
- ಡೇಟಾ ಪರಿಮಾಣ: ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸರಾಸರಿ 50-80 ಸಾವಿರ ಸಂದೇಶಗಳು, ಆದರೆ ಏನಾದರೂ ಮುರಿದರೆ, ಸಂಚಾರವು ಯಾವುದಕ್ಕೂ ಸೀಮಿತವಾಗಿಲ್ಲ, ಅದು ಸೆಕೆಂಡಿಗೆ 2-3 ಮಿಲಿಯನ್ ಸಾಲುಗಳಾಗಿರಬಹುದು
- ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ವೇಗದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಗ್ರಾಹಕರೊಂದಿಗೆ ಚರ್ಚಿಸಿದ ನಂತರ, ಅಂತಹ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುವ ವಿಶಿಷ್ಟ ಮಾದರಿ ಇದು ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ: ಜನರು ಕಳೆದ ಎರಡು ದಿನಗಳಿಂದ ತಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಲಾಗ್‌ಗಳನ್ನು ಹುಡುಕುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಹೆಚ್ಚು ಕಾಯಲು ಬಯಸುವುದಿಲ್ಲ ಸೂತ್ರೀಕರಿಸಿದ ಪ್ರಶ್ನೆಯ ಫಲಿತಾಂಶಕ್ಕಾಗಿ ಎರಡನೆಯದು.
- ನಿರ್ವಾಹಕರು ವ್ಯವಸ್ಥೆಯು ಅಗತ್ಯವಿದ್ದಲ್ಲಿ ಸುಲಭವಾಗಿ ಸ್ಕೇಲೆಬಲ್ ಆಗಿರಬೇಕು ಎಂದು ಒತ್ತಾಯಿಸಿದರು, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಆಳವಾಗಿ ಪರಿಶೀಲಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.
- ಆದ್ದರಿಂದ ಈ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ನಿಯತಕಾಲಿಕವಾಗಿ ಅಗತ್ಯವಿರುವ ಏಕೈಕ ನಿರ್ವಹಣಾ ಕಾರ್ಯವೆಂದರೆ ಕೆಲವು ಯಂತ್ರಾಂಶವನ್ನು ಬದಲಾಯಿಸುವುದು.
- ಹೆಚ್ಚುವರಿಯಾಗಿ, Odnoklassniki ಅತ್ಯುತ್ತಮ ತಾಂತ್ರಿಕ ಸಂಪ್ರದಾಯವನ್ನು ಹೊಂದಿದೆ: ನಾವು ಪ್ರಾರಂಭಿಸುವ ಯಾವುದೇ ಸೇವೆಯು ಡೇಟಾ ಸೆಂಟರ್ ವೈಫಲ್ಯದಿಂದ ಬದುಕುಳಿಯಬೇಕು (ಹಠಾತ್, ಯೋಜಿತವಲ್ಲದ ಮತ್ತು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ).
ಈ ಯೋಜನೆಯ ಅನುಷ್ಠಾನದಲ್ಲಿ ಕೊನೆಯ ಅವಶ್ಯಕತೆಯು ನಮಗೆ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುತ್ತದೆ, ಅದನ್ನು ನಾನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಮಾತನಾಡುತ್ತೇನೆ.
ಪರಿಸರ
ನಾವು ನಾಲ್ಕು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ, ಆದರೆ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ ಡೇಟಾ ನೋಡ್ಗಳನ್ನು ಕೇವಲ ಮೂರರಲ್ಲಿ ಮಾತ್ರ ಇರಿಸಬಹುದು (ಹಲವಾರು ತಾಂತ್ರಿಕವಲ್ಲದ ಕಾರಣಗಳಿಗಾಗಿ).
ಈ ನಾಲ್ಕು ಡೇಟಾ ಕೇಂದ್ರಗಳು ಸರಿಸುಮಾರು 18 ಸಾವಿರ ವಿವಿಧ ಲಾಗ್ ಮೂಲಗಳನ್ನು ಒಳಗೊಂಡಿವೆ - ಹಾರ್ಡ್‌ವೇರ್, ಕಂಟೈನರ್‌ಗಳು, ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು.
ಪ್ರಮುಖ ವೈಶಿಷ್ಟ್ಯ: ಕ್ಲಸ್ಟರ್ ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಭೌತಿಕ ಯಂತ್ರಗಳಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ ಆನ್ . ಕಂಟೇನರ್‌ಗಳು 2Ghz v2.0 ಗೆ ಹೋಲುವ 4 ಕೋರ್‌ಗಳನ್ನು ಖಾತರಿಪಡಿಸಲಾಗುತ್ತದೆ, ಉಳಿದ ಕೋರ್‌ಗಳು ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದರೆ ಅವುಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ಸಾಧ್ಯತೆಯಿದೆ.
ಬೇರೆ ಪದಗಳಲ್ಲಿ:
ಸ್ಥಳಶಾಸ್ತ್ರ
ನಾನು ಆರಂಭದಲ್ಲಿ ಪರಿಹಾರದ ಸಾಮಾನ್ಯ ರೂಪವನ್ನು ಈ ಕೆಳಗಿನಂತೆ ನೋಡಿದೆ:
- 3-4 ವಿಐಪಿಗಳು ಗ್ರೇಲಾಗ್ ಡೊಮೇನ್‌ನ ಎ-ರೆಕಾರ್ಡ್‌ನ ಹಿಂದೆ ಇದ್ದಾರೆ, ಇದು ಲಾಗ್‌ಗಳನ್ನು ಕಳುಹಿಸುವ ವಿಳಾಸವಾಗಿದೆ.
- ಪ್ರತಿ ವಿಐಪಿ ಎಲ್ವಿಎಸ್ ಬ್ಯಾಲೆನ್ಸರ್ ಆಗಿದೆ.
- ಅದರ ನಂತರ, ಲಾಗ್‌ಗಳು ಗ್ರೇಲಾಗ್ ಬ್ಯಾಟರಿಗೆ ಹೋಗುತ್ತವೆ, ಕೆಲವು ಡೇಟಾವು GELF ಸ್ವರೂಪದಲ್ಲಿದೆ, ಕೆಲವು ಸಿಸ್ಲಾಗ್ ಸ್ವರೂಪದಲ್ಲಿದೆ.
- ನಂತರ ಇದೆಲ್ಲವನ್ನೂ ಎಲಾಸ್ಟಿಕ್ ಸರ್ಚ್ ಸಂಯೋಜಕಗಳ ಬ್ಯಾಟರಿಗೆ ದೊಡ್ಡ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಬರೆಯಲಾಗುತ್ತದೆ.
- ಮತ್ತು ಅವರು ಪ್ರತಿಯಾಗಿ, ಸಂಬಂಧಿತ ಡೇಟಾ ನೋಡ್‌ಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ಬರೆಯಲು ಮತ್ತು ಓದಲು ಕಳುಹಿಸುತ್ತಾರೆ.
ಪರಿಭಾಷೆ
ಬಹುಶಃ ಪ್ರತಿಯೊಬ್ಬರೂ ಪರಿಭಾಷೆಯನ್ನು ವಿವರವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ಅದರ ಮೇಲೆ ಸ್ವಲ್ಪ ವಾಸಿಸಲು ಬಯಸುತ್ತೇನೆ.
ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟವು ಹಲವಾರು ರೀತಿಯ ನೋಡ್ಗಳನ್ನು ಹೊಂದಿದೆ - ಮಾಸ್ಟರ್, ಕೋಆರ್ಡಿನೇಟರ್, ಡೇಟಾ ನೋಡ್. ವಿಭಿನ್ನ ಲಾಗ್ ರೂಪಾಂತರಗಳು ಮತ್ತು ವಿಭಿನ್ನ ಕ್ಲಸ್ಟರ್‌ಗಳ ನಡುವಿನ ಸಂವಹನಕ್ಕಾಗಿ ಇತರ ಎರಡು ವಿಧಗಳಿವೆ, ಆದರೆ ನಾವು ಪಟ್ಟಿ ಮಾಡಲಾದವುಗಳನ್ನು ಮಾತ್ರ ಬಳಸಿದ್ದೇವೆ.
ಮಾಸ್ಟರ್
ಇದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ನೋಡ್ಗಳನ್ನು ಪಿಂಗ್ ಮಾಡುತ್ತದೆ, ಅಪ್-ಟು-ಡೇಟ್ ಕ್ಲಸ್ಟರ್ ಮ್ಯಾಪ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ನೋಡ್‌ಗಳ ನಡುವೆ ವಿತರಿಸುತ್ತದೆ, ಈವೆಂಟ್ ಲಾಜಿಕ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ವಿವಿಧ ರೀತಿಯ ಕ್ಲಸ್ಟರ್ ವೈಡ್ ಹೌಸ್‌ಕೀಪಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.
ಸಂಯೋಜಕರಾಗಿ
ಒಂದೇ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ: ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಓದುವ ಅಥವಾ ಬರೆಯುವ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಈ ದಟ್ಟಣೆಯನ್ನು ಮಾರ್ಗಗೊಳಿಸುತ್ತದೆ. ಒಂದು ವೇಳೆ ಬರೆಯುವ ವಿನಂತಿಯಿದ್ದಲ್ಲಿ, ಹೆಚ್ಚಾಗಿ, ಇದು ಸಂಬಂಧಿತ ಸೂಚ್ಯಂಕದ ಯಾವ ಚೂರುಗಳನ್ನು ಹಾಕಬೇಕೆಂದು ಮಾಸ್ಟರ್ ಅನ್ನು ಕೇಳುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಮತ್ತಷ್ಟು ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ.
ಡೇಟಾ ನೋಡ್
ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಹೊರಗಿನಿಂದ ಬರುವ ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಮೇಲೆ ಇರುವ ಚೂರುಗಳ ಮೇಲೆ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.
ಗ್ರೇಲಾಗ್
ಇದು ELK ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಲಾಗ್‌ಸ್ಟಾಶ್‌ನೊಂದಿಗೆ ಕಿಬಾನಾದ ಸಮ್ಮಿಳನದಂತಿದೆ. ಗ್ರೇಲಾಗ್ ಯುಐ ಮತ್ತು ಲಾಗ್ ಪ್ರೊಸೆಸಿಂಗ್ ಪೈಪ್‌ಲೈನ್ ಎರಡನ್ನೂ ಸಂಯೋಜಿಸುತ್ತದೆ. ಹುಡ್ ಅಡಿಯಲ್ಲಿ, ಗ್ರೇಲಾಗ್ ಕಾಫ್ಕಾ ಮತ್ತು ಝೂಕೀಪರ್ ಅನ್ನು ನಡೆಸುತ್ತದೆ, ಇದು ಕ್ಲಸ್ಟರ್‌ನಂತೆ ಗ್ರೇಲಾಗ್‌ಗೆ ಸಂಪರ್ಕವನ್ನು ಒದಗಿಸುತ್ತದೆ. Elasticsearch ಲಭ್ಯವಿಲ್ಲದಿದ್ದಲ್ಲಿ Graylog ಲಾಗ್‌ಗಳನ್ನು (ಕಾಫ್ಕಾ) ಕ್ಯಾಶ್ ಮಾಡಬಹುದು ಮತ್ತು ವಿಫಲವಾದ ಓದಲು ಮತ್ತು ಬರೆಯಲು ವಿನಂತಿಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ನಿಯಮಗಳ ಪ್ರಕಾರ ಲಾಗ್‌ಗಳನ್ನು ಗುಂಪು ಮಾಡಿ ಮತ್ತು ಗುರುತಿಸಿ. ಲಾಗ್‌ಸ್ಟ್ಯಾಶ್‌ನಂತೆ, ಎಲಾಸ್ಟಿಕ್‌ಸರ್ಚ್‌ಗೆ ಬರೆಯುವ ಮೊದಲು ಸಾಲುಗಳನ್ನು ಮಾರ್ಪಡಿಸುವ ಕಾರ್ಯವನ್ನು ಗ್ರೇಲಾಗ್ ಹೊಂದಿದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಗ್ರೇಲಾಗ್ ಅಂತರ್ನಿರ್ಮಿತ ಸೇವೆಯ ಅನ್ವೇಷಣೆಯನ್ನು ಹೊಂದಿದೆ, ಇದು ಲಭ್ಯವಿರುವ ಒಂದು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ ನೋಡ್ ಅನ್ನು ಆಧರಿಸಿ ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ನಕ್ಷೆಯನ್ನು ಪಡೆಯಲು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಟ್ಯಾಗ್ ಮೂಲಕ ಅದನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ, ಇದು ನಿರ್ದಿಷ್ಟ ಕಂಟೈನರ್‌ಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ನಿರ್ದೇಶಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.
ದೃಷ್ಟಿಗೋಚರವಾಗಿ ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಇದು ನಿರ್ದಿಷ್ಟ ನಿದರ್ಶನದಿಂದ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಆಗಿದೆ. ಇಲ್ಲಿ ನಾವು ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಯ ಆಧಾರದ ಮೇಲೆ ಹಿಸ್ಟೋಗ್ರಾಮ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ ಮತ್ತು ಸಂಬಂಧಿತ ಸಾಲುಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತೇವೆ.
ಸೂಚ್ಯಂಕಗಳು
ಸಿಸ್ಟಮ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಹಿಂತಿರುಗಿ, ನಾವು ಸೂಚ್ಯಂಕ ಮಾದರಿಯನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಾಸಿಸಲು ನಾನು ಬಯಸುತ್ತೇನೆ ಇದರಿಂದ ಅದು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಮೇಲಿನ ರೇಖಾಚಿತ್ರದಲ್ಲಿ, ಇದು ಕಡಿಮೆ ಮಟ್ಟವಾಗಿದೆ: ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ ಡೇಟಾ ನೋಡ್ಗಳು.
ಇಂಡೆಕ್ಸ್ ಎಲಾಸ್ಟಿಕ್ ಸರ್ಚ್ ಚೂರುಗಳಿಂದ ಮಾಡಲ್ಪಟ್ಟ ದೊಡ್ಡ ವರ್ಚುವಲ್ ಘಟಕವಾಗಿದೆ. ಸ್ವತಃ, ಪ್ರತಿಯೊಂದು ಚೂರುಗಳು ಲುಸೀನ್ ಸೂಚ್ಯಂಕಕ್ಕಿಂತ ಹೆಚ್ಚೇನೂ ಅಲ್ಲ. ಮತ್ತು ಪ್ರತಿ ಲುಸೀನ್ ಸೂಚ್ಯಂಕವು ಪ್ರತಿಯಾಗಿ, ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ವಿಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.
ವಿನ್ಯಾಸ ಮಾಡುವಾಗ, ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾದಲ್ಲಿ ವೇಗವನ್ನು ಓದುವ ಅವಶ್ಯಕತೆಯನ್ನು ಪೂರೈಸಲು, ನಾವು ಈ ಡೇಟಾವನ್ನು ಡೇಟಾ ನೋಡ್‌ಗಳಾದ್ಯಂತ ಸಮವಾಗಿ "ಹರಡುವ" ಅಗತ್ಯವಿದೆ ಎಂದು ನಾವು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ.
ಪ್ರತಿ ಸೂಚ್ಯಂಕಕ್ಕೆ (ಪ್ರತಿಕೃತಿಗಳೊಂದಿಗೆ) ಚೂರುಗಳ ಸಂಖ್ಯೆಯು ಡೇಟಾ ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆಗೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸಮನಾಗಿರಬೇಕು ಎಂಬ ಅಂಶಕ್ಕೆ ಇದು ಕಾರಣವಾಯಿತು. ಮೊದಲನೆಯದಾಗಿ, ಎರಡಕ್ಕೆ ಸಮಾನವಾದ ಪುನರಾವರ್ತನೆಯ ಅಂಶವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು (ಅಂದರೆ, ನಾವು ಕ್ಲಸ್ಟರ್ನ ಅರ್ಧವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು). ಮತ್ತು, ಎರಡನೆಯದಾಗಿ, ಕ್ಲಸ್ಟರ್ನ ಕನಿಷ್ಠ ಅರ್ಧದಷ್ಟು ವಿನಂತಿಗಳನ್ನು ಓದಲು ಮತ್ತು ಬರೆಯಲು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು.
ನಾವು ಮೊದಲು 30 ದಿನಗಳ ಶೇಖರಣಾ ಸಮಯವನ್ನು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ಚೂರುಗಳ ವಿತರಣೆಯನ್ನು ಸಚಿತ್ರವಾಗಿ ಈ ಕೆಳಗಿನಂತೆ ಪ್ರತಿನಿಧಿಸಬಹುದು:
ಸಂಪೂರ್ಣ ಗಾಢ ಬೂದು ಆಯತವು ಸೂಚ್ಯಂಕವಾಗಿದೆ. ಅದರಲ್ಲಿ ಎಡ ಕೆಂಪು ಚೌಕವು ಪ್ರಾಥಮಿಕ ಚೂರು, ಸೂಚ್ಯಂಕದಲ್ಲಿ ಮೊದಲನೆಯದು. ಮತ್ತು ನೀಲಿ ಚೌಕವು ಪ್ರತಿಕೃತಿ ಚೂರು ಆಗಿದೆ. ಅವರು ವಿವಿಧ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ನೆಲೆಗೊಂಡಿದ್ದಾರೆ.
ನಾವು ಇನ್ನೊಂದು ಚೂರು ಸೇರಿಸಿದಾಗ, ಅದು ಮೂರನೇ ಡೇಟಾ ಕೇಂದ್ರಕ್ಕೆ ಹೋಗುತ್ತದೆ. ಮತ್ತು, ಕೊನೆಯಲ್ಲಿ, ನಾವು ಈ ರಚನೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಇದು ಡೇಟಾ ಸ್ಥಿರತೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ DC ಅನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ:
ಸೂಚ್ಯಂಕಗಳ ತಿರುಗುವಿಕೆ, ಅಂದರೆ. ಹೊಸ ಸೂಚ್ಯಂಕವನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಹಳೆಯದನ್ನು ಅಳಿಸುವುದು, ನಾವು ಅದನ್ನು 48 ಗಂಟೆಗಳವರೆಗೆ ಸಮನಾಗಿರುತ್ತದೆ (ಸೂಚ್ಯಂಕ ಬಳಕೆಯ ಮಾದರಿಯ ಪ್ರಕಾರ: ಕೊನೆಯ 48 ಗಂಟೆಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಹುಡುಕಲಾಗುತ್ತದೆ).
ಈ ಸೂಚ್ಯಂಕ ತಿರುಗುವಿಕೆಯ ಮಧ್ಯಂತರವು ಈ ಕೆಳಗಿನ ಕಾರಣಗಳಿಂದಾಗಿ:
ನಿರ್ದಿಷ್ಟ ಡೇಟಾ ನೋಡ್ಗೆ ಹುಡುಕಾಟ ವಿನಂತಿಯು ಬಂದಾಗ, ಕಾರ್ಯಕ್ಷಮತೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ, ಅದರ ಗಾತ್ರವು ನೋಡ್‌ನ ಹಿಪ್‌ನ ಗಾತ್ರಕ್ಕೆ ಹೋಲಿಸಬಹುದಾದರೆ, ಒಂದು ಚೂರುಗಳನ್ನು ಪ್ರಶ್ನಿಸಿದಾಗ ಅದು ಹೆಚ್ಚು ಲಾಭದಾಯಕವಾಗಿರುತ್ತದೆ. ಸೂಚ್ಯಂಕದ "ಬಿಸಿ" ಭಾಗವನ್ನು ರಾಶಿಯಲ್ಲಿ ಇರಿಸಲು ಮತ್ತು ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಪ್ರವೇಶಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಬಹಳಷ್ಟು "ಬಿಸಿ ಭಾಗಗಳು" ಇದ್ದಾಗ, ಸೂಚ್ಯಂಕ ಹುಡುಕಾಟದ ವೇಗವು ಕುಸಿಯುತ್ತದೆ.
ನೋಡ್ ಒಂದು ಶಾರ್ಡ್‌ನಲ್ಲಿ ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಅದು ಭೌತಿಕ ಯಂತ್ರದ ಹೈಪರ್‌ಥ್ರೆಡಿಂಗ್ ಕೋರ್‌ಗಳ ಸಂಖ್ಯೆಗೆ ಸಮಾನವಾದ ಹಲವಾರು ಥ್ರೆಡ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಒಂದು ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಯು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಚೂರುಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಿದರೆ, ನಂತರ ಎಳೆಗಳ ಸಂಖ್ಯೆಯು ಪ್ರಮಾಣಾನುಗುಣವಾಗಿ ಬೆಳೆಯುತ್ತದೆ. ಇದು ಹುಡುಕಾಟದ ವೇಗದ ಮೇಲೆ ನಕಾರಾತ್ಮಕ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಮತ್ತು ಹೊಸ ಡೇಟಾದ ಇಂಡೆಕ್ಸಿಂಗ್ ಮೇಲೆ ಋಣಾತ್ಮಕ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ಅಗತ್ಯ ಹುಡುಕಾಟ ಸುಪ್ತತೆಯನ್ನು ಒದಗಿಸಲು, ನಾವು SSD ಅನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ವಿನಂತಿಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು, ಈ ಕಂಟೈನರ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡಿದ ಯಂತ್ರಗಳು ಕನಿಷ್ಠ 56 ಕೋರ್‌ಗಳನ್ನು ಹೊಂದಿರಬೇಕು. ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟವು ಉತ್ಪಾದಿಸುವ ಥ್ರೆಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ಧರಿಸುವ ಷರತ್ತುಬದ್ಧವಾಗಿ ಸಾಕಷ್ಟು ಮೌಲ್ಯವಾಗಿ 56 ರ ಅಂಕಿ ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ. Elasitcsearch ನಲ್ಲಿ, ಅನೇಕ ಥ್ರೆಡ್ ಪೂಲ್ ನಿಯತಾಂಕಗಳು ಲಭ್ಯವಿರುವ ಕೋರ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ನೇರವಾಗಿ ಅವಲಂಬಿಸಿರುತ್ತದೆ, ಇದು "ಕಡಿಮೆ ಕೋರ್‌ಗಳು - ಹೆಚ್ಚು ನೋಡ್ಗಳು" ತತ್ವದ ಪ್ರಕಾರ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಅಗತ್ಯವಿರುವ ಸಂಖ್ಯೆಯ ನೋಡ್ಗಳನ್ನು ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ಪರಿಣಾಮವಾಗಿ, ಒಂದು ಚೂರು ಸರಾಸರಿ 20 ಗಿಗಾಬೈಟ್‌ಗಳ ತೂಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಸೂಚ್ಯಂಕಕ್ಕೆ 1 ಚೂರುಗಳಿವೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಅದರಂತೆ, ನಾವು ಪ್ರತಿ 360 ಗಂಟೆಗಳಿಗೊಮ್ಮೆ ಅವುಗಳನ್ನು ತಿರುಗಿಸಿದರೆ, ನಾವು ಅವುಗಳಲ್ಲಿ 48 ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಪ್ರತಿಯೊಂದು ಸೂಚ್ಯಂಕವು 15 ದಿನಗಳವರೆಗೆ ಡೇಟಾವನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಡೇಟಾ ಬರವಣಿಗೆ ಮತ್ತು ಓದುವ ಸರ್ಕ್ಯೂಟ್‌ಗಳು
ಈ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಹೇಗೆ ದಾಖಲಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ.
ಗ್ರೇಲಾಗ್‌ನಿಂದ ಸಂಯೋಜಕರಿಗೆ ಕೆಲವು ವಿನಂತಿಗಳು ಬರುತ್ತವೆ ಎಂದು ಹೇಳೋಣ. ಉದಾಹರಣೆಗೆ, ನಾವು ಸೂಚ್ಯಂಕ 2-3 ಸಾವಿರ ಸಾಲುಗಳನ್ನು ಬಯಸುತ್ತೇವೆ.
ಸಂಯೋಜಕರು, ಗ್ರೇಲಾಗ್‌ನಿಂದ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಮಾಸ್ಟರ್ ಅನ್ನು ಪ್ರಶ್ನಿಸುತ್ತಾರೆ: "ಇಂಡೆಕ್ಸಿಂಗ್ ವಿನಂತಿಯಲ್ಲಿ, ನಾವು ನಿರ್ದಿಷ್ಟವಾಗಿ ಸೂಚ್ಯಂಕವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ್ದೇವೆ, ಆದರೆ ಅದನ್ನು ಯಾವ ಚೂರುಗಳಲ್ಲಿ ಬರೆಯಬೇಕೆಂದು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿಲ್ಲ."
ಮಾಸ್ಟರ್ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾರೆ: "ಈ ಮಾಹಿತಿಯನ್ನು ಶಾರ್ಡ್ ಸಂಖ್ಯೆ 71 ಗೆ ಬರೆಯಿರಿ," ನಂತರ ಅದನ್ನು ನೇರವಾಗಿ ಸಂಬಂಧಿತ ಡೇಟಾ ನೋಡ್ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಪ್ರಾಥಮಿಕ-ಶಾರ್ಡ್ ಸಂಖ್ಯೆ 71 ಇದೆ.
ಅದರ ನಂತರ ವಹಿವಾಟು ಲಾಗ್ ಅನ್ನು ಪ್ರತಿಕೃತಿ-ಶಾರ್ಡ್‌ಗೆ ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ, ಅದು ಮತ್ತೊಂದು ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿದೆ.
ಗ್ರೇಲಾಗ್‌ನಿಂದ ಸಂಯೋಜಕರಿಗೆ ಹುಡುಕಾಟ ವಿನಂತಿಯು ಬರುತ್ತದೆ. ಸಂಯೋಜಕರು ಅದನ್ನು ಸೂಚ್ಯಂಕದ ಪ್ರಕಾರ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ, ಆದರೆ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟವು ರೌಂಡ್-ರಾಬಿನ್ ತತ್ವವನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರಾಥಮಿಕ-ಶಾರ್ಡ್ ಮತ್ತು ಪ್ರತಿಕೃತಿ-ಶಾರ್ಡ್ ನಡುವೆ ವಿನಂತಿಗಳನ್ನು ವಿತರಿಸುತ್ತದೆ.
180 ನೋಡ್ಗಳು ಅಸಮಾನವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತವೆ ಮತ್ತು ಅವರು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿರುವಾಗ, ಸಂಯೋಜಕರು ಈಗಾಗಲೇ ವೇಗವಾದ ಡೇಟಾ ನೋಡ್‌ಗಳಿಂದ "ಉಗುಳಲ್ಪಟ್ಟ" ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಿದ್ದಾರೆ. ಇದರ ನಂತರ, ಎಲ್ಲಾ ಮಾಹಿತಿಯು ಬಂದಾಗ, ಅಥವಾ ವಿನಂತಿಯು ಸಮಯ ಮೀರಿದಾಗ, ಅದು ನೇರವಾಗಿ ಕ್ಲೈಂಟ್‌ಗೆ ಎಲ್ಲವನ್ನೂ ನೀಡುತ್ತದೆ.
ಈ ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯು ಕಳೆದ 48 ಗಂಟೆಗಳಲ್ಲಿ 300-400ms ನಲ್ಲಿ ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಪ್ರಮುಖ ವೈಲ್ಡ್‌ಕಾರ್ಡ್‌ನೊಂದಿಗೆ ಆ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊರತುಪಡಿಸಿ.
ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದೊಂದಿಗೆ ಹೂವುಗಳು: ಜಾವಾ ಸೆಟಪ್
ಎಲ್ಲವನ್ನೂ ನಾವು ಮೂಲತಃ ಬಯಸಿದ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು, ನಾವು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ವಿವಿಧ ರೀತಿಯ ವಿಷಯಗಳನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಬಹಳ ಸಮಯ ಕಳೆದಿದ್ದೇವೆ.
ಪತ್ತೆಯಾದ ಸಮಸ್ಯೆಗಳ ಮೊದಲ ಭಾಗವು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಜಾವಾವನ್ನು ಪೂರ್ವ ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ವಿಧಾನಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ.
ಸಮಸ್ಯೆ ಒಂದು
ಲುಸೀನ್ ಮಟ್ಟದಲ್ಲಿ, ಹಿನ್ನೆಲೆ ಕೆಲಸಗಳು ಚಾಲನೆಯಲ್ಲಿರುವಾಗ, ಲುಸೀನ್ ವಿಭಾಗವು ದೋಷದೊಂದಿಗೆ ವಿಲೀನಗೊಳ್ಳುವುದನ್ನು ನಾವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವರದಿಗಳನ್ನು ನೋಡಿದ್ದೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು OutOfMemoryError ದೋಷ ಎಂದು ಲಾಗ್‌ಗಳಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿತ್ತು. ಹಿಪ್ ಮುಕ್ತವಾಗಿದೆ ಎಂದು ನಾವು ಟೆಲಿಮೆಟ್ರಿಯಿಂದ ನೋಡಿದ್ದೇವೆ ಮತ್ತು ಈ ಕಾರ್ಯಾಚರಣೆಯು ಏಕೆ ವಿಫಲವಾಗಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.
ಲುಸೀನ್ ಸೂಚ್ಯಂಕ ವಿಲೀನಗಳು ಸೊಂಟದ ಹೊರಗೆ ಸಂಭವಿಸುತ್ತವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಮತ್ತು ಸೇವಿಸುವ ಸಂಪನ್ಮೂಲಗಳ ವಿಷಯದಲ್ಲಿ ಧಾರಕಗಳು ಸಾಕಷ್ಟು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸೀಮಿತವಾಗಿವೆ. ಈ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಹೀಪ್ ಮಾತ್ರ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ (heap.size ಮೌಲ್ಯವು RAM ಗೆ ಸರಿಸುಮಾರು ಸಮಾನವಾಗಿತ್ತು), ಮತ್ತು ಕೆಲವು ಆಫ್-ಹೀಪ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಕೆಲವು ಕಾರಣಗಳಿಂದಾಗಿ ಮಿತಿಗಿಂತ ಮೊದಲು ಉಳಿದಿರುವ ~500MB ಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ ಮೆಮೊರಿ ಹಂಚಿಕೆ ದೋಷದೊಂದಿಗೆ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತವೆ.
ಪರಿಹಾರವು ತುಂಬಾ ಕ್ಷುಲ್ಲಕವಾಗಿತ್ತು: ಕಂಟೇನರ್‌ಗೆ ಲಭ್ಯವಿರುವ RAM ನ ಪ್ರಮಾಣವನ್ನು ಹೆಚ್ಚಿಸಲಾಯಿತು, ಅದರ ನಂತರ ನಾವು ಅಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾವು ಮರೆತಿದ್ದೇವೆ.
ಸಮಸ್ಯೆ ಎರಡು
ಕ್ಲಸ್ಟರ್ ಪ್ರಾರಂಭವಾದ 4-5 ದಿನಗಳ ನಂತರ, ಡೇಟಾ ನೋಡ್ಗಳು ನಿಯತಕಾಲಿಕವಾಗಿ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಹೊರಬರಲು ಪ್ರಾರಂಭಿಸಿದವು ಮತ್ತು 10-20 ಸೆಕೆಂಡುಗಳ ನಂತರ ಅದನ್ನು ನಮೂದಿಸುವುದನ್ನು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ.
ನಾವು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದಲ್ಲಿನ ಈ ಆಫ್-ಹೀಪ್ ಮೆಮೊರಿಯನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ನಿಯಂತ್ರಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು. ನಾವು ಕಂಟೇನರ್‌ಗೆ ಹೆಚ್ಚಿನ ಮೆಮೊರಿಯನ್ನು ನೀಡಿದಾಗ, ನಾವು ನೇರ ಬಫರ್ ಪೂಲ್‌ಗಳನ್ನು ವಿವಿಧ ಮಾಹಿತಿಯೊಂದಿಗೆ ತುಂಬಲು ಸಾಧ್ಯವಾಯಿತು ಮತ್ತು ಎಲಾಸ್ಟಿಕ್‌ಸರ್ಚ್‌ನಿಂದ ಸ್ಪಷ್ಟವಾದ GC ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ನಂತರವೇ ಅದನ್ನು ತೆರವುಗೊಳಿಸಲಾಗಿದೆ.
ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಈ ಕಾರ್ಯಾಚರಣೆಯು ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು, ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಈ ನೋಡ್ ಅನ್ನು ಈಗಾಗಲೇ ನಿರ್ಗಮಿಸಿದೆ ಎಂದು ಗುರುತಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಚೆನ್ನಾಗಿ ವಿವರಿಸಲಾಗಿದೆ .
ಪರಿಹಾರವು ಕೆಳಕಂಡಂತಿತ್ತು: ಈ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ ರಾಶಿಯ ಹೊರಗೆ ಮೆಮೊರಿಯ ಬಹುಭಾಗವನ್ನು ಬಳಸುವ ಜಾವಾದ ಸಾಮರ್ಥ್ಯವನ್ನು ನಾವು ಸೀಮಿತಗೊಳಿಸಿದ್ದೇವೆ. ನಾವು ಅದನ್ನು 16 ಗಿಗಾಬೈಟ್‌ಗಳಿಗೆ (-XX:MaxDirectMemorySize=16g) ಸೀಮಿತಗೊಳಿಸಿದ್ದೇವೆ, ಸ್ಪಷ್ಟವಾದ GC ಅನ್ನು ಹೆಚ್ಚು ಬಾರಿ ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ, ಇದರಿಂದಾಗಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಇನ್ನು ಮುಂದೆ ಅಸ್ಥಿರಗೊಳಿಸುವುದಿಲ್ಲ.
ಸಮಸ್ಯೆ ಮೂರು
"ಅತ್ಯಂತ ಅನಿರೀಕ್ಷಿತ ಕ್ಷಣದಲ್ಲಿ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಹೊರಡುವ ನೋಡ್‌ಗಳ" ಸಮಸ್ಯೆಗಳು ಮುಗಿದಿವೆ ಎಂದು ನೀವು ಭಾವಿಸಿದರೆ, ನೀವು ತಪ್ಪಾಗಿ ಭಾವಿಸುತ್ತೀರಿ.
ನಾವು ಸೂಚಿಕೆಗಳೊಂದಿಗೆ ಕೆಲಸವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದಾಗ, ನಾವು mmapfs ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ ಉತ್ತಮ ವಿಭಜನೆಯೊಂದಿಗೆ ತಾಜಾ ಚೂರುಗಳ ಮೇಲೆ. ಇದು ಸಾಕಷ್ಟು ಪ್ರಮಾದವಾಗಿತ್ತು, ಏಕೆಂದರೆ ಎಂಎಂಎಪಿಎಫ್‌ಗಳನ್ನು ಬಳಸುವಾಗ ಫೈಲ್ ಅನ್ನು RAM ಗೆ ಮ್ಯಾಪ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ನಾವು ಮ್ಯಾಪ್ ಮಾಡಿದ ಫೈಲ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ. ಈ ಕಾರಣದಿಂದಾಗಿ, ಜಿಸಿ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಥ್ರೆಡ್‌ಗಳನ್ನು ನಿಲ್ಲಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ನಾವು ಬಹಳ ಸಮಯದವರೆಗೆ ಸೇಫ್‌ಪಾಯಿಂಟ್‌ಗೆ ಹೋಗುತ್ತೇವೆ ಮತ್ತು ಅದರ ದಾರಿಯಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್ ಜೀವಂತವಾಗಿದೆಯೇ ಎಂಬ ಬಗ್ಗೆ ಮಾಸ್ಟರ್ನ ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. . ಅಂತೆಯೇ, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೋಡ್ ಇನ್ನು ಮುಂದೆ ಇರುವುದಿಲ್ಲ ಎಂದು ಮಾಸ್ಟರ್ ನಂಬುತ್ತಾರೆ. ಇದರ ನಂತರ, 5-10 ಸೆಕೆಂಡುಗಳ ನಂತರ, ಕಸ ಸಂಗ್ರಾಹಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ನೋಡ್ ಜೀವಕ್ಕೆ ಬರುತ್ತದೆ, ಮತ್ತೆ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ ಮತ್ತು ಚೂರುಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಇದೆಲ್ಲವೂ "ನಾವು ಅರ್ಹವಾದ ಉತ್ಪಾದನೆ" ಎಂದು ಭಾವಿಸಿದೆ ಮತ್ತು ಗಂಭೀರವಾದ ಯಾವುದಕ್ಕೂ ಸೂಕ್ತವಲ್ಲ.
ಈ ನಡವಳಿಕೆಯನ್ನು ತೊಡೆದುಹಾಕಲು, ನಾವು ಮೊದಲು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ನಿಯೋಫ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ ಮತ್ತು ನಂತರ, ನಾವು ಎಲಾಸ್ಟಿಕ್‌ನ ಐದನೇ ಆವೃತ್ತಿಯಿಂದ ಆರನೇ ಆವೃತ್ತಿಗೆ ವಲಸೆ ಹೋದಾಗ, ನಾವು ಹೈಬ್ರಿಡ್ಫ್‌ಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ, ಅಲ್ಲಿ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪುನರುತ್ಪಾದಿಸಲಾಗಿಲ್ಲ. ಶೇಖರಣಾ ಪ್ರಕಾರಗಳ ಬಗ್ಗೆ ನೀವು ಇನ್ನಷ್ಟು ಓದಬಹುದು .
ಸಮಸ್ಯೆ ನಾಲ್ಕು
ನಂತರ ನಾವು ದಾಖಲೆ ಸಮಯಕ್ಕೆ ಚಿಕಿತ್ಸೆ ನೀಡಿದ ಮತ್ತೊಂದು ಕುತೂಹಲಕಾರಿ ಸಮಸ್ಯೆ ಇತ್ತು. ನಾವು ಅದನ್ನು 2-3 ತಿಂಗಳ ಕಾಲ ಹಿಡಿದಿದ್ದೇವೆ ಏಕೆಂದರೆ ಅದರ ಮಾದರಿಯು ಸಂಪೂರ್ಣವಾಗಿ ಅಗ್ರಾಹ್ಯವಾಗಿದೆ.
ಕೆಲವೊಮ್ಮೆ ನಮ್ಮ ಸಂಯೋಜಕರು ಪೂರ್ಣ GC ಗೆ ಹೋಗುತ್ತಾರೆ, ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವೊಮ್ಮೆ ಊಟದ ನಂತರ, ಮತ್ತು ಅಲ್ಲಿಂದ ಹಿಂತಿರುಗಲಿಲ್ಲ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಜಿಸಿ ವಿಳಂಬವನ್ನು ಲಾಗ್ ಮಾಡುವಾಗ, ಅದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿ ನಡೆಯುತ್ತಿದೆ, ಚೆನ್ನಾಗಿ, ಚೆನ್ನಾಗಿ, ಮತ್ತು ನಂತರ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಎಲ್ಲವೂ ತುಂಬಾ ಕೆಟ್ಟದಾಗಿ ಹೋಗುತ್ತಿದೆ.
ಮೊದಲಿಗೆ ನಾವು ದುಷ್ಟ ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಭಾವಿಸಿದ್ದೇವೆ, ಅವರು ಕೆಲವು ರೀತಿಯ ವಿನಂತಿಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದಾರೆ ಅದು ಸಂಯೋಜಕರನ್ನು ವರ್ಕಿಂಗ್ ಮೋಡ್‌ನಿಂದ ಹೊರಹಾಕುತ್ತದೆ. ನಾವು ಬಹಳ ಸಮಯದವರೆಗೆ ವಿನಂತಿಗಳನ್ನು ಲಾಗ್ ಮಾಡಿದ್ದೇವೆ, ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ.
ಪರಿಣಾಮವಾಗಿ, ಬಳಕೆದಾರರು ದೊಡ್ಡ ವಿನಂತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ಮತ್ತು ಅದು ನಿರ್ದಿಷ್ಟ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ ಸಂಯೋಜಕರಿಗೆ ಬಂದಾಗ, ಕೆಲವು ನೋಡ್ಗಳು ಇತರರಿಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು.
ಮತ್ತು ಸಂಯೋಜಕರು ಎಲ್ಲಾ ನೋಡ್‌ಗಳಿಂದ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯುತ್ತಿರುವಾಗ, ಅವರು ಈಗಾಗಲೇ ಪ್ರತಿಕ್ರಿಯಿಸಿದ ನೋಡ್‌ಗಳಿಂದ ಕಳುಹಿಸಿದ ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ. GC ಗಾಗಿ, ನಮ್ಮ ರಾಶಿ ಬಳಕೆಯ ಮಾದರಿಗಳು ಬಹಳ ಬೇಗನೆ ಬದಲಾಗುತ್ತವೆ ಎಂದರ್ಥ. ಮತ್ತು ನಾವು ಬಳಸಿದ GC ಈ ಕಾರ್ಯವನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.
ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಕ್ಲಸ್ಟರ್ನ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸಲು ನಾವು ಕಂಡುಕೊಂಡ ಏಕೈಕ ಪರಿಹಾರವೆಂದರೆ JDK13 ಗೆ ವಲಸೆ ಮತ್ತು Shenandoah ಕಸ ಸಂಗ್ರಾಹಕವನ್ನು ಬಳಸುವುದು. ಇದು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿತು, ನಮ್ಮ ಸಂಯೋಜಕರು ಬೀಳುವುದನ್ನು ನಿಲ್ಲಿಸಿದರು.
ಇಲ್ಲಿಯೇ ಜಾವಾದ ಸಮಸ್ಯೆಗಳು ಕೊನೆಗೊಂಡವು ಮತ್ತು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಸಮಸ್ಯೆಗಳು ಪ್ರಾರಂಭವಾದವು.
ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದೊಂದಿಗೆ "ಬೆರ್ರಿಗಳು": ಥ್ರೋಪುಟ್
ಥ್ರೋಪುಟ್‌ನೊಂದಿಗಿನ ತೊಂದರೆಗಳು ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಸ್ಥಿರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದರ್ಥ, ಆದರೆ ಸೂಚ್ಯಂಕ ದಾಖಲೆಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಗರಿಷ್ಠ ಮಟ್ಟದಲ್ಲಿ ಮತ್ತು ಕುಶಲತೆಯ ಸಮಯದಲ್ಲಿ, ಕಾರ್ಯಕ್ಷಮತೆ ಸಾಕಷ್ಟಿಲ್ಲ.
ಮೊದಲ ರೋಗಲಕ್ಷಣವು ಎದುರಾಗಿದೆ: ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೆಲವು "ಸ್ಫೋಟಗಳ" ಸಮಯದಲ್ಲಿ, ಬಹಳ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಲಾಗ್‌ಗಳು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಉತ್ಪತ್ತಿಯಾದಾಗ, ಇಂಡೆಕ್ಸಿಂಗ್ ದೋಷ es_rejected_execution ಗ್ರೇಲಾಗ್‌ನಲ್ಲಿ ಆಗಾಗ್ಗೆ ಫ್ಲ್ಯಾಷ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
ಒಂದು ಡೇಟಾ ನೋಡ್‌ನಲ್ಲಿ thread_pool.write.queue ಎಂಬ ಅಂಶದಿಂದಾಗಿ, Elasticsearch ಇಂಡೆಕ್ಸಿಂಗ್ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಮತ್ತು ಮಾಹಿತಿಯನ್ನು ಡಿಸ್ಕ್‌ನಲ್ಲಿನ ಶಾರ್ಡ್‌ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವವರೆಗೆ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಕೇವಲ 200 ವಿನಂತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಮತ್ತು ಒಳಗೆ ಈ ನಿಯತಾಂಕದ ಬಗ್ಗೆ ಬಹಳ ಕಡಿಮೆ ಹೇಳಲಾಗಿದೆ. ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಥ್ರೆಡ್‌ಗಳು ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಗಾತ್ರವನ್ನು ಮಾತ್ರ ಸೂಚಿಸಲಾಗುತ್ತದೆ.
ಸಹಜವಾಗಿ, ನಾವು ಈ ಮೌಲ್ಯವನ್ನು ಟ್ವಿಸ್ಟ್ ಮಾಡಲು ಹೋದೆವು ಮತ್ತು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ: ನಿರ್ದಿಷ್ಟವಾಗಿ, ನಮ್ಮ ಸೆಟಪ್‌ನಲ್ಲಿ, 300 ವಿನಂತಿಗಳನ್ನು ಚೆನ್ನಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಮತ್ತು ನಾವು ಮತ್ತೆ ಪೂರ್ಣ GC ಗೆ ಹಾರುತ್ತೇವೆ ಎಂಬ ಅಂಶದಿಂದ ಹೆಚ್ಚಿನ ಮೌಲ್ಯವು ತುಂಬಿದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಇವುಗಳು ಒಂದು ವಿನಂತಿಯೊಳಗೆ ಬರುವ ಸಂದೇಶಗಳ ಬ್ಯಾಚ್‌ಗಳಾಗಿರುವುದರಿಂದ, ಗ್ರೇಲಾಗ್ ಅನ್ನು ಟ್ವೀಕ್ ಮಾಡುವುದು ಅಗತ್ಯವಾಗಿದೆ, ಇದರಿಂದಾಗಿ ಅದು ಆಗಾಗ್ಗೆ ಮತ್ತು ಸಣ್ಣ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಬರೆಯುವುದಿಲ್ಲ, ಆದರೆ ದೊಡ್ಡ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಅಥವಾ ಬ್ಯಾಚ್ ಇನ್ನೂ ಪೂರ್ಣವಾಗಿಲ್ಲದಿದ್ದರೆ ಪ್ರತಿ 3 ಸೆಕೆಂಡುಗಳಿಗೊಮ್ಮೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದಲ್ಲಿ ನಾವು ಬರೆಯುವ ಮಾಹಿತಿಯು ಎರಡು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಲಭ್ಯವಿರುವುದಿಲ್ಲ, ಆದರೆ ಐದು (ಇದು ನಮಗೆ ಸರಿಹೊಂದುತ್ತದೆ), ಆದರೆ ದೊಡ್ಡದಾದ ಮೂಲಕ ತಳ್ಳಲು ಮಾಡಬೇಕಾದ ರಿಟ್ರೇಗಳ ಸಂಖ್ಯೆ. ಮಾಹಿತಿಯ ಸ್ಟಾಕ್ ಕಡಿಮೆಯಾಗಿದೆ.
ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪ್ಯಾಮ್ ಮಾಡಲಾದ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ಪಡೆಯದಿರಲು ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ - ಮುಚ್ಚಿಹೋಗಿರುವ ಬಫರ್‌ಗಳಿಂದಾಗಿ ನಿಷ್ಕ್ರಿಯವಾಗಿರುವ ಗ್ರೇಲಾಗ್ ನೋಡ್ಗಳು ಎಲ್ಲೋ ಕ್ರ್ಯಾಶ್ ಆಗಿರುವಾಗ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ತೀವ್ರವಾಗಿ ವರದಿ ಮಾಡಿದಾಗ ಆ ಕ್ಷಣಗಳಲ್ಲಿ ಇದು ಮುಖ್ಯವಾಗಿದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಇದೇ ಸ್ಫೋಟಗಳನ್ನು ಹೊಂದಿದ್ದಾಗ, ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಮತ್ತು ಪರೀಕ್ಷಕರಿಂದ ನಾವು ದೂರುಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ: ಅವರಿಗೆ ನಿಜವಾಗಿಯೂ ಈ ಲಾಗ್‌ಗಳು ಅಗತ್ಯವಿರುವ ಕ್ಷಣದಲ್ಲಿ, ಅವುಗಳನ್ನು ಬಹಳ ನಿಧಾನವಾಗಿ ನೀಡಲಾಯಿತು.
ಅವರು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು. ಒಂದೆಡೆ, ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಇಂಡೆಕ್ಸಿಂಗ್ ಪ್ರಶ್ನೆಗಳು ಎರಡನ್ನೂ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ, ಮೂಲಭೂತವಾಗಿ, ಒಂದೇ ಭೌತಿಕ ಯಂತ್ರಗಳಲ್ಲಿ, ಮತ್ತು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ಕೆಲವು ಡ್ರಾಡೌನ್‌ಗಳು ಇರುತ್ತವೆ.
ಆದರೆ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದ ಆರನೇ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಯಾದೃಚ್ಛಿಕ ರೌಂಡ್-ರಾಬಿನ್ ತತ್ವಕ್ಕೆ ಅನುಗುಣವಾಗಿಲ್ಲದ ಸಂಬಂಧಿತ ಡೇಟಾ ನೋಡ್‌ಗಳ ನಡುವೆ ಪ್ರಶ್ನೆಗಳನ್ನು ವಿತರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಅಲ್ಗಾರಿದಮ್ ಕಾಣಿಸಿಕೊಂಡಿದೆ ಎಂಬ ಅಂಶದಿಂದಾಗಿ ಇದನ್ನು ಭಾಗಶಃ ತಪ್ಪಿಸಬಹುದು (ಇಂಡೆಕ್ಸಿಂಗ್ ಮಾಡುವ ಮತ್ತು ಪ್ರಾಥಮಿಕ- ಹೊಂದಿರುವ ಕಂಟೇನರ್. ಚೂರು ತುಂಬಾ ಕಾರ್ಯನಿರತವಾಗಿರಬಹುದು, ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ), ಆದರೆ ಈ ವಿನಂತಿಯನ್ನು ಪ್ರತಿಕೃತಿ-ಶಾರ್ಡ್ ಹೊಂದಿರುವ ಕಡಿಮೆ ಲೋಡ್ ಕಂಟೇನರ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು, ಅದು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನಾವು use_adaptive_replica_selection ಗೆ ಬಂದಿದ್ದೇವೆ: ನಿಜ.
ಓದುವ ಚಿತ್ರವು ಈ ರೀತಿ ಕಾಣಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ:
ಈ ಅಲ್ಗಾರಿದಮ್‌ಗೆ ಪರಿವರ್ತನೆಯು ನಾವು ಬರೆಯಲು ಲಾಗ್‌ಗಳ ದೊಡ್ಡ ಹರಿವನ್ನು ಹೊಂದಿರುವಾಗ ಆ ಕ್ಷಣಗಳಲ್ಲಿ ಪ್ರಶ್ನೆ ಸಮಯವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸುಧಾರಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು.
ಅಂತಿಮವಾಗಿ, ಡೇಟಾ ಸೆಂಟರ್ನ ನೋವುರಹಿತ ತೆಗೆದುಹಾಕುವಿಕೆಯು ಮುಖ್ಯ ಸಮಸ್ಯೆಯಾಗಿದೆ.
ಒಂದು DC ಯೊಂದಿಗಿನ ಸಂಪರ್ಕವನ್ನು ಕಳೆದುಕೊಂಡ ತಕ್ಷಣ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ನಮಗೆ ಬೇಕಾಗಿರುವುದು:
- ವಿಫಲವಾದ ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ನಾವು ಪ್ರಸ್ತುತ ಮಾಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದನ್ನು ಮರು-ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು DC ಯಲ್ಲಿ ಮತ್ತೊಂದು ನೋಡ್ಗೆ ಪಾತ್ರವಾಗಿ ಸರಿಸಲಾಗುತ್ತದೆ.
- ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಪ್ರವೇಶಿಸಲಾಗದ ಎಲ್ಲಾ ನೋಡ್ಗಳನ್ನು ಮಾಸ್ಟರ್ ತ್ವರಿತವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತಾರೆ.
- ಉಳಿದವುಗಳನ್ನು ಆಧರಿಸಿ, ಅವರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ: ಕಳೆದುಹೋದ ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ನಾವು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಪ್ರಾಥಮಿಕ ಚೂರುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅವರು ಉಳಿದ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಪೂರಕ ಪ್ರತಿಕೃತಿ ಚೂರುಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪ್ರಚಾರ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ನಾವು ಡೇಟಾವನ್ನು ಇಂಡೆಕ್ಸ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ.
- ಇದರ ಪರಿಣಾಮವಾಗಿ, ಕ್ಲಸ್ಟರ್ನ ಬರವಣಿಗೆ ಮತ್ತು ಓದುವ ಥ್ರೋಪುಟ್ ಕ್ರಮೇಣ ಕ್ಷೀಣಿಸುತ್ತದೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲವೂ ನಿಧಾನವಾಗಿ, ಆದರೆ ಸ್ಥಿರವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಅದು ಬದಲಾದಂತೆ, ನಾವು ಈ ರೀತಿಯದನ್ನು ಬಯಸಿದ್ದೇವೆ:
ಮತ್ತು ನಾವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ:
ಇದು ಹೇಗಾಯಿತು?
ಡೇಟಾ ಸೆಂಟರ್ ಬಿದ್ದಾಗ, ನಮ್ಮ ಯಜಮಾನರು ಅಡ್ಡಿಯಾದರು.
ಯಾಕೆ?
ಸತ್ಯವೆಂದರೆ ಮಾಸ್ಟರ್ ಟಾಸ್ಕ್ ಬ್ಯಾಚರ್ ಅನ್ನು ಹೊಂದಿದ್ದು, ಇದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕೆಲವು ಕಾರ್ಯಗಳು ಮತ್ತು ಈವೆಂಟ್‌ಗಳನ್ನು ವಿತರಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದೆ. ಯಾವುದೇ ನೋಡ್ ನಿರ್ಗಮನ, ಪ್ರತಿಕೃತಿಯಿಂದ ಪ್ರಾಥಮಿಕಕ್ಕೆ ಶಾರ್ಡ್‌ನ ಯಾವುದೇ ಪ್ರಚಾರ, ಎಲ್ಲೋ ಚೂರುಗಳನ್ನು ರಚಿಸಲು ಯಾವುದೇ ಕಾರ್ಯ - ಇವೆಲ್ಲವೂ ಮೊದಲು ಟಾಸ್ಕ್‌ಬ್ಯಾಚರ್‌ಗೆ ಹೋಗುತ್ತದೆ, ಅಲ್ಲಿ ಅದನ್ನು ಅನುಕ್ರಮವಾಗಿ ಮತ್ತು ಒಂದು ಥ್ರೆಡ್‌ನಲ್ಲಿ ಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ.
ಒಂದು ಡೇಟಾ ಕೇಂದ್ರವನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯದಲ್ಲಿ, ಉಳಿದಿರುವ ದತ್ತಾಂಶ ಕೇಂದ್ರಗಳಲ್ಲಿನ ಎಲ್ಲಾ ಡೇಟಾ ನೋಡ್ಗಳು "ನಾವು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಚೂರುಗಳು ಮತ್ತು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಡೇಟಾ ನೋಡ್ಗಳನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ" ಎಂದು ಮಾಸ್ಟರ್‌ಗೆ ತಿಳಿಸುವುದು ತಮ್ಮ ಕರ್ತವ್ಯವೆಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಉಳಿದಿರುವ ಡೇಟಾ ನೋಡ್ಗಳು ಈ ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ಪ್ರಸ್ತುತ ಮಾಸ್ಟರ್‌ಗೆ ಕಳುಹಿಸಿದವು ಮತ್ತು ಅವರು ಅದನ್ನು ಒಪ್ಪಿಕೊಂಡಿದ್ದಾರೆ ಎಂದು ದೃಢೀಕರಣಕ್ಕಾಗಿ ಕಾಯಲು ಪ್ರಯತ್ನಿಸಿದರು. ಅವರು ಇದಕ್ಕಾಗಿ ಕಾಯಲಿಲ್ಲ, ಏಕೆಂದರೆ ಮಾಸ್ಟರ್ ಅವರು ಉತ್ತರಿಸುವುದಕ್ಕಿಂತ ವೇಗವಾಗಿ ಕಾರ್ಯಗಳನ್ನು ಸ್ವೀಕರಿಸಿದರು. ನೋಡ್ಗಳು ಪುನರಾವರ್ತಿತ ವಿನಂತಿಗಳನ್ನು ಮೀರಿದೆ, ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ಮಾಸ್ಟರ್ ಅವರಿಗೆ ಉತ್ತರಿಸಲು ಸಹ ಪ್ರಯತ್ನಿಸಲಿಲ್ಲ, ಆದರೆ ಆದ್ಯತೆಯ ಮೂಲಕ ವಿನಂತಿಗಳನ್ನು ವಿಂಗಡಿಸುವ ಕಾರ್ಯದಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಹೀರಿಕೊಳ್ಳಲ್ಪಟ್ಟರು.
ಟರ್ಮಿನಲ್ ರೂಪದಲ್ಲಿ, ಡೇಟಾ ನೋಡ್ಗಳು ಮಾಸ್ಟರ್ ಅನ್ನು ಸ್ಪ್ಯಾಮ್ ಮಾಡಿದ್ದು ಅದು ಪೂರ್ಣ ಜಿಸಿಗೆ ಹೋಗಿದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಅದರ ನಂತರ, ನಮ್ಮ ಮಾಸ್ಟರ್ ಪಾತ್ರವು ಕೆಲವು ಮುಂದಿನ ನೋಡ್ಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿತು, ಸಂಪೂರ್ಣವಾಗಿ ಅದೇ ವಿಷಯ ಸಂಭವಿಸಿತು ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ ಕ್ಲಸ್ಟರ್ ಸಂಪೂರ್ಣವಾಗಿ ಕುಸಿಯಿತು.
ನಾವು ಅಳತೆಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಆವೃತ್ತಿ 6.4.0 ಗಿಂತ ಮೊದಲು, ಇದನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ, ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮುಚ್ಚಲು 10 ರಲ್ಲಿ 360 ಡೇಟಾ ನೋಡ್ಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಔಟ್‌ಪುಟ್ ಮಾಡಲು ನಮಗೆ ಸಾಕಾಗಿತ್ತು.
ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಆವೃತ್ತಿ 6.4.0 ರ ನಂತರ, ಈ ಭಯಾನಕ ದೋಷವನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ, ಡೇಟಾ ನೋಡ್ಗಳು ಮಾಸ್ಟರ್ ಅನ್ನು ಕೊಲ್ಲುವುದನ್ನು ನಿಲ್ಲಿಸಿದವು. ಆದರೆ ಅದು ಅವನನ್ನು "ಬುದ್ಧಿವಂತ" ಮಾಡಲಿಲ್ಲ. ಅವುಗಳೆಂದರೆ: ನಾವು 2, 3 ಅಥವಾ 10 (ಒಂದನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ ಸಂಖ್ಯೆ) ಡೇಟಾ ನೋಡ್ಗಳನ್ನು ಔಟ್‌ಪುಟ್ ಮಾಡಿದಾಗ, ನೋಡ್ A ಬಿಟ್ಟಿದೆ ಎಂದು ಹೇಳುವ ಕೆಲವು ಮೊದಲ ಸಂದೇಶವನ್ನು ಮಾಸ್ಟರ್ ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ನೋಡ್ ಬಿ, ನೋಡ್ ಸಿ, ನೋಡ್ ಡಿ ಬಗ್ಗೆ ಹೇಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ.
ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ, ಸುಮಾರು 20-30 ಸೆಕೆಂಡ್‌ಗಳಿಗೆ ಸಮಾನವಾದ ಯಾವುದನ್ನಾದರೂ ಯಾರಿಗಾದರೂ ಹೇಳುವ ಪ್ರಯತ್ನಗಳಿಗೆ ಸಮಯಾವಧಿಯನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಮಾತ್ರ ಇದನ್ನು ನಿಭಾಯಿಸಬಹುದು ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಹೊರಗೆ ಚಲಿಸುವ ಡೇಟಾ ಕೇಂದ್ರದ ವೇಗವನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು.
ತಾತ್ವಿಕವಾಗಿ, ಇದು ಯೋಜನೆಯ ಭಾಗವಾಗಿ ಅಂತಿಮ ಉತ್ಪನ್ನಕ್ಕೆ ಆರಂಭದಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾದ ಅವಶ್ಯಕತೆಗಳಿಗೆ ಸರಿಹೊಂದುತ್ತದೆ, ಆದರೆ "ಶುದ್ಧ ವಿಜ್ಞಾನ" ದ ದೃಷ್ಟಿಕೋನದಿಂದ ಇದು ದೋಷವಾಗಿದೆ. ಇದು ಮೂಲಕ, ಆವೃತ್ತಿ 7.2 ರಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳಿಂದ ಯಶಸ್ವಿಯಾಗಿ ಸರಿಪಡಿಸಲಾಗಿದೆ.
ಇದಲ್ಲದೆ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಡೇಟಾ ನೋಡ್ ಹೊರಬಂದಾಗ, ಅದರ ನಿರ್ಗಮನದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪ್ರಸಾರ ಮಾಡುವುದು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ಗೆ ಅದರ ಮೇಲೆ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಪ್ರಾಥಮಿಕ ಚೂರುಗಳಿವೆ ಎಂದು ಹೇಳುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ (ಇನ್ನೊಂದು ಡೇಟಾದಲ್ಲಿ ಪ್ರತಿಕೃತಿ-ಶಾರ್ಡ್ ಅನ್ನು ಉತ್ತೇಜಿಸುವ ಸಲುವಾಗಿ. ಪ್ರಾಥಮಿಕ ಕೇಂದ್ರದಲ್ಲಿ ಮತ್ತು ಮಾಹಿತಿಯಲ್ಲಿ ಅವುಗಳ ಮೇಲೆ ಬರೆಯಬಹುದು).
ಆದ್ದರಿಂದ, ಎಲ್ಲವೂ ಈಗಾಗಲೇ ಸ್ಥಗಿತಗೊಂಡಾಗ, ಬಿಡುಗಡೆಯಾದ ಡೇಟಾ ನೋಡ್ಗಳನ್ನು ತಕ್ಷಣವೇ ಹಳೆಯದು ಎಂದು ಗುರುತಿಸಲಾಗುವುದಿಲ್ಲ. ಅಂತೆಯೇ, ಬಿಡುಗಡೆಯಾದ ಡೇಟಾ ನೋಡ್‌ಗಳಿಗೆ ಎಲ್ಲಾ ಪಿಂಗ್‌ಗಳು ಸಮಯ ಮೀರುವವರೆಗೆ ನಾವು ಕಾಯಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ನಂತರವೇ ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಅಲ್ಲಿ, ಅಲ್ಲಿ ಮತ್ತು ಅಲ್ಲಿ ನಾವು ಮಾಹಿತಿಯನ್ನು ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಬೇಕಾಗಿದೆ ಎಂದು ನಮಗೆ ಹೇಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಇದರ ಬಗ್ಗೆ ನೀವು ಇನ್ನಷ್ಟು ಓದಬಹುದು .
ಪರಿಣಾಮವಾಗಿ, ಇಂದು ಡೇಟಾ ಕೇಂದ್ರವನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳುವ ಕಾರ್ಯಾಚರಣೆಯು ವಿಪರೀತ ಸಮಯದಲ್ಲಿ ನಮಗೆ ಸುಮಾರು 5 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಅಂತಹ ದೊಡ್ಡ ಮತ್ತು ಬೃಹದಾಕಾರದ ಕೋಲೋಸಸ್ಗಾಗಿ, ಇದು ಉತ್ತಮ ಫಲಿತಾಂಶವಾಗಿದೆ.
ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈ ಕೆಳಗಿನ ನಿರ್ಧಾರಕ್ಕೆ ಬಂದಿದ್ದೇವೆ:
- ನಾವು 360 ಗಿಗಾಬೈಟ್ ಡಿಸ್ಕ್ಗಳೊಂದಿಗೆ 700 ಡೇಟಾ ನೋಡ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.
- ಇದೇ ಡೇಟಾ ನೋಡ್‌ಗಳ ಮೂಲಕ ಸಂಚಾರವನ್ನು ರೂಟಿಂಗ್ ಮಾಡಲು 60 ಸಂಯೋಜಕರು.
- 40 ರ ಹಿಂದಿನ ಆವೃತ್ತಿಗಳಿಂದ ನಾವು ಒಂದು ರೀತಿಯ ಪರಂಪರೆಯಾಗಿ ಉಳಿದಿರುವ 6.4.0 ಮಾಸ್ಟರ್‌ಗಳು - ಡೇಟಾ ಸೆಂಟರ್ನ ಹಿಂತೆಗೆದುಕೊಳ್ಳುವಿಕೆಯಿಂದ ಬದುಕುಳಿಯುವ ಸಲುವಾಗಿ, ಮಾಸ್ಟರ್‌ಗಳ ಕೋರಂ ಅನ್ನು ಹೊಂದಲು ಖಾತರಿಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಹಲವಾರು ಯಂತ್ರಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಮಾನಸಿಕವಾಗಿ ಸಿದ್ಧರಾಗಿದ್ದೇವೆ. ಕೆಟ್ಟ ಸನ್ನಿವೇಶ
- ಒಂದು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಪಾತ್ರಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಯಾವುದೇ ಪ್ರಯತ್ನಗಳು ಬೇಗ ಅಥವಾ ನಂತರ ನೋಡ್ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಮುರಿಯುತ್ತದೆ ಎಂಬ ಅಂಶದೊಂದಿಗೆ ಭೇಟಿಯಾಯಿತು.
- ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ 31 ಗಿಗಾಬೈಟ್‌ಗಳ ಹೀಪ್.ಸೈಜ್ ಅನ್ನು ಬಳಸುತ್ತದೆ: ಗಾತ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಎಲ್ಲಾ ಪ್ರಯತ್ನಗಳು ಪ್ರಮುಖ ವೈಲ್ಡ್‌ಕಾರ್ಡ್‌ನೊಂದಿಗೆ ಭಾರೀ ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಕೆಲವು ನೋಡ್ಗಳನ್ನು ಕೊಲ್ಲುವಲ್ಲಿ ಅಥವಾ ಎಲಾಸ್ಟಿಕ್‌ಸರ್ಚ್‌ನಲ್ಲಿಯೇ ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಅನ್ನು ಪಡೆಯುವಲ್ಲಿ ಕಾರಣವಾಯಿತು.
- ಹೆಚ್ಚುವರಿಯಾಗಿ, ಹುಡುಕಾಟ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಾವು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಸಿಕ್ಕಿದ ಅಡಚಣೆಯಲ್ಲಿ ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಘಟನೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ವಸ್ತುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಚಿಕ್ಕದಾಗಿ ಇರಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ.
ಅಂತಿಮವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಬಗ್ಗೆ
ಇದೆಲ್ಲವೂ ಉದ್ದೇಶಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಾವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ:
- ಪ್ರತಿಯೊಂದು ಡೇಟಾ ನೋಡ್ ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ನಮ್ಮ ಕ್ಲೌಡ್‌ಗೆ ವರದಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದರ ಮೇಲೆ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಚೂರುಗಳಿವೆ. ನಾವು ಎಲ್ಲೋ ಏನನ್ನಾದರೂ ನಂದಿಸಿದಾಗ, ಕ್ಲಸ್ಟರ್ 2-3 ಸೆಕೆಂಡುಗಳ ನಂತರ ಕೇಂದ್ರ A ಯಲ್ಲಿ ನಾವು 2, 3 ಮತ್ತು 4 ನೋಡ್ಗಳನ್ನು ನಂದಿಸಿದ್ದೇವೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ - ಇದರರ್ಥ ಇತರ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ನಾವು ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲೂ ಒಂದೇ ಒಂದು ಚೂರು ಇರುವ ಆ ನೋಡ್ಗಳನ್ನು ನಂದಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಬಿಟ್ಟರು.
- ಮಾಸ್ಟರ್ನ ನಡವಳಿಕೆಯ ಸ್ವರೂಪವನ್ನು ತಿಳಿದುಕೊಂಡು, ಬಾಕಿ ಉಳಿದಿರುವ ಕಾರ್ಯಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಾವು ಬಹಳ ಎಚ್ಚರಿಕೆಯಿಂದ ನೋಡುತ್ತೇವೆ. ಏಕೆಂದರೆ ಒಂದು ಅಂಟಿಕೊಂಡಿರುವ ಕಾರ್ಯವೂ ಸಹ, ಸಮಯಕ್ಕೆ ಸಮಯ ಮೀರದಿದ್ದರೆ, ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಕೆಲವು ತುರ್ತು ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಪ್ರಾಥಮಿಕದಲ್ಲಿ ಪ್ರತಿಕೃತಿ ಚೂರುಗಳ ಪ್ರಚಾರವು ಕಾರ್ಯನಿರ್ವಹಿಸದಿರಲು ಕಾರಣವಾಗಬಹುದು, ಅದಕ್ಕಾಗಿಯೇ ಇಂಡೆಕ್ಸಿಂಗ್ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.
- ಕಸ ಸಂಗ್ರಾಹಕ ವಿಳಂಬವನ್ನು ನಾವು ಬಹಳ ಹತ್ತಿರದಿಂದ ನೋಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ಆಪ್ಟಿಮೈಸೇಶನ್ ಸಮಯದಲ್ಲಿ ನಾವು ಈಗಾಗಲೇ ಇದರೊಂದಿಗೆ ಹೆಚ್ಚಿನ ತೊಂದರೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.
- ಅಡಚಣೆ ಎಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಮುಂಚಿತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಥ್ರೆಡ್ ಮೂಲಕ ತಿರಸ್ಕರಿಸುತ್ತದೆ.
- ಸರಿ, ಹೀಪ್, RAM ಮತ್ತು I/O ನಂತಹ ಪ್ರಮಾಣಿತ ಮೆಟ್ರಿಕ್‌ಗಳು.
ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ನಿರ್ಮಿಸುವಾಗ, ನೀವು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದಲ್ಲಿ ಥ್ರೆಡ್ ಪೂಲ್‌ನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ಹುಡುಕಾಟ ಮತ್ತು ಸೂಚಿಕೆಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳು ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಆದರೆ thread_pool.management ಬಗ್ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಮೌನವಾಗಿದೆ. ಈ ಥ್ರೆಡ್‌ಗಳು ನಿರ್ದಿಷ್ಟವಾಗಿ, _cat/shards ಮತ್ತು ಇತರ ರೀತಿಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತವೆ, ಇದು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಬರೆಯುವಾಗ ಬಳಸಲು ಅನುಕೂಲಕರವಾಗಿದೆ. ದೊಡ್ಡದಾದ ಕ್ಲಸ್ಟರ್, ಪ್ರತಿ ಯುನಿಟ್ ಸಮಯಕ್ಕೆ ಅಂತಹ ಹೆಚ್ಚಿನ ವಿನಂತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಮೇಲೆ ತಿಳಿಸಲಾದ thread_pool.management ಅನ್ನು ಅಧಿಕೃತ ದಾಖಲಾತಿಯಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ 5 ಥ್ರೆಡ್‌ಗಳಿಗೆ ಸೀಮಿತವಾಗಿರುತ್ತದೆ, ನಂತರ ಅದನ್ನು ತ್ವರಿತವಾಗಿ ವಿಲೇವಾರಿ ಮಾಡಲಾಗುತ್ತದೆ. ಯಾವ ಮೇಲ್ವಿಚಾರಣೆಯು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.
ನಾನು ಕೊನೆಯಲ್ಲಿ ಏನು ಹೇಳಲು ಬಯಸುತ್ತೇನೆ: ನಾವು ಅದನ್ನು ಮಾಡಿದ್ದೇವೆ! ನಮ್ಮ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಯಾವುದೇ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದರ ಕುರಿತು ತ್ವರಿತವಾಗಿ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುವ ಸಾಧನವನ್ನು ನೀಡಲು ನಾವು ಸಮರ್ಥರಾಗಿದ್ದೇವೆ.
ಹೌದು, ಇದು ಸಾಕಷ್ಟು ಜಟಿಲವಾಗಿದೆ, ಆದರೆ, ಅದೇನೇ ಇದ್ದರೂ, ನಮ್ಮ ಶುಭಾಶಯಗಳನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಉತ್ಪನ್ನಗಳಿಗೆ ಹೊಂದಿಸಲು ನಾವು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ, ಅದನ್ನು ನಾವು ನಮಗಾಗಿ ತೇಪೆ ಮತ್ತು ಪುನಃ ಬರೆಯಬೇಕಾಗಿಲ್ಲ.
ಮೂಲ: www.habr.com