ಇಲ್ಯಾ ಕೊಸ್ಮೊಡೆಮಿಯಾನ್ಸ್ಕಿಯವರ 2015 ರ ವರದಿಯ ಪ್ರತಿಲಿಪಿ "PostgreSQL ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಲಿನಕ್ಸ್ ಟ್ಯೂನಿಂಗ್"
ಹಕ್ಕು ನಿರಾಕರಣೆ: ಈ ವರದಿಯು ನವೆಂಬರ್ 2015 ರ ದಿನಾಂಕವಾಗಿದೆ ಎಂದು ನಾನು ಗಮನಿಸುತ್ತೇನೆ - 4 ವರ್ಷಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಳೆದಿದೆ ಮತ್ತು ಸಾಕಷ್ಟು ಸಮಯ ಕಳೆದಿದೆ. ವರದಿಯಲ್ಲಿ ಚರ್ಚಿಸಲಾದ ಆವೃತ್ತಿ 9.4 ಅನ್ನು ಇನ್ನು ಮುಂದೆ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಕಳೆದ 4 ವರ್ಷಗಳಲ್ಲಿ, PostgreSQL ನ 5 ಹೊಸ ಬಿಡುಗಡೆಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗಿದೆ ಮತ್ತು Linux ಕರ್ನಲ್‌ನ 15 ಆವೃತ್ತಿಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗಿದೆ. ನೀವು ಈ ವಾಕ್ಯವೃಂದಗಳನ್ನು ಪುನಃ ಬರೆದರೆ, ನೀವು ಬೇರೆ ವರದಿಯೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತೀರಿ. ಆದರೆ ಇಲ್ಲಿ ನಾವು PostgreSQL ಗಾಗಿ ಮೂಲಭೂತ ಲಿನಕ್ಸ್ ಟ್ಯೂನಿಂಗ್ ಅನ್ನು ಪರಿಗಣಿಸುತ್ತೇವೆ, ಅದು ಇಂದಿಗೂ ಪ್ರಸ್ತುತವಾಗಿದೆ.
ನನ್ನ ಹೆಸರು ಇಲ್ಯಾ ಕೊಸ್ಮೊಡೆಮಿಯಾನ್ಸ್ಕಿ. ನಾನು PostgreSQL-ಕನ್ಸಲ್ಟಿಂಗ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ಮತ್ತು ಈಗ ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಲಿನಕ್ಸ್‌ನೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ಸ್ವಲ್ಪ ಮಾತನಾಡುತ್ತೇನೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ PostgreSQL, ಏಕೆಂದರೆ ತತ್ವಗಳು ಸಾಕಷ್ಟು ಹೋಲುತ್ತವೆ.
ನಾವು ಏನು ಮಾತನಾಡುತ್ತೇವೆ? ನೀವು PostgreSQL ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಿದರೆ, ಸ್ವಲ್ಪ ಮಟ್ಟಿಗೆ ನೀವು UNIX ನಿರ್ವಾಹಕರಾಗಿರಬೇಕು. ಅದರ ಅರ್ಥವೇನು? ನಾವು Oracle ಮತ್ತು PostgreSQL ಅನ್ನು ಹೋಲಿಕೆ ಮಾಡಿದರೆ, Oracle ನಲ್ಲಿ ನೀವು 80% DBA ಡೇಟಾಬೇಸ್ ನಿರ್ವಾಹಕ ಮತ್ತು 20% Linux ನಿರ್ವಾಹಕರಾಗಿರಬೇಕು.
PostgreSQL ನೊಂದಿಗೆ ಇದು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ. PostgreSQL ನೊಂದಿಗೆ ನೀವು Linux ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಉತ್ತಮ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿರಬೇಕು. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ, ಲೊಕೊಮೊಟಿವ್ ನಂತರ ಸ್ವಲ್ಪ ರನ್ ಮಾಡಿ, ಏಕೆಂದರೆ ಇತ್ತೀಚೆಗೆ ಎಲ್ಲವನ್ನೂ ಸಾಕಷ್ಟು ಚೆನ್ನಾಗಿ ನವೀಕರಿಸಲಾಗಿದೆ. ಮತ್ತು ಹೊಸ ಕರ್ನಲ್‌ಗಳು ಬಿಡುಗಡೆಯಾಗುತ್ತವೆ, ಮತ್ತು ಹೊಸ ಕಾರ್ಯವು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಿಸುತ್ತದೆ, ಇತ್ಯಾದಿ.
ನಾವು ಲಿನಕ್ಸ್ ಬಗ್ಗೆ ಏಕೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ? ನಾವು ಲಿನಕ್ಸ್ ಕಾನ್ಫರೆನ್ಸ್ ಪೀಟರ್‌ನಲ್ಲಿರುವುದರಿಂದ ಅಲ್ಲ, ಆದರೆ ಆಧುನಿಕ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಬಳಸುವ ಅತ್ಯಂತ ಸಮರ್ಥನೀಯ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ PostgreSQL ಲಿನಕ್ಸ್ ಆಗಿದೆ. ಏಕೆಂದರೆ FreeBSD, ದುರದೃಷ್ಟವಶಾತ್, ಕೆಲವು ವಿಚಿತ್ರ ದಿಕ್ಕಿನಲ್ಲಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ. ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಇತರ ಹಲವು ವಿಷಯಗಳೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳಿರುತ್ತವೆ. ವಿಂಡೋಸ್‌ನಲ್ಲಿನ ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಪ್ರತ್ಯೇಕ ಗಂಭೀರ ಸಮಸ್ಯೆಯಾಗಿದೆ, ಇದು ವಿಂಡೋಸ್ ಯುನಿಕ್ಸ್‌ನಂತೆಯೇ ಹಂಚಿಕೆಯ ಮೆಮೊರಿಯನ್ನು ಹೊಂದಿಲ್ಲ ಎಂಬ ಅಂಶವನ್ನು ಆಧರಿಸಿದೆ, ಆದರೆ ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್ ಎಲ್ಲವನ್ನೂ ಇದಕ್ಕೆ ಜೋಡಿಸಲಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಬಹು-ಪ್ರಕ್ರಿಯೆ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ.
ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರೂ ಸೋಲಾರಿಸ್‌ನಂತಹ ವಿಲಕ್ಷಣಗಳಲ್ಲಿ ಕಡಿಮೆ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದಾರೆಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಆದ್ದರಿಂದ ನಾವು ಹೋಗೋಣ.
ನೀವು ಕರ್ನಲ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುತ್ತೀರಿ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಆಧುನಿಕ ಲಿನಕ್ಸ್ ವಿತರಣೆಯು 1 syctl ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ವಿವಿಧ ಬೀಜಗಳನ್ನು ನೋಡಿದರೆ, ನಾವು ಏನನ್ನಾದರೂ ಹಲವು ರೀತಿಯಲ್ಲಿ ಸರಿಹೊಂದಿಸಬಹುದು. ಅವುಗಳನ್ನು ಹೇಗೆ ಆರೋಹಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಫೈಲ್ ಸಿಸ್ಟಮ್ ನಿಯತಾಂಕಗಳಿವೆ. ಅದನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ನೀವು ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ: BIOS ನಲ್ಲಿ ಏನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು, ಹಾರ್ಡ್ವೇರ್ ಅನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಇತ್ಯಾದಿ.
ಇದು ಹಲವಾರು ದಿನಗಳಲ್ಲಿ ಚರ್ಚಿಸಬಹುದಾದ ಒಂದು ದೊಡ್ಡ ಸಂಪುಟವಾಗಿದೆ, ಮತ್ತು ಒಂದು ಸಣ್ಣ ವರದಿಯಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ ಈಗ ನಾನು ಪ್ರಮುಖ ವಿಷಯಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇನೆ, ನೀವು Linux ನಲ್ಲಿ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಉತ್ತಮವಾಗಿ ಬಳಸದಂತೆ ತಡೆಯುವ ಭರವಸೆಯಿರುವ ಆ ರೇಕ್‌ಗಳನ್ನು ಹೇಗೆ ತಪ್ಪಿಸುವುದು ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಬೇಡಿ. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ, ಡೇಟಾಬೇಸ್ಗೆ ಸರಿಯಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ಅನೇಕ ಡೀಫಾಲ್ಟ್ ನಿಯತಾಂಕಗಳನ್ನು ಸೇರಿಸಲಾಗಿಲ್ಲ ಎಂಬುದು ಒಂದು ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ. ಅಂದರೆ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅದು ಕಳಪೆಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಅಥವಾ ಇಲ್ಲ.
Linux ನಲ್ಲಿ ಯಾವ ಸಾಂಪ್ರದಾಯಿಕ ಶ್ರುತಿ ಗುರಿಗಳಿವೆ? ನೀವೆಲ್ಲರೂ ಲಿನಕ್ಸ್ ಆಡಳಿತದೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತಿರುವ ಕಾರಣ, ಗುರಿಗಳು ಯಾವುವು ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ನೀವು ಟ್ಯೂನ್ ಮಾಡಬಹುದು:
- ಸಿಪಿಯು.
- ಮೆಮೊರಿ.
- ಸಂಗ್ರಹಣೆ.
- ಇತರೆ. ನಾವು ತಿಂಡಿಗಾಗಿ ಕೊನೆಯಲ್ಲಿ ಇದರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ. ಸಹ, ಉದಾಹರಣೆಗೆ, ಶಕ್ತಿ ಉಳಿತಾಯ ನೀತಿಗಳಂತಹ ನಿಯತಾಂಕಗಳು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅತ್ಯಂತ ಅನಿರೀಕ್ಷಿತವಾಗಿ ಪರಿಣಾಮ ಬೀರಬಹುದು ಮತ್ತು ಅತ್ಯಂತ ಆಹ್ಲಾದಕರ ರೀತಿಯಲ್ಲಿ ಅಲ್ಲ.
PostgreSQL ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಬೇಸ್‌ನ ವಿಶೇಷತೆಗಳು ಯಾವುವು? ಸಮಸ್ಯೆಯೆಂದರೆ ನೀವು ಯಾವುದೇ ವೈಯಕ್ತಿಕ ಅಡಿಕೆಯನ್ನು ತಿರುಚಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ನಮ್ಮ ಕಾರ್ಯಕ್ಷಮತೆ ಗಮನಾರ್ಹವಾಗಿ ಸುಧಾರಿಸಿದೆ ಎಂದು ನೋಡಿ.
ಹೌದು, ಅಂತಹ ಗ್ಯಾಜೆಟ್‌ಗಳಿವೆ, ಆದರೆ ಡೇಟಾಬೇಸ್ ಒಂದು ಸಂಕೀರ್ಣ ವಿಷಯವಾಗಿದೆ. ಇದು ಸರ್ವರ್ ಹೊಂದಿರುವ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಮತ್ತು ಪೂರ್ಣವಾಗಿ ಸಂವಹನ ಮಾಡಲು ಆದ್ಯತೆ ನೀಡುತ್ತದೆ. ಹೋಸ್ಟ್ ಓಎಸ್ ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದರ ಕುರಿತು ನೀವು ಒರಾಕಲ್‌ನ ಪ್ರಸ್ತುತ ಶಿಫಾರಸುಗಳನ್ನು ನೋಡಿದರೆ, ಅದು ಆ ಮಂಗೋಲಿಯನ್ ಗಗನಯಾತ್ರಿಗಳ ಹಾಸ್ಯದಂತೆಯೇ ಇರುತ್ತದೆ - ನಾಯಿಗೆ ಆಹಾರವನ್ನು ನೀಡಿ ಮತ್ತು ಏನನ್ನೂ ಮುಟ್ಟಬೇಡಿ. ಡೇಟಾಬೇಸ್ಗೆ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನೀಡೋಣ, ಡೇಟಾಬೇಸ್ ಸ್ವತಃ ಎಲ್ಲವನ್ನೂ ವಿಂಗಡಿಸುತ್ತದೆ.
ತಾತ್ವಿಕವಾಗಿ, ಸ್ವಲ್ಪ ಮಟ್ಟಿಗೆ ಪರಿಸ್ಥಿತಿಯು PostgreSQL ನೊಂದಿಗೆ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ವ್ಯತ್ಯಾಸವೆಂದರೆ ಡೇಟಾಬೇಸ್ ಇನ್ನೂ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ, ಅಂದರೆ ಎಲ್ಲೋ ಲಿನಕ್ಸ್ ಮಟ್ಟದಲ್ಲಿ ನೀವು ಎಲ್ಲವನ್ನೂ ನೀವೇ ವಿಂಗಡಿಸಬೇಕಾಗಿದೆ.
ಮುಖ್ಯ ಆಲೋಚನೆಯು ಒಂದೇ ಗುರಿಯನ್ನು ಆರಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಟ್ಯೂನ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುವುದು ಅಲ್ಲ, ಉದಾಹರಣೆಗೆ, ಮೆಮೊರಿ, ಸಿಪಿಯು ಅಥವಾ ಅಂತಹದ್ದೇನಾದರೂ, ಆದರೆ ಕೆಲಸದ ಹೊರೆಯನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಮತ್ತು ಥ್ರೋಪುಟ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸುಧಾರಿಸಲು ಪ್ರಯತ್ನಿಸಿ ಇದರಿಂದ ಉತ್ತಮ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಅದನ್ನು ರಚಿಸಿದ್ದಾರೆ. ನಮ್ಮ ಬಳಕೆದಾರರನ್ನು ಒಳಗೊಂಡಂತೆ ನಮಗೆ.
ಅದು ಏನೆಂದು ವಿವರಿಸಲು ಚಿತ್ರ ಇಲ್ಲಿದೆ. Linux OS ಬಫರ್ ಇದೆ ಮತ್ತು ಹಂಚಿಕೆಯ ಮೆಮೊರಿ ಇದೆ ಮತ್ತು PostgreSQL ಹಂಚಿದ ಬಫರ್‌ಗಳಿವೆ. PostgreSQL, Oracle ಗಿಂತ ಭಿನ್ನವಾಗಿ, ನೇರವಾಗಿ ಕರ್ನಲ್ ಬಫರ್ ಮೂಲಕ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅಂದರೆ, ಡಿಸ್ಕ್‌ನಿಂದ ಪುಟವು ಅದರ ಹಂಚಿಕೆಯ ಮೆಮೊರಿಗೆ ಬರಲು, ಅದು ಕರ್ನಲ್ ಬಫರ್ ಮೂಲಕ ಹೋಗಬೇಕು ಮತ್ತು ಅದೇ ಪರಿಸ್ಥಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು.
ಡಿಸ್ಕ್ಗಳು ಈ ವ್ಯವಸ್ಥೆಯ ಅಡಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ. ನಾನು ಇದನ್ನು ಡಿಸ್ಕ್ ಆಗಿ ಚಿತ್ರಿಸಿದೆ. ವಾಸ್ತವವಾಗಿ, ಒಂದು RAID ನಿಯಂತ್ರಕ, ಇತ್ಯಾದಿ ಇರಬಹುದು.
ಮತ್ತು ಈ ಇನ್ಪುಟ್-ಔಟ್ಪುಟ್ ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ಈ ವಿಷಯದ ಮೂಲಕ ಸಂಭವಿಸುತ್ತದೆ.
PostgreSQL ಒಂದು ಶ್ರೇಷ್ಠ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ. ಒಳಗೆ ಒಂದು ಪುಟವಿದೆ. ಮತ್ತು ಎಲ್ಲಾ ಇನ್ಪುಟ್ ಮತ್ತು ಔಟ್ಪುಟ್ ಪುಟಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಭವಿಸುತ್ತದೆ. ನಾವು ಪುಟಗಳೊಂದಿಗೆ ಮೆಮೊರಿಗೆ ಬ್ಲಾಕ್ಗಳನ್ನು ಹೆಚ್ಚಿಸುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ಏನೂ ಸಂಭವಿಸದಿದ್ದರೆ, ನಾವು ಅವುಗಳನ್ನು ಓದುತ್ತೇವೆ, ನಂತರ ಕ್ರಮೇಣ ಅವರು ಈ ಸಂಗ್ರಹದಿಂದ, ಹಂಚಿದ ಬಫರ್‌ಗಳಿಂದ ಕಣ್ಮರೆಯಾಗುತ್ತಾರೆ ಮತ್ತು ಡಿಸ್ಕ್ಗೆ ಹಿಂತಿರುಗುತ್ತಾರೆ.
ನಾವು ಎಲ್ಲೋ ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಿದರೆ, ಇಡೀ ಪುಟವನ್ನು ಕೊಳಕು ಎಂದು ಗುರುತಿಸಲಾಗುತ್ತದೆ. ನಾನು ಅವುಗಳನ್ನು ಇಲ್ಲಿ ನೀಲಿ ಬಣ್ಣದಲ್ಲಿ ಗುರುತಿಸಿದ್ದೇನೆ. ಮತ್ತು ಇದರರ್ಥ ಈ ಪುಟವನ್ನು ಬ್ಲಾಕ್ ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬೇಕು. ಅಂದರೆ, ನಾವು ಅದನ್ನು ಕೊಳಕು ಮಾಡಿದಾಗ, ನಾವು WAL ಗೆ ಎಂಟ್ರಿ ಕೊಟ್ಟಿದ್ದೇವೆ. ಮತ್ತು ಕೆಲವು ಅದ್ಭುತ ಕ್ಷಣದಲ್ಲಿ ಚೆಕ್ಪಾಯಿಂಟ್ ಎಂಬ ವಿದ್ಯಮಾನವು ಬಂದಿತು. ಹಾಗೂ ಈ ಲಾಗ್‌ನಲ್ಲಿ ಆತ ಬಂದಿರುವ ಬಗ್ಗೆ ಮಾಹಿತಿ ದಾಖಲಾಗಿದೆ. ಮತ್ತು ಈ ಹಂಚಿದ ಬಫರ್‌ಗಳಲ್ಲಿ ಆ ಕ್ಷಣದಲ್ಲಿದ್ದ ಎಲ್ಲಾ ಕೊಳಕು ಪುಟಗಳನ್ನು ಕರ್ನಲ್ ಬಫರ್ ಮೂಲಕ fsync ಅನ್ನು ಬಳಸಿಕೊಂಡು ಶೇಖರಣಾ ಡಿಸ್ಕ್ನೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗಿದೆ ಎಂದರ್ಥ.
ಇದನ್ನು ಏಕೆ ಮಾಡಲಾಗುತ್ತಿದೆ? ನಾವು ವೋಲ್ಟೇಜ್ ಕಳೆದುಕೊಂಡರೆ, ಎಲ್ಲಾ ಡೇಟಾ ಕಳೆದುಹೋದ ಪರಿಸ್ಥಿತಿಯನ್ನು ನಾವು ಪಡೆಯಲಿಲ್ಲ. ಪ್ರತಿಯೊಬ್ಬರೂ ನಮಗೆ ಹೇಳಿದ ನಿರಂತರ ಸ್ಮರಣೆಯು ಇಲ್ಲಿಯವರೆಗೆ ಡೇಟಾಬೇಸ್ ಸಿದ್ಧಾಂತದಲ್ಲಿದೆ - ಇದು ಉಜ್ವಲ ಭವಿಷ್ಯವಾಗಿದೆ, ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಶ್ರಮಿಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಇಷ್ಟಪಡುತ್ತೇವೆ, ಆದರೆ ಇದೀಗ ಅವರು ಮೈನಸ್ 20 ವರ್ಷಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದಾರೆ. ಮತ್ತು, ಸಹಜವಾಗಿ, ಈ ಎಲ್ಲಾ ಮೇಲ್ವಿಚಾರಣೆ ಅಗತ್ಯವಿದೆ.
ಮತ್ತು ಥ್ರೋಪುಟ್ ಅನ್ನು ಹೆಚ್ಚಿಸುವ ಕಾರ್ಯವು ಈ ಎಲ್ಲಾ ಹಂತಗಳಲ್ಲಿ ಉತ್ತಮವಾಗಿ-ಟ್ಯೂನ್ ಮಾಡುವುದು, ಇದರಿಂದ ಅದು ತ್ವರಿತವಾಗಿ ಹಿಂದಕ್ಕೆ ಮತ್ತು ಮುಂದಕ್ಕೆ ಚಲಿಸುತ್ತದೆ. ಹಂಚಿದ ಮೆಮೊರಿ ಮೂಲತಃ ಪುಟದ ಸಂಗ್ರಹವಾಗಿದೆ. PostgreSQL ನಲ್ಲಿ ನಾವು ಆಯ್ದ ಪ್ರಶ್ನೆ ಅಥವಾ ಯಾವುದನ್ನಾದರೂ ಕಳುಹಿಸಿದ್ದೇವೆ, ಅದು ಈ ಡೇಟಾವನ್ನು ಡಿಸ್ಕ್‌ನಿಂದ ಹಿಂಪಡೆದಿದೆ. ಅವರು ಹಂಚಿಕೊಂಡ ಬಫರ್‌ಗಳಲ್ಲಿ ಕೊನೆಗೊಂಡರು. ಅಂತೆಯೇ, ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು, ಸಾಕಷ್ಟು ಮೆಮೊರಿ ಇರಬೇಕು.
ಇದೆಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಮತ್ತು ತ್ವರಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು, ನೀವು ಎಲ್ಲಾ ಹಂತಗಳಲ್ಲಿ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ಸಮತೋಲಿತ ಯಂತ್ರಾಂಶವನ್ನು ಆರಿಸಿ, ಏಕೆಂದರೆ ನೀವು ಕೆಲವು ಸ್ಥಳದಲ್ಲಿ ಅಸಮತೋಲನವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ನೀವು ಸಾಕಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಮಾಡಬಹುದು, ಆದರೆ ಅದು ಸಾಕಷ್ಟು ವೇಗದಲ್ಲಿ ಸೇವೆ ಸಲ್ಲಿಸುವುದಿಲ್ಲ.
ಮತ್ತು ಈ ಪ್ರತಿಯೊಂದು ಬಿಂದುಗಳ ಮೂಲಕ ಹೋಗೋಣ.
ಈ ಪುಟಗಳನ್ನು ವೇಗವಾಗಿ ಹಿಂದಕ್ಕೆ ಮತ್ತು ಮುಂದಕ್ಕೆ ಚಲಿಸುವಂತೆ ಮಾಡಲು, ನೀವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಸಾಧಿಸಬೇಕು:
- ಮೊದಲನೆಯದಾಗಿ, ನೀವು ಮೆಮೊರಿಯೊಂದಿಗೆ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
- ಎರಡನೆಯದಾಗಿ, ಮೆಮೊರಿಯಿಂದ ಪುಟಗಳು ಡಿಸ್ಕ್ಗೆ ಹೋದಾಗ ಈ ಪರಿವರ್ತನೆಯು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರಬೇಕು.
- ಮತ್ತು ಮೂರನೆಯದಾಗಿ, ಉತ್ತಮ ಡಿಸ್ಕ್ಗಳು ಇರಬೇಕು.
ನೀವು ಸರ್ವರ್‌ನಲ್ಲಿ 512 GB RAM ಅನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಅದು ಯಾವುದೇ ಸಂಗ್ರಹವಿಲ್ಲದೆ SATA ಹಾರ್ಡ್ ಡ್ರೈವ್‌ನಲ್ಲಿ ಕೊನೆಗೊಂಡರೆ, ಸಂಪೂರ್ಣ ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ ಕೇವಲ ಕುಂಬಳಕಾಯಿಯಾಗಿಲ್ಲ, ಆದರೆ SATA ಇಂಟರ್ಫೇಸ್‌ನೊಂದಿಗೆ ಕುಂಬಳಕಾಯಿಯಾಗಿ ಬದಲಾಗುತ್ತದೆ. ನೀವು ನೇರವಾಗಿ ಅದರೊಳಗೆ ಓಡುತ್ತೀರಿ. ಮತ್ತು ಯಾವುದೂ ನಿಮ್ಮನ್ನು ಉಳಿಸುವುದಿಲ್ಲ.
ನೆನಪಿನ ಮೊದಲ ಅಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಜೀವನವನ್ನು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿಸುವ ಮೂರು ವಿಷಯಗಳಿವೆ.
ಅವುಗಳಲ್ಲಿ ಮೊದಲನೆಯದು NUMA. NUMA ಎನ್ನುವುದು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಮಾಡಲಾದ ವಸ್ತುವಾಗಿದೆ. ಕೆಲಸದ ಹೊರೆಗೆ ಅನುಗುಣವಾಗಿ, ವಿವಿಧ ವಿಷಯಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬಹುದು. ಮತ್ತು ಅದರ ಹೊಸ ಪ್ರಸ್ತುತ ರೂಪದಲ್ಲಿ, ಪುಟ ಸಂಗ್ರಹ ಹಂಚಿಕೆ ಬಫರ್ಗಳನ್ನು ತೀವ್ರವಾಗಿ ಬಳಸುವ ಡೇಟಾಬೇಸ್‌ಗಳಂತಹ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಇದು ತುಂಬಾ ಉತ್ತಮವಲ್ಲ.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ. NUMA ನಲ್ಲಿ ಏನಾದರೂ ತಪ್ಪಾಗಿದ್ದರೆ ನೀವು ಹೇಗೆ ಹೇಳಬಹುದು? ನಿಮಗೆ ಕೆಲವು ರೀತಿಯ ಅಹಿತಕರ ನಾಕ್ ಇದೆ, ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಕೆಲವು ಸಿಪಿಯು ಓವರ್ಲೋಡ್ ಆಗಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನೀವು PostgreSQL ನಲ್ಲಿ ಪ್ರಶ್ನೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತೀರಿ ಮತ್ತು ಅಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಏನೂ ಇಲ್ಲ ಎಂದು ನೋಡಿ. ಈ ಪ್ರಶ್ನೆಗಳು CPU ತೀವ್ರವಾಗಿರಬಾರದು. ನೀವು ಇದನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಹಿಡಿಯಬಹುದು. PostgreSQL ಗಾಗಿ NUMA ಅನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ಮೊದಲಿನಿಂದಲೂ ಸರಿಯಾದ ಶಿಫಾರಸುಗಳನ್ನು ಬಳಸುವುದು ಸುಲಭವಾಗಿದೆ.
ನಿಜವಾಗಿಯೂ ಏನು ನಡೆಯುತ್ತಿದೆ? NUMA ಎಂದರೆ ಏಕರೂಪವಲ್ಲದ ಮೆಮೊರಿ ಪ್ರವೇಶ. ಏನು ಪ್ರಯೋಜನ? ನೀವು CPU ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಅದರ ಪಕ್ಕದಲ್ಲಿ ಅದರ ಸ್ಥಳೀಯ ಮೆಮೊರಿ ಇದೆ. ಮತ್ತು ಈ ಮೆಮೊರಿ ಇಂಟರ್‌ಕನೆಕ್ಟ್‌ಗಳು ಇತರ CPUಗಳಿಂದ ಮೆಮೊರಿಯನ್ನು ಎಳೆಯಬಹುದು.
ನೀವು ಓಡಿದರೆ numactl --hardware, ನಂತರ ನೀವು ಅಂತಹ ದೊಡ್ಡ ಹಾಳೆಯನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ದೂರದ ಕ್ಷೇತ್ರವಿರುತ್ತದೆ. ಸಂಖ್ಯೆಗಳು ಇರುತ್ತದೆ - 10-20, ಹಾಗೆ. ಈ ಸಂಖ್ಯೆಗಳು ಈ ರಿಮೋಟ್ ಮೆಮೊರಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಮತ್ತು ಅದನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಬಳಸಲು ಹಾಪ್‌ಗಳ ಸಂಖ್ಯೆಗಿಂತ ಹೆಚ್ಚೇನೂ ಅಲ್ಲ. ತಾತ್ವಿಕವಾಗಿ, ಒಳ್ಳೆಯದು. ಇದು ಕೆಲಸದ ಹೊರೆಗಳ ವ್ಯಾಪ್ತಿಯ ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ.
ಈಗ ನೀವು ಒಂದು CPU ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಊಹಿಸಿ, ಮೊದಲು ಅದರ ಸ್ಥಳೀಯ ಮೆಮೊರಿಯನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೀರಿ, ನಂತರ ಯಾವುದನ್ನಾದರೂ ಇಂಟರ್‌ಕನೆಕ್ಟ್ ಮೂಲಕ ಮತ್ತೊಂದು ಮೆಮೊರಿಯನ್ನು ಎಳೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೀರಿ. ಮತ್ತು ಈ CPU ನಿಮ್ಮ ಸಂಪೂರ್ಣ PostgreSQL ಪುಟ ಸಂಗ್ರಹವನ್ನು ಪಡೆಯುತ್ತದೆ - ಅಷ್ಟೇ, ಕೆಲವು ಗಿಗಾಬೈಟ್‌ಗಳು. ನೀವು ಯಾವಾಗಲೂ ಕೆಟ್ಟ ಪ್ರಕರಣವನ್ನು ಪಡೆಯುತ್ತೀರಿ, ಏಕೆಂದರೆ CPU ನಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಆ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ಕಡಿಮೆ ಮೆಮೊರಿ ಇರುತ್ತದೆ. ಮತ್ತು ಸೇವೆ ಸಲ್ಲಿಸಿದ ಎಲ್ಲಾ ಮೆಮೊರಿಯು ಈ ಅಂತರ್ಸಂಪರ್ಕಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಇದು ನಿಧಾನವಾಗಿ ಮತ್ತು ದುಃಖಕರವಾಗಿ ಹೊರಹೊಮ್ಮುತ್ತದೆ. ಮತ್ತು ನಿಮ್ಮ ಪ್ರೊಸೆಸರ್ ಸೇವೆಗಳನ್ನು ಈ ನೋಡ್ ನಿರಂತರವಾಗಿ ಓವರ್ಲೋಡ್ ಆಗಿದೆ. ಮತ್ತು ಈ ಮೆಮೊರಿಯ ಪ್ರವೇಶ ಸಮಯವು ಕೆಟ್ಟದು, ನಿಧಾನವಾಗಿರುತ್ತದೆ. ನೀವು ಇದನ್ನು ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ಬಳಸುತ್ತಿದ್ದರೆ ನೀವು ಬಯಸದ ಪರಿಸ್ಥಿತಿ ಇದು.
ಆದ್ದರಿಂದ, ಡೇಟಾಬೇಸ್ಗೆ ಹೆಚ್ಚು ಸರಿಯಾದ ಆಯ್ಕೆಯೆಂದರೆ ಲಿನಕ್ಸ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂದು ತಿಳಿದಿಲ್ಲ. ಆದ್ದರಿಂದ ಅದು ಮಾಡುವಂತೆ ಮೆಮೊರಿಯನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ.
ಅದು ಏಕೆ? ಇದು ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ಇರಬೇಕು ಎಂದು ತೋರುತ್ತದೆ. ಇದು ಒಂದು ಸರಳ ಕಾರಣಕ್ಕಾಗಿ ಸಂಭವಿಸುತ್ತದೆ: ಪುಟದ ಸಂಗ್ರಹಕ್ಕಾಗಿ ನಮಗೆ ಸಾಕಷ್ಟು ಮೆಮೊರಿ ಬೇಕು - ಹತ್ತಾರು, ನೂರಾರು ಗಿಗಾಬೈಟ್‌ಗಳು.
ಮತ್ತು ನಾವು ಈ ಎಲ್ಲವನ್ನು ನಿಯೋಜಿಸಿದರೆ ಮತ್ತು ಅಲ್ಲಿ ನಮ್ಮ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, ಸಂಗ್ರಹವನ್ನು ಬಳಸುವುದರಿಂದ ಆಗುವ ಲಾಭವು ಮೆಮೊರಿಗೆ ಅಂತಹ ಟ್ರಿಕಿ ಪ್ರವೇಶದ ಲಾಭಕ್ಕಿಂತ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. ಮತ್ತು ನಾವು NUMA ಅನ್ನು ಬಳಸಿಕೊಂಡು ಮೆಮೊರಿಯನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಪ್ರವೇಶಿಸುತ್ತೇವೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಹೋಲಿಸಿದರೆ ನಾವು ಹೋಲಿಸಲಾಗದಷ್ಟು ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತೇವೆ.
ಆದ್ದರಿಂದ, ಈ ಸಮಯದಲ್ಲಿ ಇಲ್ಲಿ ಎರಡು ವಿಧಾನಗಳಿವೆ, ಉಜ್ವಲ ಭವಿಷ್ಯವು ಬರುವವರೆಗೆ, ಮತ್ತು ಡೇಟಾಬೇಸ್ ಸ್ವತಃ ಯಾವ CPU ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಮತ್ತು ಎಲ್ಲಿಂದ ಏನನ್ನಾದರೂ ಎಳೆಯಬೇಕು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ, NUMA ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಸರಿಯಾದ ವಿಧಾನವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ರೀಬೂಟ್ ಮಾಡುವಾಗ. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಗೆಲುವುಗಳು ಅಂತಹ ಆದೇಶಗಳನ್ನು ಹೊಂದಿದ್ದು, ಯಾವುದು ಉತ್ತಮ ಎಂಬ ಪ್ರಶ್ನೆಯು ಉದ್ಭವಿಸುವುದಿಲ್ಲ.
ಇನ್ನೊಂದು ಆಯ್ಕೆ ಇದೆ. ನಾವು ಇದನ್ನು ಮೊದಲನೆಯದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಬಳಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಬೆಂಬಲಕ್ಕಾಗಿ ನಮ್ಮ ಬಳಿಗೆ ಬಂದಾಗ, ಸರ್ವರ್ ಅನ್ನು ರೀಬೂಟ್ ಮಾಡುವುದು ಅವರಿಗೆ ದೊಡ್ಡ ವ್ಯವಹಾರವಾಗಿದೆ. ಅವನಿಗೆ ಅಲ್ಲಿ ವ್ಯಾಪಾರವಿದೆ. ಮತ್ತು ಅವರು NUMA ಕಾರಣದಿಂದಾಗಿ ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಭವಿಸುತ್ತಾರೆ. ಆದ್ದರಿಂದ, ನಾವು ಅದನ್ನು ರೀಬೂಟ್ ಮಾಡುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ಆಕ್ರಮಣಕಾರಿ ವಿಧಾನಗಳಲ್ಲಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ಆದರೆ ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ಜಾಗರೂಕರಾಗಿರಿ. ಏಕೆಂದರೆ, ಅನುಭವವು ತೋರಿಸಿದಂತೆ, ಪೋಷಕ PostgreSQL ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಾವು NUMA ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಒಳ್ಳೆಯದು, ಆದರೆ ಅದು ಕೆಲಸ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಅವಳು ನಿಜವಾಗಿಯೂ ಸ್ವಿಚ್ ಆಫ್ ಆಗಿದ್ದಾಳೆ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ನೋಡಬೇಕು.
ರಾಬರ್ಟ್ ಹಾಸ್ ಅವರ ಉತ್ತಮ ಪೋಸ್ಟ್ ಇದೆ. ಇದು PostgreSQL ಕಮಿಟರ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಎಲ್ಲಾ ಕೆಳಮಟ್ಟದ ಗಿಬ್ಲೆಟ್‌ಗಳ ಪ್ರಮುಖ ಡೆವಲಪರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರು. ಮತ್ತು ನೀವು ಈ ಪೋಸ್ಟ್‌ನಿಂದ ಲಿಂಕ್‌ಗಳನ್ನು ಅನುಸರಿಸಿದರೆ, NUMA ಜನರಿಗೆ ಜೀವನವನ್ನು ಹೇಗೆ ಕಷ್ಟಕರವಾಗಿಸಿದೆ ಎಂಬುದರ ಕುರಿತು ಅವರು ಹಲವಾರು ವರ್ಣರಂಜಿತ ಕಥೆಗಳನ್ನು ವಿವರಿಸುತ್ತಾರೆ. ನೋಡಿ, ನಮ್ಮ ಡೇಟಾಬೇಸ್ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಸರ್ವರ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾದ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರ ಪರಿಶೀಲನಾಪಟ್ಟಿಯನ್ನು ಅಧ್ಯಯನ ಮಾಡಿ. ಈ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬರೆಯಬೇಕು ಮತ್ತು ಪರಿಶೀಲಿಸಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಅದು ತುಂಬಾ ಉತ್ತಮವಾಗುವುದಿಲ್ಲ.
ನಾನು ಮಾತನಾಡುವ ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಇದು ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ದೋಷ ಸಹಿಷ್ಣುತೆಗಾಗಿ ಮಾಸ್ಟರ್-ಸ್ಲೇವ್ ಮೋಡ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಈ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಸ್ಲೇವ್‌ನಲ್ಲಿ ಮಾಡಲು ಮರೆಯಬೇಡಿ ಏಕೆಂದರೆ ಒಂದು ದಿನ ನೀವು ಅಪಘಾತಕ್ಕೊಳಗಾಗುತ್ತೀರಿ ಮತ್ತು ನೀವು ಗುಲಾಮನಿಗೆ ಬದಲಾಯಿಸುತ್ತೀರಿ ಮತ್ತು ಅದು ಯಜಮಾನನಾಗುತ್ತಾನೆ.
ತುರ್ತು ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಎಲ್ಲವೂ ತುಂಬಾ ಕೆಟ್ಟದಾಗಿದ್ದಾಗ, ನಿಮ್ಮ ಫೋನ್ ನಿರಂತರವಾಗಿ ರಿಂಗ್ ಆಗುತ್ತಿರುವಾಗ ಮತ್ತು ನಿಮ್ಮ ಬಾಸ್ ದೊಡ್ಡ ಕೋಲಿನೊಂದಿಗೆ ಓಡುತ್ತಿರುವಾಗ, ಪರಿಶೀಲಿಸುವ ಬಗ್ಗೆ ಯೋಚಿಸಲು ನಿಮಗೆ ಸಮಯವಿರುವುದಿಲ್ಲ. ಮತ್ತು ಫಲಿತಾಂಶಗಳು ಸಾಕಷ್ಟು ಹಾನಿಕಾರಕವಾಗಬಹುದು.
ಮುಂದಿನ ಹಂತವು ದೊಡ್ಡ ಪುಟಗಳು. ಬೃಹತ್ ಪುಟಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸುವುದು ಕಷ್ಟ, ಮತ್ತು ಹಾಗೆ ಮಾಡುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ, ಆದರೂ ಇದನ್ನು ಮಾಡಬಹುದಾದ ಮಾನದಂಡಗಳಿವೆ. ಅವರು Google ಗೆ ಸುಲಭ.
ಏನು ಪ್ರಯೋಜನ? ನೀವು ಸಾಕಷ್ಟು RAM ಹೊಂದಿರುವ ಅತ್ಯಂತ ದುಬಾರಿ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, 30 GB ಗಿಂತ ಹೆಚ್ಚು. ನೀವು ದೊಡ್ಡ ಪುಟಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಇದರರ್ಥ ನೀವು ಖಂಡಿತವಾಗಿಯೂ ಮೆಮೊರಿ ಬಳಕೆಯ ವಿಷಯದಲ್ಲಿ ಓವರ್ಹೆಡ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಮತ್ತು ಈ ಓವರ್ಹೆಡ್ ಅತ್ಯಂತ ಆಹ್ಲಾದಕರದಿಂದ ದೂರವಿದೆ.
ಅದು ಏಕೆ? ಮತ್ತೆ ಏನು ನಡೀತಿದೆ? ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಮೆಮೊರಿಯನ್ನು ಸಣ್ಣ ತುಂಡುಗಳಲ್ಲಿ ನಿಯೋಜಿಸುತ್ತದೆ. ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ, ಇದು ಐತಿಹಾಸಿಕವಾಗಿ ಹೇಗೆ ಸಂಭವಿಸಿತು. ಮತ್ತು ನಾವು ವಿವರವಾಗಿ ಹೋದರೆ, OS ವರ್ಚುವಲ್ ವಿಳಾಸಗಳನ್ನು ಭೌತಿಕ ಪದಗಳಿಗಿಂತ ಭಾಷಾಂತರಿಸಬೇಕು. ಮತ್ತು ಈ ಪ್ರಕ್ರಿಯೆಯು ಸರಳವಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ OS ಈ ಕಾರ್ಯಾಚರಣೆಯ ಫಲಿತಾಂಶವನ್ನು ಅನುವಾದ ಲುಕ್ಸೈಡ್ ಬಫರ್ (TLB) ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ.
ಮತ್ತು TLB ಒಂದು ಸಂಗ್ರಹವಾಗಿರುವುದರಿಂದ, ಸಂಗ್ರಹದಲ್ಲಿ ಅಂತರ್ಗತವಾಗಿರುವ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳು ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಉದ್ಭವಿಸುತ್ತವೆ. ಮೊದಲನೆಯದಾಗಿ, ನೀವು ಸಾಕಷ್ಟು RAM ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಅದನ್ನು ಸಣ್ಣ ಭಾಗಗಳಲ್ಲಿ ಹಂಚಿದ್ದರೆ, ಈ ಬಫರ್ ತುಂಬಾ ದೊಡ್ಡದಾಗುತ್ತದೆ. ಮತ್ತು ಸಂಗ್ರಹವು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಅದರ ಮೂಲಕ ಹುಡುಕುವುದು ನಿಧಾನವಾಗಿರುತ್ತದೆ. ಓವರ್ಹೆಡ್ ಆರೋಗ್ಯಕರವಾಗಿದೆ ಮತ್ತು ಅದು ಸ್ವತಃ ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಅಂದರೆ RAM ಅನ್ನು ಯಾವುದೋ ತಪ್ಪಾಗಿ ಸೇವಿಸಲಾಗುತ್ತದೆ. ಈ ಸಮಯ.
ಎರಡು - ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಸಂಗ್ರಹವು ಹೆಚ್ಚು ಬೆಳೆಯುತ್ತದೆ, ನೀವು ಸಂಗ್ರಹವನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು. ಮತ್ತು ಅದರ ಗಾತ್ರ ಹೆಚ್ಚಾದಂತೆ ಈ ಸಂಗ್ರಹದ ದಕ್ಷತೆಯು ವೇಗವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ಗಳು ಸರಳವಾದ ವಿಧಾನದೊಂದಿಗೆ ಬಂದವು. ಇದನ್ನು ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ದೀರ್ಘಕಾಲ ಬಳಸಲಾಗುತ್ತಿದೆ. ಇದು ಬಹಳ ಹಿಂದೆಯೇ FreeBSD ಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿತು. ಆದರೆ ನಾವು ಲಿನಕ್ಸ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ಇವು ದೊಡ್ಡ ಪುಟಗಳು.
ಮತ್ತು ಇಲ್ಲಿ ಗಮನಿಸಬೇಕಾದ ಸಂಗತಿಯೆಂದರೆ, ಒಂದು ಕಲ್ಪನೆಯಂತೆ, ಒರಾಕಲ್ ಮತ್ತು IBM ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಸಮುದಾಯಗಳಿಂದ ಆರಂಭದಲ್ಲಿ ದೊಡ್ಡ ಪುಟಗಳನ್ನು ತಳ್ಳಲಾಯಿತು, ಅಂದರೆ ಡೇಟಾಬೇಸ್ ತಯಾರಕರು ಇದು ಡೇಟಾಬೇಸ್‌ಗಳಿಗೂ ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ಬಲವಾಗಿ ಭಾವಿಸಿದ್ದರು.
ಮತ್ತು ಇದನ್ನು PostgreSQL ನೊಂದಿಗೆ ಹೇಗೆ ಸ್ನೇಹಿತರಾಗಬಹುದು? ಮೊದಲನೆಯದಾಗಿ, ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ನಲ್ಲಿ ಬೃಹತ್ ಪುಟಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು.
ಎರಡನೆಯದಾಗಿ, ಅವುಗಳನ್ನು sysctl ನಿಯತಾಂಕದಿಂದ ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು - ಎಷ್ಟು ಇವೆ. ಇಲ್ಲಿರುವ ಸಂಖ್ಯೆಗಳು ಕೆಲವು ಹಳೆಯ ಸರ್ವರ್‌ನಿಂದ ಬಂದವು. ನೀವು ಎಷ್ಟು ಹಂಚಿದ ಬಫರ್ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ನೀವು ಲೆಕ್ಕ ಹಾಕಬಹುದು ಇದರಿಂದ ದೊಡ್ಡ ಪುಟಗಳು ಅಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ.
ಮತ್ತು ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಸರ್ವರ್ PostgreSQL ಗೆ ಮೀಸಲಾಗಿದ್ದರೆ, ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಖಂಡಿತವಾಗಿಯೂ ಈ 25% ಗೆ ಸರಿಹೊಂದುತ್ತದೆ ಎಂದು ನಿಮಗೆ ಖಚಿತವಾಗಿದ್ದರೆ RAM ನ 75% ಅಥವಾ ಹಂಚಿಕೆಯ ಬಫರ್‌ಗಳಿಗೆ 75% ಅನ್ನು ನಿಯೋಜಿಸುವುದು ಉತ್ತಮ ಆರಂಭಿಕ ಹಂತವಾಗಿದೆ. ಆರಂಭಿಕ ಹಂತ ಒಂದು. ಮತ್ತು ಪರಿಗಣಿಸಿ, ನೀವು 256 GB RAM ಹೊಂದಿದ್ದರೆ, ಅದರ ಪ್ರಕಾರ, ನೀವು 64 GB ದೊಡ್ಡ ಬಫರ್ಗಳನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಕೆಲವು ಅಂಚುಗಳೊಂದಿಗೆ ಸರಿಸುಮಾರು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ - ಈ ಅಂಕಿ ಏನನ್ನು ಹೊಂದಿಸಬೇಕು.
ಆವೃತ್ತಿ 9.2 ಕ್ಕಿಂತ ಮೊದಲು (ನಾನು ತಪ್ಪಾಗಿ ಭಾವಿಸದಿದ್ದರೆ, ಆವೃತ್ತಿ 8.2 ರಿಂದ), ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿಕೊಂಡು ದೊಡ್ಡ ಪುಟಗಳೊಂದಿಗೆ PostgreSQL ಅನ್ನು ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಮತ್ತು ಇದನ್ನು ಯಾವಾಗಲೂ ಮಾಡಬೇಕು. ಮೊದಲಿಗೆ, ಬೃಹತ್ ಪುಟಗಳನ್ನು ಸರಿಯಾಗಿ ನಿಯೋಜಿಸಲು ನಿಮಗೆ ಕರ್ನಲ್ ಅಗತ್ಯವಿದೆ. ಮತ್ತು, ಎರಡನೆಯದಾಗಿ, ಆದ್ದರಿಂದ ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್ ಅವುಗಳನ್ನು ಬಳಸಬಹುದು. ಅದನ್ನು ಕೇವಲ ಆ ರೀತಿಯಲ್ಲಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ. PostgreSQL ಸಿಸ್ಟಮ್ 5 ಶೈಲಿಯಲ್ಲಿ ಮೆಮೊರಿಯನ್ನು ನಿಯೋಜಿಸಿರುವುದರಿಂದ, ಇದನ್ನು libhugetlbfs ಬಳಸಿ ಮಾಡಬಹುದು - ಇದು ಲೈಬ್ರರಿಯ ಪೂರ್ಣ ಹೆಸರು.
9.3 ರಲ್ಲಿ, ಮೆಮೊರಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ PostgreSQL ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲಾಯಿತು ಮತ್ತು ಸಿಸ್ಟಮ್ 5 ಮೆಮೊರಿ ಹಂಚಿಕೆ ವಿಧಾನವನ್ನು ಕೈಬಿಡಲಾಯಿತು. ಪ್ರತಿಯೊಬ್ಬರೂ ತುಂಬಾ ಸಂತೋಷಪಟ್ಟರು, ಇಲ್ಲದಿದ್ದರೆ ನೀವು ಒಂದು ಗಣಕದಲ್ಲಿ ಎರಡು PostgreSQL ನಿದರ್ಶನಗಳನ್ನು ಚಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೀರಿ ಮತ್ತು ನನ್ನಲ್ಲಿ ಸಾಕಷ್ಟು ಹಂಚಿಕೆಯ ಮೆಮೊರಿ ಇಲ್ಲ ಎಂದು ಅವರು ಹೇಳುತ್ತಾರೆ. ಮತ್ತು sysctl ಅನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ ಎಂದು ಅವರು ಹೇಳುತ್ತಾರೆ. ಮತ್ತು ನೀವು ಇನ್ನೂ ರೀಬೂಟ್ ಮಾಡಬೇಕಾದ ಇಂತಹ sysctl ಇದೆ, ಇತ್ಯಾದಿ. ಸಾಮಾನ್ಯವಾಗಿ, ಎಲ್ಲರೂ ಸಂತೋಷವಾಗಿದ್ದರು. ಆದರೆ ಎಂಎಂಎಪಿ ಮೆಮೊರಿ ಹಂಚಿಕೆಯು ಬೃಹತ್ ಪುಟಗಳ ಬಳಕೆಯನ್ನು ಮುರಿಯಿತು. ನಮ್ಮ ಹೆಚ್ಚಿನ ಗ್ರಾಹಕರು ದೊಡ್ಡ ಹಂಚಿದ ಬಫರ್ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ. ಮತ್ತು 9.3 ಗೆ ಬದಲಾಯಿಸದಂತೆ ನಾವು ಬಲವಾಗಿ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ಓವರ್ಹೆಡ್ ಅನ್ನು ಉತ್ತಮ ಶೇಕಡಾವಾರುಗಳಲ್ಲಿ ಲೆಕ್ಕಹಾಕಲು ಪ್ರಾರಂಭಿಸಿತು.
ಆದರೆ ಸಮುದಾಯವು ಈ ಸಮಸ್ಯೆಯತ್ತ ಗಮನ ಹರಿಸಿತು ಮತ್ತು 9.4 ರಲ್ಲಿ ಅವರು ಈ ಘಟನೆಯನ್ನು ಚೆನ್ನಾಗಿ ಮರುನಿರ್ಮಾಣ ಮಾಡಿದರು. ಮತ್ತು 9.4 ರಲ್ಲಿ postgresql.conf ನಲ್ಲಿ ಪ್ಯಾರಾಮೀಟರ್ ಕಾಣಿಸಿಕೊಂಡಿತು, ಅದರಲ್ಲಿ ನೀವು ಪ್ರಯತ್ನಿಸಬಹುದು, ಆನ್ ಅಥವಾ ಆಫ್ ಮಾಡಬಹುದು.
ಪ್ರಯತ್ನಿಸಿ ಸುರಕ್ಷಿತ ಆಯ್ಕೆಯಾಗಿದೆ. PostgreSQL ಪ್ರಾರಂಭವಾದಾಗ, ಅದು ಹಂಚಿದ ಮೆಮೊರಿಯನ್ನು ನಿಯೋಜಿಸಿದಾಗ, ಅದು ದೊಡ್ಡ ಪುಟಗಳಿಂದ ಈ ಮೆಮೊರಿಯನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಮತ್ತು ಅದು ಕೆಲಸ ಮಾಡದಿದ್ದರೆ, ಅದು ಸಾಮಾನ್ಯ ಆಯ್ಕೆಗೆ ಹಿಂತಿರುಗುತ್ತದೆ. ಮತ್ತು ನೀವು FreeBSD ಅಥವಾ Solaris ಹೊಂದಿದ್ದರೆ, ನೀವು ಪ್ರಯತ್ನಿಸಬಹುದು, ಅದು ಯಾವಾಗಲೂ ಸುರಕ್ಷಿತವಾಗಿರುತ್ತದೆ.
ಆನ್ ಆಗಿದ್ದರೆ, ದೊಡ್ಡ ಪುಟಗಳಿಂದ ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಅದು ಸರಳವಾಗಿ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ. ಇಲ್ಲಿ ಇದು ಈಗಾಗಲೇ ಯಾರು ಮತ್ತು ಯಾವುದು ಉತ್ತಮವಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು. ಆದರೆ ನೀವು ಪ್ರಯತ್ನಿಸಿದರೆ, ನಿಮಗೆ ಹೈಲೈಟ್ ಮಾಡಬೇಕಾದುದನ್ನು ನೀವು ನಿಜವಾಗಿಯೂ ಹೊಂದಿದ್ದೀರಾ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ದೋಷಕ್ಕೆ ಸಾಕಷ್ಟು ಸ್ಥಳವಿದೆ. ಪ್ರಸ್ತುತ ಈ ಕಾರ್ಯವು Linux ನಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ನಾವು ಮುಂದೆ ಹೋಗುವ ಮೊದಲು ಇನ್ನೂ ಒಂದು ಸಣ್ಣ ಟಿಪ್ಪಣಿ. ಪಾರದರ್ಶಕ ಬೃಹತ್ ಪುಟಗಳು ಇನ್ನೂ PostgreSQL ಬಗ್ಗೆ ಅಲ್ಲ. ಅವನು ಅವುಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ಅಂತಹ ಕೆಲಸದ ಹೊರೆಗಾಗಿ ಪಾರದರ್ಶಕ ಬೃಹತ್ ಪುಟಗಳೊಂದಿಗೆ, ಹಂಚಿದ ಮೆಮೊರಿಯ ದೊಡ್ಡ ತುಣುಕು ಅಗತ್ಯವಿದ್ದಾಗ, ಪ್ರಯೋಜನಗಳು ಬಹಳ ದೊಡ್ಡ ಸಂಪುಟಗಳೊಂದಿಗೆ ಮಾತ್ರ ಬರುತ್ತವೆ. ನೀವು ಟೆರಾಬೈಟ್‌ಗಳಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಇದು ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರಬಹುದು. ನಾವು ಹೆಚ್ಚು ದೈನಂದಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಕುರಿತು ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಗಣಕದಲ್ಲಿ ನೀವು 32, 64, 128, 256 GB ಮೆಮೊರಿಯನ್ನು ಹೊಂದಿರುವಾಗ, ಸಾಮಾನ್ಯ ದೊಡ್ಡ ಪುಟಗಳು ಸರಿ, ಮತ್ತು ನಾವು ಪಾರದರ್ಶಕತೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ.
ಮತ್ತು ಮೆಮೊರಿಯ ಕೊನೆಯ ವಿಷಯವು ನೇರವಾಗಿ ಹಣ್ಣಿನೊಂದಿಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ, ಅದು ನಿಜವಾಗಿಯೂ ನಿಮ್ಮ ಜೀವನವನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ. ಸರ್ವರ್ ನಿರಂತರವಾಗಿ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುವುದರಿಂದ ಎಲ್ಲಾ ಥ್ರೋಪುಟ್ ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ಮತ್ತು ಇದು ಹಲವಾರು ರೀತಿಯಲ್ಲಿ ತುಂಬಾ ಅಹಿತಕರವಾಗಿರುತ್ತದೆ. ಮತ್ತು ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ ಆಧುನಿಕ ಕರ್ನಲ್‌ಗಳು ಹಳೆಯ ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ಗಳಿಗಿಂತ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತವೆ. ಮತ್ತು ಈ ವಿಷಯವು ಹೆಜ್ಜೆ ಹಾಕಲು ಸಾಕಷ್ಟು ಅಹಿತಕರವಾಗಿದೆ, ಏಕೆಂದರೆ ನಾವು ಸ್ವಾಪ್ನೊಂದಿಗೆ ಕೆಲವು ರೀತಿಯ ಕೆಲಸದ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ಅದು OOM- ಕೊಲೆಗಾರನ ಅಕಾಲಿಕ ಆಗಮನದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಮತ್ತು OOM-ಕಿಲ್ಲರ್, ಇದು ಸಮಯಕ್ಕೆ ಸರಿಯಾಗಿ ಬರಲಿಲ್ಲ ಮತ್ತು PostgreSQL ಅನ್ನು ಕೈಬಿಟ್ಟಿತು, ಇದು ಅಹಿತಕರವಾಗಿದೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಇದರ ಬಗ್ಗೆ ತಿಳಿಯುತ್ತಾರೆ, ಅಂದರೆ, ಕೊನೆಯ ಬಳಕೆದಾರರವರೆಗೆ.
ಏನಾಗುತ್ತಿದೆ? ನೀವು ಅಲ್ಲಿ ದೊಡ್ಡ ಪ್ರಮಾಣದ RAM ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಂದಾಗಿ ಸರ್ವರ್ ಸ್ವಾಪ್ನಲ್ಲಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಇದರಿಂದಾಗಿ ನಿಧಾನಗೊಳ್ಳುತ್ತದೆ. ಬಹಳಷ್ಟು ಸ್ಮರಣೆ ಇದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಇದು ಸಂಭವಿಸುತ್ತದೆ.
ಹಿಂದೆ, ನಾವು vm.swappiness ಅನ್ನು ಶೂನ್ಯಕ್ಕೆ ಹೊಂದಿಸಲು ಸಲಹೆ ನೀಡಿದ್ದೇವೆ, ಅಂದರೆ ಸ್ವಾಪ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು. ಹಿಂದೆ, 32 GB RAM ಮತ್ತು ಅನುಗುಣವಾದ ಹಂಚಿಕೆಯ ಬಫರ್‌ಗಳು ದೊಡ್ಡ ಮೊತ್ತವಾಗಿದೆ ಎಂದು ತೋರುತ್ತಿದೆ. ಸ್ವಾಪ್ನ ಮುಖ್ಯ ಉದ್ದೇಶವೆಂದರೆ ನಾವು ಬಿದ್ದರೆ ಕ್ರಸ್ಟ್ ಅನ್ನು ಎಸೆಯಲು ಸ್ಥಳವನ್ನು ಹೊಂದಿರುವುದು. ಮತ್ತು ಇದು ಇನ್ನು ಮುಂದೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಈಡೇರಲಿಲ್ಲ. ತದನಂತರ ನೀವು ಈ ಕ್ರಸ್ಟ್‌ನೊಂದಿಗೆ ಏನು ಮಾಡಲಿದ್ದೀರಿ? ಇದು ಒಂದು ಕಾರ್ಯವಾಗಿದ್ದು, ವಿಶೇಷವಾಗಿ ಅಂತಹ ಗಾತ್ರದ ಸ್ವಾಪ್ ಏಕೆ ಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.
ಆದರೆ ಹೆಚ್ಚು ಆಧುನಿಕ, ಅಂದರೆ, ಕರ್ನಲ್‌ನ ಮೂರನೇ ಆವೃತ್ತಿಗಳಲ್ಲಿ, ನಡವಳಿಕೆಯು ಬದಲಾಗಿದೆ. ಮತ್ತು ನೀವು ಸ್ವಾಪ್ ಅನ್ನು ಶೂನ್ಯಕ್ಕೆ ಹೊಂದಿಸಿದರೆ, ಅಂದರೆ ಅದನ್ನು ಆಫ್ ಮಾಡಿ, ನಂತರ ಬೇಗ ಅಥವಾ ನಂತರ, ಕೆಲವು RAM ಉಳಿದಿದ್ದರೂ ಸಹ, ಹೆಚ್ಚು ತೀವ್ರವಾದ ಗ್ರಾಹಕರನ್ನು ಕೊಲ್ಲಲು OOM ಕೊಲೆಗಾರ ನಿಮ್ಮ ಬಳಿಗೆ ಬರುತ್ತಾನೆ. ಏಕೆಂದರೆ ಅಂತಹ ಕೆಲಸದ ಹೊರೆಯೊಂದಿಗೆ ನಾವು ಇನ್ನೂ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಉಳಿದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಜಿಗಿಯುತ್ತೇವೆ, ಅಂದರೆ, ಸಿಸ್ಟಮ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೊಡೆಯಲು ಅಲ್ಲ, ಆದರೆ ಕಡಿಮೆ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೊಡೆಯಲು. ಈ ಕಡಿಮೆ ಪ್ರಾಮುಖ್ಯತೆಯು ಹಂಚಿಕೊಂಡ ಮೆಮೊರಿಯ ತೀವ್ರವಾದ ಗ್ರಾಹಕ, ಅವುಗಳೆಂದರೆ ಪೋಸ್ಟ್‌ಮಾಸ್ಟರ್. ಮತ್ತು ಅದರ ನಂತರ ಬೇಸ್ ಅನ್ನು ಪುನಃಸ್ಥಾಪಿಸಬೇಕಾಗಿಲ್ಲದಿದ್ದರೆ ಅದು ಒಳ್ಳೆಯದು.
ಆದ್ದರಿಂದ, ಈಗ ಡೀಫಾಲ್ಟ್, ನನಗೆ ನೆನಪಿರುವಂತೆ, ಹೆಚ್ಚಿನ ವಿತರಣೆಗಳು ಎಲ್ಲೋ 6 ರಷ್ಟಿದೆ, ಅಂದರೆ ಎಷ್ಟು ಮೆಮೊರಿ ಉಳಿದಿದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿ ನೀವು ಯಾವ ಹಂತದಲ್ಲಿ ಸ್ವಾಪ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಬೇಕು. ನಾವು ಈಗ vm.swappiness = 1 ಅನ್ನು ಹೊಂದಿಸಲು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ಇದು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅದನ್ನು ಆಫ್ ಮಾಡುತ್ತದೆ, ಆದರೆ OOM-ಕೊಲೆಗಾರನೊಂದಿಗಿನ ಅದೇ ಪರಿಣಾಮಗಳನ್ನು ನೀಡುವುದಿಲ್ಲ, ಅದು ಅನಿರೀಕ್ಷಿತವಾಗಿ ಆಗಮಿಸಿ ಇಡೀ ವಿಷಯವನ್ನು ಕೊಂದಿತು.
ಮುಂದೇನು? ನಾವು ಡೇಟಾಬೇಸ್‌ಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ ಮತ್ತು ಕ್ರಮೇಣ ಡಿಸ್ಕ್ಗಳ ಕಡೆಗೆ ಚಲಿಸುವಾಗ, ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮ ತಲೆಗಳನ್ನು ಹಿಡಿಯಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಏಕೆಂದರೆ ಡಿಸ್ಕ್ ನಿಧಾನವಾಗಿರುತ್ತದೆ ಮತ್ತು ಮೆಮೊರಿ ವೇಗವಾಗಿರುತ್ತದೆ ಎಂಬ ಸತ್ಯವು ಬಾಲ್ಯದಿಂದಲೂ ಎಲ್ಲರಿಗೂ ತಿಳಿದಿದೆ. ಮತ್ತು ಡೇಟಾಬೇಸ್ ಡಿಸ್ಕ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ ಎಂದು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿದೆ.
ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳ ಸ್ಪೈಕ್‌ಗಳೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಮುಖ PostgreSQL ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಯು ಡಿಸ್ಕ್ ನಿಧಾನವಾಗಿರುವುದರಿಂದ ಸಂಭವಿಸುವುದಿಲ್ಲ. ಮೆಮೊರಿ ಮತ್ತು ಡಿಸ್ಕ್ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಸಮತೋಲಿತವಾಗಿಲ್ಲ ಎಂಬ ಅಂಶದಿಂದಾಗಿ ಇದು ಹೆಚ್ಚಾಗಿ ಸಂಭವಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಅವರು ವಿವಿಧ ಸ್ಥಳಗಳಲ್ಲಿ ಸಮತೋಲಿತವಾಗಿರುವುದಿಲ್ಲ. PostgreSQL ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿಲ್ಲ, OS ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿಲ್ಲ, ಹಾರ್ಡ್ವೇರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿಲ್ಲ ಮತ್ತು ಹಾರ್ಡ್ವೇರ್ ತಪ್ಪಾಗಿದೆ. ಮತ್ತು ಎಲ್ಲವೂ ಸಂಭವಿಸಿದಲ್ಲಿ ಮಾತ್ರ ಈ ಸಮಸ್ಯೆ ಸಂಭವಿಸುವುದಿಲ್ಲ, ಅಂದರೆ ಯಾವುದೇ ಲೋಡ್ ಇಲ್ಲ, ಅಥವಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಹಾರ್ಡ್ವೇರ್ ಅನ್ನು ಉತ್ತಮವಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ.
ಅದು ಏನು ಮತ್ತು ಅದು ಹೇಗೆ ಕಾಣುತ್ತದೆ? ಸಾಮಾನ್ಯವಾಗಿ PostgreSQL ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಜನರು ಈ ವಿಷಯವನ್ನು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಪ್ರವೇಶಿಸಿದ್ದಾರೆ. ನಾನು ವಿವರಿಸುತ್ತೇನೆ. ನಾನು ಹೇಳಿದಂತೆ, PostgreSQL ನಿಯತಕಾಲಿಕವಾಗಿ ಹಂಚಿದ ಮೆಮೊರಿಯಲ್ಲಿ ಕೊಳಕು ಪುಟಗಳನ್ನು ಡಿಸ್ಕ್ಗೆ ಡಂಪ್ ಮಾಡಲು ಚೆಕ್ಪಾಯಿಂಟ್ಗಳನ್ನು ಮಾಡುತ್ತದೆ. ನಾವು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಹಂಚಿದ ಮೆಮೊರಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಚೆಕ್ಪಾಯಿಂಟ್ ಡಿಸ್ಕ್ನಲ್ಲಿ ತೀವ್ರವಾದ ಪರಿಣಾಮವನ್ನು ಬೀರಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಈ ಪುಟಗಳನ್ನು fsync ನೊಂದಿಗೆ ಡಂಪ್ ಮಾಡುತ್ತದೆ. ಇದು ಕರ್ನಲ್ ಬಫರ್‌ನಲ್ಲಿ ಬರುತ್ತದೆ ಮತ್ತು fsync ಅನ್ನು ಬಳಸಿಕೊಂಡು ಡಿಸ್ಕ್‌ಗಳಿಗೆ ಬರೆಯಲಾಗುತ್ತದೆ. ಮತ್ತು ಈ ವ್ಯವಹಾರದ ಪ್ರಮಾಣವು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ನಾವು ಅಹಿತಕರ ಪರಿಣಾಮವನ್ನು ಗಮನಿಸಬಹುದು, ಅವುಗಳೆಂದರೆ ಡಿಸ್ಕ್ಗಳ ದೊಡ್ಡ ಬಳಕೆ.
ಇಲ್ಲಿ ನನ್ನ ಬಳಿ ಎರಡು ಚಿತ್ರಗಳಿವೆ. ಅದು ಏನೆಂದು ನಾನು ಈಗ ವಿವರಿಸುತ್ತೇನೆ. ಇವು ಎರಡು ಸಮಯ-ಸಂಬಂಧಿತ ಗ್ರಾಫ್‌ಗಳಾಗಿವೆ. ಮೊದಲ ಗ್ರಾಫ್ ಡಿಸ್ಕ್ ಬಳಕೆಯಾಗಿದೆ. ಇಲ್ಲಿ ಇದು ಈ ಸಮಯದಲ್ಲಿ ಸುಮಾರು 90% ತಲುಪುತ್ತದೆ. ನೀವು ಭೌತಿಕ ಡಿಸ್ಕ್ಗಳೊಂದಿಗೆ ಡೇಟಾಬೇಸ್ ವೈಫಲ್ಯವನ್ನು ಹೊಂದಿದ್ದರೆ, 90% ನಲ್ಲಿ RAID ನಿಯಂತ್ರಕ ಬಳಕೆಯೊಂದಿಗೆ, ಇದು ಕೆಟ್ಟ ಸುದ್ದಿಯಾಗಿದೆ. ಇದರರ್ಥ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಮತ್ತು ಅದು 100 ತಲುಪುತ್ತದೆ ಮತ್ತು I/O ನಿಲ್ಲುತ್ತದೆ.
ನೀವು ಡಿಸ್ಕ್ ರಚನೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಸ್ವಲ್ಪ ವಿಭಿನ್ನ ಕಥೆಯಾಗಿದೆ. ಇದು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ಅದು ಯಾವ ರೀತಿಯ ರಚನೆ, ಇತ್ಯಾದಿಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.
ಮತ್ತು ಸಮಾನಾಂತರವಾಗಿ, ಆಂತರಿಕ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ವೀಕ್ಷಣೆಯಿಂದ ಗ್ರಾಫ್ ಅನ್ನು ಇಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ಇದು ಚೆಕ್ಪಾಯಿಂಟ್ ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಮತ್ತು ಇಲ್ಲಿ ಹಸಿರು ಬಣ್ಣವು ಎಷ್ಟು ಬಫರ್‌ಗಳು, ಈ ಕೊಳಕು ಪುಟಗಳು, ಆ ಕ್ಷಣದಲ್ಲಿ ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ಗಾಗಿ ಈ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗೆ ಬಂದಿವೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಮತ್ತು ಇಲ್ಲಿ ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದ ಮುಖ್ಯ ವಿಷಯ ಇದು. ನಾವು ಇಲ್ಲಿ ಬಹಳಷ್ಟು ಪುಟಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಕೆಲವು ಹಂತದಲ್ಲಿ ನಾವು ಬೋರ್ಡ್ ಅನ್ನು ಹೊಡೆದಿದ್ದೇವೆ, ಅಂದರೆ, ನಾವು ಬರೆದಿದ್ದೇವೆ ಮತ್ತು ಬರೆದಿದ್ದೇವೆ, ಇಲ್ಲಿ ಡಿಸ್ಕ್ ಸಿಸ್ಟಮ್ ಸ್ಪಷ್ಟವಾಗಿ ತುಂಬಾ ಕಾರ್ಯನಿರತವಾಗಿದೆ. ಮತ್ತು ನಮ್ಮ ಚೆಕ್ಪಾಯಿಂಟ್ ಡಿಸ್ಕ್ನಲ್ಲಿ ಬಲವಾದ ಪ್ರಭಾವವನ್ನು ಹೊಂದಿದೆ. ತಾತ್ತ್ವಿಕವಾಗಿ, ಪರಿಸ್ಥಿತಿಯು ಈ ರೀತಿ ಇರಬೇಕು, ಅಂದರೆ ನಾವು ಇಲ್ಲಿ ಕಡಿಮೆ ರೆಕಾರ್ಡಿಂಗ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಅದನ್ನು ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಸರಿಪಡಿಸಬಹುದು ಇದರಿಂದ ಅದು ಹೀಗೆಯೇ ಮುಂದುವರಿಯುತ್ತದೆ. ಅಂದರೆ, ಮರುಬಳಕೆ ಚಿಕ್ಕದಾಗಿದೆ, ಆದರೆ ಎಲ್ಲೋ ನಾವು ಇಲ್ಲಿ ಏನನ್ನಾದರೂ ಬರೆಯುತ್ತಿದ್ದೇವೆ.
ಈ ಸಮಸ್ಯೆಯನ್ನು ಹೋಗಲಾಡಿಸಲು ಏನು ಮಾಡಬೇಕು? ನೀವು ಡೇಟಾಬೇಸ್ ಅಡಿಯಲ್ಲಿ IO ಅನ್ನು ನಿಲ್ಲಿಸಿದ್ದರೆ, ಅವರ ವಿನಂತಿಗಳನ್ನು ಪೂರೈಸಲು ಬಂದ ಎಲ್ಲಾ ಬಳಕೆದಾರರು ಕಾಯುತ್ತಾರೆ ಎಂದರ್ಥ.
ನೀವು Linux ನ ದೃಷ್ಟಿಕೋನದಿಂದ ನೋಡಿದರೆ, ನೀವು ಉತ್ತಮ ಯಂತ್ರಾಂಶವನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಅದನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿ, PostgreSQL ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ ಅದು ಈ ಚೆಕ್ಪಾಯಿಂಟ್ಗಳನ್ನು ಕಡಿಮೆ ಬಾರಿ ಮಾಡುತ್ತದೆ, ಕಾಲಾನಂತರದಲ್ಲಿ ಅವುಗಳನ್ನು ಪರಸ್ಪರ ಹರಡುತ್ತದೆ, ನಂತರ ನೀವು ಡೀಫಾಲ್ಟ್ ಡೆಬಿಯನ್ ನಿಯತಾಂಕಗಳಿಗೆ ಹೆಜ್ಜೆ ಹಾಕುತ್ತೀರಿ. ಹೆಚ್ಚಿನ Linux ವಿತರಣೆಗಳಿಗೆ, ಇದು ಚಿತ್ರ: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
ಅದರ ಅರ್ಥವೇನು? ಕರ್ನಲ್ 2.6 ರಿಂದ ಒಂದು ಫ್ಲಶಿಂಗ್ ರಾಕ್ಷಸ ಕಾಣಿಸಿಕೊಂಡಿತು. Pdglush, ಯಾರು ಬಳಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ಇದು ಕರ್ನಲ್ ಬಫರ್‌ನಿಂದ ಕೊಳಕು ಪುಟಗಳನ್ನು ಹಿನ್ನಲೆಯಲ್ಲಿ ತಿರಸ್ಕರಿಸುವಲ್ಲಿ ತೊಡಗಿದೆ ಮತ್ತು ಕೊಳಕು ಪುಟಗಳನ್ನು ತಿರಸ್ಕರಿಸುವುದು ಅಗತ್ಯವಿದ್ದಾಗ, ಬ್ಯಾಕ್‌ಗ್ರೌಂಡ್ ತಿರಸ್ಕರಿಸುವುದು ಸಹಾಯ ಮಾಡದಿದ್ದಾಗ.
ಹಿನ್ನೆಲೆ ಯಾವಾಗ ಬರುತ್ತದೆ? ಸರ್ವರ್‌ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ಒಟ್ಟು RAM ನ 10% ಕರ್ನಲ್ ಬಫರ್‌ನಲ್ಲಿ ಕೊಳಕು ಪುಟಗಳಿಂದ ಆಕ್ರಮಿಸಿಕೊಂಡಾಗ, ವಿಶೇಷ ಬರಹ-ಆಫ್ ಕಾರ್ಯವನ್ನು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಕರೆಯಲಾಗುತ್ತದೆ. ಇದು ಏಕೆ ಹಿನ್ನೆಲೆ? ಪ್ಯಾರಾಮೀಟರ್ ಆಗಿ, ಎಷ್ಟು ಪುಟಗಳನ್ನು ಬರೆಯಬೇಕೆಂದು ಇದು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತು, ಅವರು N ಪುಟಗಳನ್ನು ಬರೆಯುತ್ತಾರೆ ಎಂದು ಹೇಳೋಣ. ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಈ ವಿಷಯವು ನಿದ್ರಿಸುತ್ತದೆ. ತದನಂತರ ಅವಳು ಮತ್ತೆ ಬಂದು ಇನ್ನೂ ಕೆಲವು ಪುಟಗಳನ್ನು ನಕಲಿಸುತ್ತಾಳೆ.
ಇದು ಅತ್ಯಂತ ಸರಳವಾದ ಕಥೆ. ಇಲ್ಲಿ ಸಮಸ್ಯೆ ಈಜುಕೊಳದಂತೆಯೇ ಇದೆ, ಅದು ಒಂದು ಪೈಪ್ನಲ್ಲಿ ಸುರಿಯುವಾಗ, ಅದು ಇನ್ನೊಂದಕ್ಕೆ ಹರಿಯುತ್ತದೆ. ನಮ್ಮ ಚೆಕ್ಪಾಯಿಂಟ್ ಆಗಮಿಸಿದೆ ಮತ್ತು ಅದನ್ನು ತಿರಸ್ಕರಿಸಲು ಕೆಲವು ಕೊಳಕು ಪುಟಗಳನ್ನು ಕಳುಹಿಸಿದರೆ, ನಂತರ ಕ್ರಮೇಣ ಇಡೀ ವಿಷಯವನ್ನು ಕರ್ನಲ್ ಬಫರ್ pgflush ನಿಂದ ಅಂದವಾಗಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ.
ಈ ಕೊಳಕು ಪುಟಗಳು ಸಂಗ್ರಹವಾಗುವುದನ್ನು ಮುಂದುವರೆಸಿದರೆ, ಅವು 20% ವರೆಗೆ ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತವೆ, ಅದರ ನಂತರ OS ಆದ್ಯತೆಯು ಸಂಪೂರ್ಣ ವಿಷಯವನ್ನು ಡಿಸ್ಕ್ಗೆ ಬರೆಯುವುದು, ಏಕೆಂದರೆ ವಿದ್ಯುತ್ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವೂ ನಮಗೆ ಕೆಟ್ಟದಾಗಿರುತ್ತದೆ. ನಾವು ಈ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ.
ಏನಿದು ಉಪಾಯ? ಟ್ರಿಕ್ ಏನೆಂದರೆ, ಆಧುನಿಕ ಜಗತ್ತಿನಲ್ಲಿ ಈ ನಿಯತಾಂಕಗಳು ಯಂತ್ರದಲ್ಲಿರುವ ಒಟ್ಟು RAM ನ 20 ಮತ್ತು 10% ಆಗಿದ್ದು, ನೀವು ಹೊಂದಿರುವ ಯಾವುದೇ ಡಿಸ್ಕ್ ಸಿಸ್ಟಮ್ನ ಥ್ರೋಪುಟ್ ವಿಷಯದಲ್ಲಿ ಅವು ಸಂಪೂರ್ಣವಾಗಿ ದೈತ್ಯಾಕಾರದವುಗಳಾಗಿವೆ.
ನೀವು 128 GB RAM ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ ಡಿಸ್ಕ್ ಸಿಸ್ಟಂನಲ್ಲಿ 12,8 GB ಬರುತ್ತದೆ. ಮತ್ತು ನೀವು ಅಲ್ಲಿ ಯಾವುದೇ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿದ್ದರೂ, ನೀವು ಅಲ್ಲಿ ಯಾವುದೇ ಶ್ರೇಣಿಯನ್ನು ಹೊಂದಿದ್ದರೂ, ಅವು ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ, ನಿಮ್ಮ RAID ನಿಯಂತ್ರಕದ ಸಾಮರ್ಥ್ಯಗಳ ಆಧಾರದ ಮೇಲೆ ನೀವು ತಕ್ಷಣ ಈ ಸಂಖ್ಯೆಗಳನ್ನು ಹೊಂದಿಸಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. 512 MB ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿರುವ ನಿಯಂತ್ರಕಕ್ಕಾಗಿ ನಾನು ತಕ್ಷಣವೇ ಇಲ್ಲಿ ಶಿಫಾರಸು ಮಾಡಿದ್ದೇನೆ.
ಎಲ್ಲವನ್ನೂ ತುಂಬಾ ಸರಳವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ನೀವು vm.dirty_background ಅನ್ನು ಬೈಟ್‌ಗಳಲ್ಲಿ ಹಾಕಬಹುದು. ಮತ್ತು ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಹಿಂದಿನ ಎರಡನ್ನು ರದ್ದುಗೊಳಿಸುತ್ತವೆ. ಅನುಪಾತವು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿರುತ್ತದೆ, ಅಥವಾ ಬೈಟ್‌ಗಳನ್ನು ಹೊಂದಿರುವವುಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ, ನಂತರ ಬೈಟ್‌ಗಳನ್ನು ಹೊಂದಿರುವವರು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ. ಆದರೆ ನಾನು ಡಿಬಿಎ ಸಲಹೆಗಾರನಾಗಿರುವುದರಿಂದ ಮತ್ತು ವಿಭಿನ್ನ ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದರಿಂದ, ನಾನು ಸ್ಟ್ರಾಗಳನ್ನು ಸೆಳೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ ಮತ್ತು ಆದ್ದರಿಂದ, ಬೈಟ್‌ಗಳಲ್ಲಿದ್ದರೆ, ಬೈಟ್‌ಗಳಲ್ಲಿ. ಉತ್ತಮ ನಿರ್ವಾಹಕರು ಸರ್ವರ್‌ಗೆ ಹೆಚ್ಚಿನ ಮೆಮೊರಿಯನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ, ಅದನ್ನು ರೀಬೂಟ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅಂಕಿ ಒಂದೇ ಆಗಿರುತ್ತದೆ ಎಂದು ಯಾರೂ ಯಾವುದೇ ಗ್ಯಾರಂಟಿ ನೀಡಲಿಲ್ಲ. ಈ ಸಂಖ್ಯೆಗಳನ್ನು ಲೆಕ್ಕಹಾಕಿ ಇದರಿಂದ ಎಲ್ಲವೂ ಗ್ಯಾರಂಟಿಯೊಂದಿಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ.
ನೀವು ಹೊಂದಿಕೊಳ್ಳದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ? ಯಾವುದೇ ಫ್ಲಶಿಂಗ್ ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿಲ್ಲಿಸಲಾಗಿದೆ ಎಂದು ನಾನು ಬರೆದಿದ್ದೇನೆ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಇದು ಮಾತಿನ ಚಿತ್ರವಾಗಿದೆ. ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ದೊಡ್ಡ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ - ಇದು ಬಹಳಷ್ಟು ಕೊಳಕು ಪುಟಗಳನ್ನು ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಗ್ರಾಹಕರು ಉತ್ಪಾದಿಸುವ IO ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿಲ್ಲಿಸಲಾಗಿದೆ, ಅಂದರೆ ಡೇಟಾಬೇಸ್ಗೆ sql ಪ್ರಶ್ನೆಯನ್ನು ಕಳುಹಿಸಲು ಅಪ್ಲಿಕೇಶನ್ ಬಂದಿದೆ, ಅದು ಕಾಯುತ್ತಿದೆ. ಅದಕ್ಕೆ ಯಾವುದೇ ಇನ್ಪುಟ್/ಔಟ್ಪುಟ್ ಕಡಿಮೆ ಆದ್ಯತೆಯಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಡೇಟಾಬೇಸ್ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ನಿಂದ ಆಕ್ರಮಿಸಲ್ಪಟ್ಟಿದೆ. ಮತ್ತು ಅವಳು ಯಾವಾಗ ಮುಗಿಸುತ್ತಾಳೆ ಎಂಬುದು ಸಂಪೂರ್ಣವಾಗಿ ಅಸ್ಪಷ್ಟವಾಗಿದೆ. ಮತ್ತು ನೀವು ಹಿನ್ನೆಲೆ ಅಲ್ಲದ ಫ್ಲಶಿಂಗ್ ಅನ್ನು ಸಾಧಿಸಿದಾಗ, ನಿಮ್ಮ ಎಲ್ಲಾ IO ಅದನ್ನು ಆಕ್ರಮಿಸಿಕೊಂಡಿದೆ ಎಂದರ್ಥ. ಮತ್ತು ಅದು ಮುಗಿಯುವವರೆಗೆ, ನೀವು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.
ಈ ವರದಿಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿದ ಇನ್ನೂ ಎರಡು ಪ್ರಮುಖ ಅಂಶಗಳಿವೆ. ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳು postgresql.conf ನಲ್ಲಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು, ಅಂದರೆ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳ ಸೆಟ್ಟಿಂಗ್‌ಗಳು. ಮತ್ತು ನಿಮ್ಮ ಡಿಸ್ಕ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸಮರ್ಪಕವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು. ನೀವು RAID ನಲ್ಲಿ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಬ್ಯಾಟರಿಯನ್ನು ಹೊಂದಿರಬೇಕು. ಜನರು ಬ್ಯಾಟರಿ ಇಲ್ಲದೆ ಉತ್ತಮ ಸಂಗ್ರಹದೊಂದಿಗೆ RAID ಅನ್ನು ಖರೀದಿಸುತ್ತಾರೆ. ನೀವು RAID ನಲ್ಲಿ SSD ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅವು ಸರ್ವರ್ ಆಗಿರಬೇಕು, ಅಲ್ಲಿ ಕೆಪಾಸಿಟರ್‌ಗಳು ಇರಬೇಕು. ವಿವರವಾದ ಪರಿಶೀಲನಾಪಟ್ಟಿ ಇಲ್ಲಿದೆ. PostgreSQL ನಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಡಿಸ್ಕ್ ಅನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ನನ್ನ ವರದಿಯನ್ನು ಈ ಲಿಂಕ್ ಒಳಗೊಂಡಿದೆ. ಅಲ್ಲಿ ಈ ಎಲ್ಲಾ ಚೆಕ್‌ಲಿಸ್ಟ್‌ಗಳಿವೆ.
ಇನ್ನೇನು ಜೀವನವನ್ನು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿಸಬಹುದು? ಇವು ಎರಡು ನಿಯತಾಂಕಗಳಾಗಿವೆ. ಅವು ತುಲನಾತ್ಮಕವಾಗಿ ಹೊಸದು. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಅವುಗಳನ್ನು ವಿವಿಧ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಸೇರಿಸಬಹುದು. ಮತ್ತು ಅವರು ತಪ್ಪಾಗಿ ಆನ್ ಮಾಡಿದರೆ ಅವರು ಜೀವನವನ್ನು ಕಷ್ಟಕರವಾಗಿಸಬಹುದು.
ತುಲನಾತ್ಮಕವಾಗಿ ಎರಡು ಹೊಸ ವಿಷಯಗಳಿವೆ. ಅವರು ಈಗಾಗಲೇ ಮೂರನೇ ಕೋರ್ಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿದ್ದಾರೆ. ಇದು ನ್ಯಾನೊಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ sched_migration_cost ಮತ್ತು sched_autogroup_enabled ಆಗಿದೆ, ಇದು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಒಂದಾಗಿದೆ.
ಮತ್ತು ಅವರು ನಿಮ್ಮ ಜೀವನವನ್ನು ಹೇಗೆ ಹಾಳುಮಾಡುತ್ತಾರೆ? ನಿಗದಿತ_ವಲಸೆ_ವೆಚ್ಚ ಎಂದರೇನು? Linux ನಲ್ಲಿ, ಶೆಡ್ಯೂಲರ್ ಒಂದು CPU ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ಥಳಾಂತರಿಸಬಹುದು. ಮತ್ತು ಪ್ರಶ್ನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ PostgreSQL ಗಾಗಿ, ಮತ್ತೊಂದು CPU ಗೆ ವಲಸೆ ಹೋಗುವುದು ಸಂಪೂರ್ಣವಾಗಿ ಅಸ್ಪಷ್ಟವಾಗಿದೆ. ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ದೃಷ್ಟಿಕೋನದಿಂದ, ನೀವು ಓಪನ್ ಆಫೀಸ್ ಮತ್ತು ಟರ್ಮಿನಲ್ ನಡುವೆ ವಿಂಡೋಗಳನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಇದು ಒಳ್ಳೆಯದು, ಆದರೆ ಡೇಟಾಬೇಸ್ಗೆ ಇದು ತುಂಬಾ ಕೆಟ್ಟದಾಗಿದೆ. ಆದ್ದರಿಂದ, ಒಂದು ಸಮಂಜಸವಾದ ನೀತಿಯು migration_cost ಅನ್ನು ಕೆಲವು ದೊಡ್ಡ ಮೌಲ್ಯಕ್ಕೆ ಹೊಂದಿಸುವುದು, ಕನಿಷ್ಠ ಹಲವಾರು ಸಾವಿರ ನ್ಯಾನೋಸೆಕೆಂಡ್‌ಗಳು.
ಶೆಡ್ಯೂಲರ್‌ಗೆ ಇದರ ಅರ್ಥವೇನು? ಈ ಸಮಯದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯು ಇನ್ನೂ ಬಿಸಿಯಾಗಿರುತ್ತದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಅಂದರೆ, ನೀವು ದೀರ್ಘಕಾಲದವರೆಗೆ ಏನನ್ನಾದರೂ ಮಾಡುತ್ತಿರುವ ದೀರ್ಘಾವಧಿಯ ವಹಿವಾಟನ್ನು ಹೊಂದಿದ್ದರೆ, ಶೆಡ್ಯೂಲರ್ ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಈ ಸಮಯ ಮೀರುವವರೆಗೆ, ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಎಲ್ಲಿಯೂ ಸ್ಥಳಾಂತರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಅವರು ಊಹಿಸುತ್ತಾರೆ. ಅದೇ ಸಮಯದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯು ಏನನ್ನಾದರೂ ಮಾಡಿದರೆ, ಅದನ್ನು ಎಲ್ಲಿಯೂ ಸ್ಥಳಾಂತರಿಸಲಾಗುವುದಿಲ್ಲ, ಅದು ಅದಕ್ಕೆ ನಿಯೋಜಿಸಲಾದ CPU ನಲ್ಲಿ ಸದ್ದಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ಫಲಿತಾಂಶವು ಅತ್ಯುತ್ತಮವಾಗಿದೆ.
ಎರಡನೆಯ ಅಂಶವೆಂದರೆ ಆಟೋಗ್ರೂಪ್. ಆಧುನಿಕ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸದ ನಿರ್ದಿಷ್ಟ ಕೆಲಸದ ಹೊರೆಗಳಿಗೆ ಉತ್ತಮ ಕಲ್ಪನೆ ಇದೆ - ಇದು ವರ್ಚುವಲ್ ಟರ್ಮಿನಲ್ ಮೂಲಕ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಗುಂಪು ಮಾಡುವುದು. ಕೆಲವು ಕಾರ್ಯಗಳಿಗೆ ಇದು ಅನುಕೂಲಕರವಾಗಿದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, PostgreSQL ಒಂದು ಟರ್ಮಿನಲ್‌ನಿಂದ ಚಲಿಸುವ ಪ್ರಿಫೋರ್ಕ್‌ನೊಂದಿಗೆ ಬಹು-ಪ್ರಕ್ರಿಯೆ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ನೀವು ಲಾಕ್ ರೈಟರ್, ಚೆಕ್ಪಾಯಿಂಟ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ನಿಮ್ಮ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ಪ್ರತಿ CPU ಗೆ ಒಂದು ಶೆಡ್ಯೂಲರ್ ಆಗಿ ಗುಂಪು ಮಾಡಲಾಗುತ್ತದೆ. ಮತ್ತು ಒಬ್ಬರಿಗೊಬ್ಬರು ಮಧ್ಯಪ್ರವೇಶಿಸಲು ಮತ್ತು ಅವನನ್ನು ಹೆಚ್ಚು ಕಾಲ ಆಕ್ರಮಿಸಿಕೊಳ್ಳಲು ಅವರು ಮುಕ್ತರಾಗಲು ಅವರು ಅಲ್ಲಿ ಒಗ್ಗಟ್ಟಿನಿಂದ ಕಾಯುತ್ತಾರೆ. ಅಂತಹ ಹೊರೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಅನಗತ್ಯವಾದ ಕಥೆಯಾಗಿದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಅದನ್ನು ಆಫ್ ಮಾಡಬೇಕಾಗಿದೆ.
ನನ್ನ ಸಹೋದ್ಯೋಗಿ ಅಲೆಕ್ಸಿ ಲೆಸೊವ್ಸ್ಕಿ ಅವರು ಸರಳವಾದ pgbench ನೊಂದಿಗೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಮಾಡಿದರು, ಅಲ್ಲಿ ಅವರು ಪ್ರಮಾಣದ ಕ್ರಮದಿಂದ ವಲಸೆ_ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸಿದರು ಮತ್ತು ಆಟೋಗ್ರೂಪ್ ಅನ್ನು ಆಫ್ ಮಾಡಿದರು. ಕೆಟ್ಟ ಯಂತ್ರಾಂಶದಲ್ಲಿನ ವ್ಯತ್ಯಾಸವು ಸುಮಾರು 10% ಆಗಿತ್ತು. ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಮೇಲಿಂಗ್ ಪಟ್ಟಿಯಲ್ಲಿ ಚರ್ಚೆ ಇದೆ, ಅಲ್ಲಿ ಜನರು ಪ್ರಶ್ನೆಯ ವೇಗಕ್ಕೆ ಇದೇ ರೀತಿಯ ಬದಲಾವಣೆಗಳ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತಾರೆ ಪ್ರಭಾವಿತ 50%. ಅಂತಹ ಕಥೆಗಳು ಸಾಕಷ್ಟು ಇವೆ.
ಮತ್ತು ಅಂತಿಮವಾಗಿ, ವಿದ್ಯುತ್ ಉಳಿತಾಯ ನೀತಿಯ ಬಗ್ಗೆ. ಲಿನಕ್ಸ್ ಅನ್ನು ಈಗ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಬಳಸಬಹುದು ಎಂಬುದು ಒಳ್ಳೆಯದು. ಮತ್ತು ಇದು ಬ್ಯಾಟರಿಯನ್ನು ಚೆನ್ನಾಗಿ ಬಳಸುತ್ತದೆ. ಆದರೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಇದು ಸರ್ವರ್‌ನಲ್ಲಿಯೂ ಸಂಭವಿಸಬಹುದು ಎಂದು ತಿರುಗುತ್ತದೆ.
ಇದಲ್ಲದೆ, ನೀವು ಕೆಲವು ಹೋಸ್ಟರ್‌ಗಳಿಂದ ಸರ್ವರ್‌ಗಳನ್ನು ಬಾಡಿಗೆಗೆ ಪಡೆದರೆ, ನೀವು ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು "ಉತ್ತಮ" ಹೋಸ್ಟರ್‌ಗಳು ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ. ಕಬ್ಬಿಣವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಿಕೊಳ್ಳುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅವರ ಕಾರ್ಯವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅವರು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನಲ್ಲಿ ಲ್ಯಾಪ್ಟಾಪ್ ವಿದ್ಯುತ್ ಉಳಿತಾಯ ಮೋಡ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು.
ಹೆಚ್ಚಿನ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಹೊಂದಿರುವ ಸರ್ವರ್‌ನಲ್ಲಿ ನೀವು ಈ ವಿಷಯವನ್ನು ಬಳಸಿದರೆ, ನಿಮ್ಮ ಆಯ್ಕೆಯು acpi_cpufreq + permormance ಆಗಿದೆ. ಬೇಡಿಕೆಯೊಂದಿಗೆ ಸಹ ಸಮಸ್ಯೆಗಳಿರುತ್ತವೆ.
Intel_pstate ಸ್ವಲ್ಪ ವಿಭಿನ್ನ ಚಾಲಕವಾಗಿದೆ. ಮತ್ತು ಈಗ ಇದಕ್ಕೆ ಆದ್ಯತೆ ನೀಡಲಾಗಿದೆ, ಏಕೆಂದರೆ ಅದು ನಂತರ ಮತ್ತು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ಗವರ್ನರ್ ಕಾರ್ಯಕ್ಷಮತೆ ಮಾತ್ರ. Ondemand, powersave ಮತ್ತು ಎಲ್ಲವೂ ನಿಮ್ಮ ಬಗ್ಗೆ ಅಲ್ಲ.
ನೀವು ಪವರ್‌ಸೇವ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ PostgreSQL ಅನ್ನು ವಿವರಿಸುವ ವಿಶ್ಲೇಷಣೆಯ ಫಲಿತಾಂಶಗಳು ಪರಿಮಾಣದ ಹಲವಾರು ಆದೇಶಗಳಿಂದ ಭಿನ್ನವಾಗಿರಬಹುದು, ಏಕೆಂದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅಡಿಯಲ್ಲಿ CPU ಸಂಪೂರ್ಣವಾಗಿ ಅನಿರೀಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಈ ಐಟಂಗಳನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸೇರಿಸಿಕೊಳ್ಳಬಹುದು. ಅವರು ಅದನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಆನ್ ಮಾಡಿದ್ದಾರೆಯೇ ಎಂದು ನೋಡಲು ಎಚ್ಚರಿಕೆಯಿಂದ ನೋಡಿ. ಇದು ನಿಜವಾಗಿಯೂ ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಗಿರಬಹುದು.
ಮತ್ತು ಕೊನೆಯಲ್ಲಿ, ಪ್ರತಿದಿನ ಈ ವಿಷಯದಲ್ಲಿ ಮುನ್ನಡೆಯುತ್ತಿರುವ ನಮ್ಮ PosgreSQL- ಕನ್ಸಲ್ಟಿಂಗ್ DBA ತಂಡದ ಹುಡುಗರಿಗೆ, ಅಂದರೆ ಮ್ಯಾಕ್ಸ್ ಬೊಗುಕ್ ಮತ್ತು ಅಲೆಕ್ಸಿ ಲೆಸೊವ್ಸ್ಕಿಗೆ ನಾನು ಧನ್ಯವಾದ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ಮತ್ತು ನಮ್ಮ ಗ್ರಾಹಕರಿಗೆ ನಮ್ಮಿಂದ ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ತಮವಾಗಿ ಮಾಡಲು ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ ಇದರಿಂದ ಅದು ಅವರಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಇದು ವಾಯುಯಾನ ಸುರಕ್ಷತೆ ಸೂಚನೆಗಳಂತೆ. ಇಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ರಕ್ತದಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಈ ಪ್ರತಿಯೊಂದು ಬೀಜಗಳು ಕೆಲವು ರೀತಿಯ ಸಮಸ್ಯೆಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕಂಡುಬರುತ್ತವೆ. ಅವುಗಳನ್ನು ನಿಮ್ಮೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲು ನನಗೆ ಸಂತೋಷವಾಗಿದೆ.
ಪ್ರಶ್ನೆಗಳು:
ಧನ್ಯವಾದ! ಉದಾಹರಣೆಗೆ, ಕಂಪನಿಯು ಹಣವನ್ನು ಉಳಿಸಲು ಮತ್ತು ಡೇಟಾಬೇಸ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಲಾಜಿಕ್ ಅನ್ನು ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿ ಇರಿಸಲು ಬಯಸಿದರೆ ಅಥವಾ ಕಂಪನಿಯು ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳ ಫ್ಯಾಶನ್ ಪ್ರವೃತ್ತಿಯನ್ನು ಅನುಸರಿಸಿದರೆ, ಇದರಲ್ಲಿ PostgreSQL ಕಂಟೇನರ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಏನಿದು ಉಪಾಯ? Sysctl ಜಾಗತಿಕವಾಗಿ ಸಂಪೂರ್ಣ ಕರ್ನಲ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. sysctls ಅನ್ನು ಹೇಗಾದರೂ ವರ್ಚುವಲೈಸ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ನಾನು ಕೇಳಿಲ್ಲ, ಇದರಿಂದ ಅವು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಕೇವಲ ಒಂದು cgroup ಇದೆ ಮತ್ತು ಅಲ್ಲಿ ನಿಯಂತ್ರಣದ ಭಾಗ ಮಾತ್ರ ಇರುತ್ತದೆ. ಇದರೊಂದಿಗೆ ನೀವು ಹೇಗೆ ಬದುಕಬಹುದು? ಅಥವಾ ನೀವು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಬಯಸಿದರೆ, ಪ್ರತ್ಯೇಕ ಹಾರ್ಡ್ವೇರ್ ಸರ್ವರ್‌ನಲ್ಲಿ PostgreSQL ಅನ್ನು ರನ್ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಟ್ಯೂನ್ ಮಾಡುವುದೇ?
ನಿಮ್ಮ ಪ್ರಶ್ನೆಗೆ ನಾವು ಸುಮಾರು ಮೂರು ರೀತಿಯಲ್ಲಿ ಉತ್ತರಿಸಿದ್ದೇವೆ. ನಾವು ಟ್ಯೂನ್ ಮಾಡಬಹುದಾದ ಹಾರ್ಡ್ವೇರ್ ಸರ್ವರ್ ಬಗ್ಗೆ ಮಾತನಾಡದಿದ್ದರೆ, ವಿಶ್ರಾಂತಿ ಪಡೆಯಿರಿ, ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಲ್ಲದೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು ಈ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಮಾಡಬೇಕಾದ ಅಂತಹ ಲೋಡ್ ಅನ್ನು ನೀವು ಹೊಂದಿದ್ದರೆ, ನಂತರ ನೀವು ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗಿಂತ ಮುಂಚೆಯೇ ಕಬ್ಬಿಣದ ಸರ್ವರ್‌ಗೆ ಬರುತ್ತೀರಿ.
ಸಮಸ್ಯೆ ಏನು? ಇದು ವರ್ಚುವಲ್ ಯಂತ್ರವಾಗಿದ್ದರೆ, ಹೆಚ್ಚಾಗಿ ನೀವು ಅನೇಕ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಹೆಚ್ಚಿನ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಲ್ಲಿ ಡಿಸ್ಕ್ನ ಸುಪ್ತತೆಯು ಸಾಕಷ್ಟು ಅಸಮಂಜಸವಾಗಿದೆ. ಡಿಸ್ಕ್ ಥ್ರೋಪುಟ್ ಉತ್ತಮವಾಗಿದ್ದರೂ ಸಹ, ಒಂದು ವಿಫಲವಾದ I/O ವಹಿವಾಟು ಚೆಕ್ಪಾಯಿಂಟ್ ಸಮಯದಲ್ಲಿ ಅಥವಾ WAL ಗೆ ಬರೆಯುವ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸಿದ ಸರಾಸರಿ ಥ್ರೋಪುಟ್ ಅನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ, ಆಗ ಡೇಟಾಬೇಸ್ ಇದರಿಂದ ಹೆಚ್ಚು ಹಾನಿಯಾಗುತ್ತದೆ. ಮತ್ತು ನೀವು ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುವ ಮೊದಲು ನೀವು ಇದನ್ನು ಗಮನಿಸಬಹುದು.
ನೀವು ಅದೇ ಸರ್ವರ್‌ನಲ್ಲಿ NGINX ಹೊಂದಿದ್ದರೆ, ನೀವು ಸಹ ಅದೇ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಅವರು ಹಂಚಿಕೊಂಡ ಸ್ಮರಣೆಗಾಗಿ ಹೋರಾಡುತ್ತಾರೆ. ಮತ್ತು ಇಲ್ಲಿ ವಿವರಿಸಿದ ಸಮಸ್ಯೆಗಳಿಗೆ ನೀವು ಹೋಗುವುದಿಲ್ಲ.
ಆದರೆ ಮತ್ತೊಂದೆಡೆ, ಈ ಕೆಲವು ನಿಯತಾಂಕಗಳು ನಿಮಗೆ ಇನ್ನೂ ಪ್ರಸ್ತುತವಾಗುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, sysctl ನೊಂದಿಗೆ dirty_ratio ಅನ್ನು ಹೊಂದಿಸಿ ಇದರಿಂದ ಅದು ತುಂಬಾ ಹುಚ್ಚವಾಗಿರುವುದಿಲ್ಲ - ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ, ನೀವು ಡಿಸ್ಕ್ನೊಂದಿಗೆ ಸಂವಹನವನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಮತ್ತು ಇದು ತಪ್ಪು ಮಾದರಿಯ ಪ್ರಕಾರ ಇರುತ್ತದೆ. ನಾನು ತೋರಿಸಿದ ನಿಯತಾಂಕಗಳಿಗೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ. ಮತ್ತು ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಅವುಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಉತ್ತಮ.
ಆದರೆ NUMA ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿರಬಹುದು. ಉದಾಹರಣೆಗೆ, VmWare, NUMA ಜೊತೆಗೆ ನಿಖರವಾಗಿ ವಿರುದ್ಧವಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ಇಲ್ಲಿ ನೀವು ಆರಿಸಬೇಕಾಗುತ್ತದೆ - ಕಬ್ಬಿಣದ ಸರ್ವರ್ ಅಥವಾ ಕಬ್ಬಿಣವಲ್ಲದ ಒಂದು.
ನಾನು Amazon AWS ಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಶ್ನೆಯನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಅವರು ಚಿತ್ರಗಳನ್ನು ಮೊದಲೇ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದಾರೆ. ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಅಮೆಜಾನ್ ಆರ್ಡಿಎಸ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಅವರ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗೆ ಯಾವುದೇ ಕಸ್ಟಮ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆಯೇ?
ಅಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆ, ಆದರೆ ಅವು ವಿಭಿನ್ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳಾಗಿವೆ. ಡೇಟಾಬೇಸ್ ಈ ವಿಷಯವನ್ನು ಹೇಗೆ ಬಳಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಇಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಈಗ ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ನಿಯತಾಂಕಗಳಿವೆ, ಉದಾಹರಣೆಗೆ ರೂಪಿಸುವುದು. ಅಂದರೆ, ನಮಗೆ ಹಲವಾರು ಸಂಪನ್ಮೂಲಗಳು ಬೇಕಾಗುತ್ತವೆ, ನಾವು ಈಗ ಅವುಗಳನ್ನು ತಿನ್ನುತ್ತೇವೆ. ಇದರ ನಂತರ, ಅಮೆಜಾನ್ RDS ಈ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಿಗಿಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯು ಅಲ್ಲಿ ಇಳಿಯುತ್ತದೆ. ಈ ವಿಷಯದಲ್ಲಿ ಜನರು ಹೇಗೆ ಗೊಂದಲಕ್ಕೊಳಗಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಕಥೆಗಳಿವೆ. ಕೆಲವೊಮ್ಮೆ ಸಾಕಷ್ಟು ಯಶಸ್ವಿಯಾಗಿ. ಆದರೆ ಓಎಸ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಇದಕ್ಕೂ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ. ಇದು ಮೋಡವನ್ನು ಹ್ಯಾಕ್ ಮಾಡಿದಂತಿದೆ. ಅದೊಂದು ಬೇರೆ ಕಥೆ.
ಬೃಹತ್ TLB ಗೆ ಹೋಲಿಸಿದರೆ ಪಾರದರ್ಶಕ ಬೃಹತ್ ಪುಟಗಳು ಏಕೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ?
ಕೊಡಬೇಡ. ಇದನ್ನು ಹಲವು ವಿಧಗಳಲ್ಲಿ ವಿವರಿಸಬಹುದು. ಆದರೆ ವಾಸ್ತವವಾಗಿ ಅವರು ಅದನ್ನು ಸರಳವಾಗಿ ನೀಡುವುದಿಲ್ಲ. PostgreSQL ನ ಇತಿಹಾಸವೇನು? ಪ್ರಾರಂಭದಲ್ಲಿ, ಇದು ಹಂಚಿದ ಮೆಮೊರಿಯ ದೊಡ್ಡ ಭಾಗವನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಅವು ಪಾರದರ್ಶಕವೋ ಇಲ್ಲವೋ ಎಂಬುದು ಸಂಪೂರ್ಣವಾಗಿ ಅಪ್ರಸ್ತುತ. ಅವರು ಆರಂಭದಲ್ಲಿ ಎದ್ದು ಕಾಣುವ ಅಂಶವು ಎಲ್ಲವನ್ನೂ ವಿವರಿಸುತ್ತದೆ. ಮತ್ತು ಸಾಕಷ್ಟು ಮೆಮೊರಿ ಇದ್ದರೆ ಮತ್ತು ನೀವು ಹಂಚಿಕೊಂಡ_ಮೆಮೊರಿ ವಿಭಾಗವನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಬೇಕಾದರೆ, ಪಾರದರ್ಶಕ ಬೃಹತ್ ಪುಟಗಳು ಪ್ರಸ್ತುತವಾಗುತ್ತವೆ. PostgreSQL ನಲ್ಲಿ, ಪ್ರಾರಂಭದಲ್ಲಿ ಅದನ್ನು ಸರಳವಾಗಿ ಒಂದು ದೊಡ್ಡ ಭಾಗದಲ್ಲಿ ಹಂಚಲಾಗುತ್ತದೆ ಮತ್ತು ಅದು ಅಷ್ಟೆ, ಮತ್ತು ನಂತರ ಅಲ್ಲಿ ವಿಶೇಷ ಏನೂ ಸಂಭವಿಸುವುದಿಲ್ಲ. ನೀವು ಸಹಜವಾಗಿ, ಇದನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ಅದು ಏನನ್ನಾದರೂ ಮರು-ಹಂಚಿಕೆ ಮಾಡಿದಾಗ ಹಂಚಿಕೆ_ಮೆಮೊರಿಯ ಭ್ರಷ್ಟಾಚಾರವನ್ನು ಪಡೆಯುವ ಅವಕಾಶವಿದೆ. PostgreSQL ಗೆ ಇದರ ಬಗ್ಗೆ ತಿಳಿದಿಲ್ಲ.
ಮೂಲ: www.habr.com