ಅಲೆಕ್ಸಿ ಲೆಸೊವ್ಸ್ಕಿಯವರ 2015 ರ ವರದಿಯ ಪ್ರತಿಲೇಖನ "ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್ ಆಂತರಿಕ ಅಂಕಿಅಂಶಗಳಿಗೆ ಆಳವಾದ ಧುಮುಕುವುದು"
ವರದಿಯ ಲೇಖಕರಿಂದ ಹಕ್ಕು ನಿರಾಕರಣೆ: ಈ ವರದಿಯು ನವೆಂಬರ್ 2015 ರ ದಿನಾಂಕವಾಗಿದೆ ಎಂದು ನಾನು ಗಮನಿಸುತ್ತೇನೆ - 4 ವರ್ಷಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಳೆದಿದೆ ಮತ್ತು ಸಾಕಷ್ಟು ಸಮಯ ಕಳೆದಿದೆ. ವರದಿಯಲ್ಲಿ ಚರ್ಚಿಸಲಾದ ಆವೃತ್ತಿ 9.4 ಅನ್ನು ಇನ್ನು ಮುಂದೆ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಕಳೆದ 4 ವರ್ಷಗಳಲ್ಲಿ, 5 ಹೊಸ ಬಿಡುಗಡೆಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗಿದೆ, ಇದರಲ್ಲಿ ಸಾಕಷ್ಟು ಆವಿಷ್ಕಾರಗಳು, ಸುಧಾರಣೆಗಳು ಮತ್ತು ಅಂಕಿಅಂಶಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಬದಲಾವಣೆಗಳು ಕಾಣಿಸಿಕೊಂಡಿವೆ ಮತ್ತು ಕೆಲವು ವಸ್ತುಗಳು ಹಳೆಯದಾಗಿದೆ ಮತ್ತು ಪ್ರಸ್ತುತವಲ್ಲ. ನಾನು ಪರಿಶೀಲಿಸಿದಂತೆ, ಓದುಗರನ್ನು ತಪ್ಪುದಾರಿಗೆ ಎಳೆಯದಂತೆ ನಾನು ಈ ಸ್ಥಳಗಳನ್ನು ಗುರುತಿಸಲು ಪ್ರಯತ್ನಿಸಿದೆ. ನಾನು ಈ ಸ್ಥಳಗಳನ್ನು ಪುನಃ ಬರೆಯಲಿಲ್ಲ, ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಇವೆ, ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ, ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ವರದಿಯು ಹೊರಹೊಮ್ಮುತ್ತದೆ.
PostgreSQL DBMS ಒಂದು ದೊಡ್ಡ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ, ಮತ್ತು ಈ ಕಾರ್ಯವಿಧಾನವು ಅನೇಕ ಉಪವ್ಯವಸ್ಥೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಇದರ ಸಮನ್ವಯತೆಯು DBMS ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ, ಘಟಕಗಳ ಕಾರ್ಯಾಚರಣೆಯ ಬಗ್ಗೆ ಅಂಕಿಅಂಶಗಳು ಮತ್ತು ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಇದು PostgreSQL ನ ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಈ ಮಾಹಿತಿಯು ಬಹಳಷ್ಟು ಇದೆ ಮತ್ತು ಅದನ್ನು ಸರಳೀಕೃತ ರೂಪದಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ. ಈ ಮಾಹಿತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಅರ್ಥೈಸುವುದು ಕೆಲವೊಮ್ಮೆ ಸಂಪೂರ್ಣವಾಗಿ ಕ್ಷುಲ್ಲಕವಲ್ಲದ ಕೆಲಸವಾಗಿದೆ ಮತ್ತು ಪರಿಕರಗಳು ಮತ್ತು ಉಪಯುಕ್ತತೆಗಳ "ಮೃಗಾಲಯ" ಸುಧಾರಿತ DBA ಅನ್ನು ಸಹ ಸುಲಭವಾಗಿ ಗೊಂದಲಗೊಳಿಸಬಹುದು.
ಶುಭ ಅಪರಾಹ್ನ ನನ್ನ ಹೆಸರು ಅಲೆಕ್ಸಿ. ಇಲ್ಯಾ ಹೇಳಿದಂತೆ, ನಾನು PostgreSQL ಅಂಕಿಅಂಶಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ.
PostgreSQL ಚಟುವಟಿಕೆಯ ಅಂಕಿಅಂಶಗಳು. PostgreSQL ಎರಡು ಅಂಕಿಅಂಶಗಳನ್ನು ಹೊಂದಿದೆ. ಚಟುವಟಿಕೆಯ ಅಂಕಿಅಂಶಗಳು, ಇದನ್ನು ಚರ್ಚಿಸಲಾಗುವುದು. ಮತ್ತು ಡೇಟಾ ವಿತರಣೆಯ ಬಗ್ಗೆ ಶೆಡ್ಯೂಲರ್ ಅಂಕಿಅಂಶಗಳು. ನಾನು PostgreSQL ಚಟುವಟಿಕೆಯ ಅಂಕಿಅಂಶಗಳ ಬಗ್ಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಮಾತನಾಡುತ್ತೇನೆ, ಇದು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನಿರ್ಣಯಿಸಲು ಮತ್ತು ಅದನ್ನು ಹೇಗಾದರೂ ಸುಧಾರಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ನೀವು ಹೊಂದಿರುವ ಅಥವಾ ಹೊಂದಿರಬಹುದಾದ ವಿವಿಧ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಅಂಕಿಅಂಶಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಹೇಗೆ ಬಳಸುವುದು ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
ವರದಿಯಲ್ಲಿ ಏನು ಇರುವುದಿಲ್ಲ? ವರದಿಯಲ್ಲಿ, ನಾನು ವೇಳಾಪಟ್ಟಿಯ ಅಂಕಿಅಂಶಗಳನ್ನು ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ. ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಈ ಡೇಟಾದ ಗುಣಾತ್ಮಕ ಮತ್ತು ಪರಿಮಾಣಾತ್ಮಕ ಗುಣಲಕ್ಷಣಗಳ ಕಲ್ಪನೆಯನ್ನು ಪ್ರಶ್ನೆ ಯೋಜಕರು ಹೇಗೆ ಪಡೆಯುತ್ತಾರೆ ಎಂಬುದರ ಕುರಿತು ಪ್ರತ್ಯೇಕ ವರದಿಗಾಗಿ ಇದು ಪ್ರತ್ಯೇಕ ವಿಷಯವಾಗಿದೆ.
ಮತ್ತು ಯಾವುದೇ ಟೂಲ್ ವಿಮರ್ಶೆಗಳು ಇರುವುದಿಲ್ಲ, ನಾನು ಒಂದು ಉತ್ಪನ್ನವನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಹೋಲಿಸುವುದಿಲ್ಲ. ಯಾವುದೇ ಜಾಹೀರಾತು ಇರುವುದಿಲ್ಲ. ಅದನ್ನು ಬಿಡೋಣ.
ಅಂಕಿಅಂಶಗಳನ್ನು ಬಳಸುವುದು ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ತೋರಿಸಲು ಬಯಸುತ್ತೇನೆ. ಇದು ಅಗತ್ಯ. ಅದನ್ನು ನಿರ್ಭಯವಾಗಿ ಬಳಸಿ. ನಮಗೆ ಬೇಕಾಗಿರುವುದು ಸರಳ SQL ಮತ್ತು SQL ನ ಮೂಲಭೂತ ಜ್ಞಾನ.
ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಯಾವ ಅಂಕಿಅಂಶಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕೆಂದು ನಾವು ಮಾತನಾಡುತ್ತೇವೆ.
ನಾವು PostgreSQL ಅನ್ನು ನೋಡಿದರೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ವೀಕ್ಷಿಸಲು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನಲ್ಲಿ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿದರೆ, ನಾವು "ಬ್ಲಾಕ್ ಬಾಕ್ಸ್" ಅನ್ನು ನೋಡುತ್ತೇವೆ. ಏನನ್ನಾದರೂ ಮಾಡುವ ಕೆಲವು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಹೆಸರಿನಿಂದ ಅವರು ಅಲ್ಲಿ ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆ, ಅವರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆಂದು ನಾವು ಸ್ಥೂಲವಾಗಿ ಊಹಿಸಬಹುದು. ಆದರೆ, ವಾಸ್ತವವಾಗಿ, ಇದು ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯಾಗಿದೆ, ನಾವು ಒಳಗೆ ನೋಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ನಾವು CPU ಲೋಡ್ ಅನ್ನು ನೋಡಬಹುದು top, ನಾವು ಕೆಲವು ಸಿಸ್ಟಮ್ ಉಪಯುಕ್ತತೆಗಳಿಂದ ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ನೋಡಬಹುದು, ಆದರೆ PostgreSQL ಒಳಗೆ ನೋಡಲು ನಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಇದಕ್ಕಾಗಿ ನಮಗೆ ಇತರ ಉಪಕರಣಗಳು ಬೇಕಾಗುತ್ತವೆ.
ಮತ್ತು ಮತ್ತಷ್ಟು ಮುಂದುವರಿಯುತ್ತಾ, ಸಮಯವನ್ನು ಎಲ್ಲಿ ಕಳೆದಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. ಅಂತಹ ಯೋಜನೆಯ ರೂಪದಲ್ಲಿ ನಾವು PostgreSQL ಅನ್ನು ಪ್ರತಿನಿಧಿಸಿದರೆ, ಸಮಯವನ್ನು ಎಲ್ಲಿ ಕಳೆದಿದೆ ಎಂದು ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಇವು ಎರಡು ವಿಷಯಗಳಾಗಿವೆ: ಇದು ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಚಾಲನೆಯಲ್ಲಿಡಲು PostgreSQL ನಿರ್ವಹಿಸುವ ಹಿನ್ನೆಲೆ ಕಾರ್ಯಗಳು.
ನಾವು ಮೇಲಿನ ಎಡ ಮೂಲೆಯಲ್ಲಿ ನೋಡಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡಬಹುದು. ವಿನಂತಿಯು ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಬರುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಕೆಲಸಕ್ಕಾಗಿ ಕ್ಲೈಂಟ್ ಸೆಶನ್ ಅನ್ನು ತೆರೆಯಲಾಗುತ್ತದೆ. ವಿನಂತಿಯನ್ನು ಶೆಡ್ಯೂಲರ್‌ಗೆ ರವಾನಿಸಲಾಗಿದೆ. ಯೋಜಕರು ಪ್ರಶ್ನೆ ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ. ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತಷ್ಟು ಕಳುಹಿಸುತ್ತದೆ. ಕೋಷ್ಟಕಗಳು ಮತ್ತು ಸೂಚ್ಯಂಕಗಳೊಂದಿಗೆ ಕೆಲವು ರೀತಿಯ ಬ್ಲಾಕ್ I / O ಡೇಟಾ ಸಂಯೋಜಿತವಾಗಿದೆ. "ಹಂಚಿಕೊಂಡ ಬಫರ್‌ಗಳು" ಎಂಬ ವಿಶೇಷ ಪ್ರದೇಶದಲ್ಲಿ ಡಿಸ್ಕ್‌ಗಳಿಂದ ಮೆಮೊರಿಗೆ ಅಗತ್ಯವಾದ ಡೇಟಾವನ್ನು ಓದಲಾಗುತ್ತದೆ. ಪ್ರಶ್ನೆಯ ಫಲಿತಾಂಶಗಳು, ಅವು ನವೀಕರಣಗಳಾಗಿದ್ದರೆ, ಅಳಿಸಿದರೆ, WAL ನಲ್ಲಿನ ವಹಿವಾಟು ಲಾಗ್‌ನಲ್ಲಿ ದಾಖಲಿಸಲಾಗುತ್ತದೆ. ಕೆಲವು ಅಂಕಿಅಂಶಗಳ ಮಾಹಿತಿಯು ಲಾಗ್ ಅಥವಾ ಅಂಕಿಅಂಶಗಳ ಸಂಗ್ರಾಹಕಕ್ಕೆ ಹೋಗುತ್ತದೆ. ಮತ್ತು ವಿನಂತಿಯ ಫಲಿತಾಂಶವನ್ನು ಕ್ಲೈಂಟ್ಗೆ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ. ಅದರ ನಂತರ, ಕ್ಲೈಂಟ್ ಹೊಸ ವಿನಂತಿಯೊಂದಿಗೆ ಎಲ್ಲವನ್ನೂ ಪುನರಾವರ್ತಿಸಬಹುದು.
ಹಿನ್ನೆಲೆ ಕಾರ್ಯಗಳು ಮತ್ತು ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ ನಾವು ಏನು ಹೊಂದಿದ್ದೇವೆ? ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಹಲವಾರು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಈ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸಹ ವರದಿಯಲ್ಲಿ ಒಳಗೊಂಡಿದೆ: ಇವು ಆಟೋವಾಕ್ಯೂಮ್, ಚೆಕ್ಪಾಯಿಂಟರ್, ಪ್ರತಿಕೃತಿಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಕ್ರಿಯೆಗಳು, ಹಿನ್ನೆಲೆ ಬರಹಗಾರ. ನಾನು ವರದಿ ಮಾಡುವಂತೆ ನಾನು ಪ್ರತಿಯೊಂದನ್ನು ಸ್ಪರ್ಶಿಸುತ್ತೇನೆ.
ಅಂಕಿಅಂಶಗಳ ಸಮಸ್ಯೆಗಳೇನು?
- ಸಾಕಷ್ಟು ಮಾಹಿತಿ. ಅಂಕಿಅಂಶಗಳ ಡೇಟಾವನ್ನು ವೀಕ್ಷಿಸಲು PostgreSQL 9.4 109 ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಡೇಟಾಬೇಸ್ ಅನೇಕ ಕೋಷ್ಟಕಗಳು, ಸ್ಕೀಮಾಗಳು, ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, ಈ ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಅನುಗುಣವಾದ ಸಂಖ್ಯೆಯ ಕೋಷ್ಟಕಗಳು, ಡೇಟಾಬೇಸ್‌ಗಳಿಂದ ಗುಣಿಸಬೇಕಾಗುತ್ತದೆ. ಅಂದರೆ, ಇನ್ನೂ ಹೆಚ್ಚಿನ ಮಾಹಿತಿ ಇದೆ. ಮತ್ತು ಅದರಲ್ಲಿ ಮುಳುಗುವುದು ತುಂಬಾ ಸುಲಭ.
- ಅಂಕಿಅಂಶಗಳನ್ನು ಕೌಂಟರ್‌ಗಳಿಂದ ಪ್ರತಿನಿಧಿಸಲಾಗುತ್ತದೆ ಎಂಬುದು ಮುಂದಿನ ಸಮಸ್ಯೆಯಾಗಿದೆ. ನಾವು ಈ ಅಂಕಿಅಂಶಗಳನ್ನು ನೋಡಿದರೆ, ನಾವು ನಿರಂತರವಾಗಿ ಹೆಚ್ಚುತ್ತಿರುವ ಕೌಂಟರ್ಗಳನ್ನು ನೋಡುತ್ತೇವೆ. ಮತ್ತು ಅಂಕಿಅಂಶಗಳನ್ನು ಮರುಹೊಂದಿಸಿದ ನಂತರ ಸಾಕಷ್ಟು ಸಮಯ ಕಳೆದಿದ್ದರೆ, ನಾವು ಶತಕೋಟಿ ಮೌಲ್ಯಗಳನ್ನು ನೋಡುತ್ತೇವೆ. ಮತ್ತು ಅವರು ನಮಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
- ಇತಿಹಾಸವೇ ಇಲ್ಲ. ನೀವು ಕೆಲವು ರೀತಿಯ ವೈಫಲ್ಯವನ್ನು ಹೊಂದಿದ್ದರೆ, 15-30 ನಿಮಿಷಗಳ ಹಿಂದೆ ಏನಾದರೂ ಬಿದ್ದಿದ್ದರೆ, ನೀವು ಅಂಕಿಅಂಶಗಳನ್ನು ಬಳಸಲು ಮತ್ತು 15-30 ನಿಮಿಷಗಳ ಹಿಂದೆ ಏನಾಯಿತು ಎಂಬುದನ್ನು ನೋಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಇದು ಸಮಸ್ಯೆ.
- PostgreSQL ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಉಪಕರಣದ ಕೊರತೆಯು ಒಂದು ಸಮಸ್ಯೆಯಾಗಿದೆ. ಕರ್ನಲ್ ಡೆವಲಪರ್‌ಗಳು ಯಾವುದೇ ಉಪಯುಕ್ತತೆಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. ಅವರ ಬಳಿ ಅಂಥದ್ದೇನೂ ಇಲ್ಲ. ಅವರು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಅಂಕಿಅಂಶಗಳನ್ನು ನೀಡುತ್ತಾರೆ. ಅದನ್ನು ಬಳಸಿ, ಅದಕ್ಕೆ ವಿನಂತಿಯನ್ನು ಮಾಡಿ, ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಮಾಡಿ, ನಂತರ ಅದನ್ನು ಮಾಡಿ.
- PostgreSQL ನಲ್ಲಿ ಯಾವುದೇ ಉಪಕರಣವನ್ನು ನಿರ್ಮಿಸಲಾಗಿಲ್ಲವಾದ್ದರಿಂದ, ಇದು ಮತ್ತೊಂದು ಸಮಸ್ಯೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಸಾಕಷ್ಟು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಉಪಕರಣಗಳು. ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ನೇರ ಕೈಗಳನ್ನು ಹೊಂದಿರುವ ಪ್ರತಿಯೊಂದು ಕಂಪನಿಯು ತನ್ನದೇ ಆದ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಬರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ. ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಸಮುದಾಯವು ಅಂಕಿಅಂಶಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನೀವು ಬಳಸಬಹುದಾದ ಬಹಳಷ್ಟು ಸಾಧನಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಕೆಲವು ಸಾಧನಗಳಲ್ಲಿ ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳಿವೆ, ಇತರ ಸಾಧನಗಳಲ್ಲಿ ಯಾವುದೇ ವೈಶಿಷ್ಟ್ಯಗಳಿಲ್ಲ ಅಥವಾ ಕೆಲವು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳಿವೆ. ಮತ್ತು ನೀವು ಪರಸ್ಪರ ಅತಿಕ್ರಮಿಸುವ ಮತ್ತು ವಿಭಿನ್ನ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿರುವ ಎರಡು, ಮೂರು ಅಥವಾ ನಾಲ್ಕು ಸಾಧನಗಳನ್ನು ಬಳಸಬೇಕಾದ ಪರಿಸ್ಥಿತಿ ಉದ್ಭವಿಸುತ್ತದೆ. ಇದು ತುಂಬಾ ಕಿರಿಕಿರಿ ಉಂಟುಮಾಡುತ್ತದೆ.
ಇದರಿಂದ ಏನು ಅನುಸರಿಸುತ್ತದೆ? ಕಾರ್ಯಕ್ರಮಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗದಂತೆ ಅಂಕಿಅಂಶಗಳನ್ನು ನೇರವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಅಥವಾ ಹೇಗಾದರೂ ಈ ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ನೀವೇ ಸುಧಾರಿಸಿ: ನಿಮ್ಮ ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯಲು ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ಸೇರಿಸಿ.
ಮತ್ತು ನಿಮಗೆ SQL ನ ಮೂಲಭೂತ ಜ್ಞಾನದ ಅಗತ್ಯವಿದೆ. ಅಂಕಿಅಂಶಗಳಿಂದ ಕೆಲವು ಡೇಟಾವನ್ನು ಪಡೆಯಲು, ನೀವು SQL ಪ್ರಶ್ನೆಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ, ಅಂದರೆ ನೀವು ಆಯ್ಕೆ ಮಾಡುವುದು, ಸೇರುವುದು ಹೇಗೆ ಎಂದು ತಿಳಿಯಬೇಕು.
ಅಂಕಿಅಂಶಗಳು ನಮಗೆ ಹಲವಾರು ವಿಷಯಗಳನ್ನು ಹೇಳುತ್ತವೆ. ಅವುಗಳನ್ನು ವರ್ಗಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು.
- ಮೊದಲ ವರ್ಗವು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಡೆಯುತ್ತಿರುವ ಘಟನೆಗಳು. ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಕೆಲವು ಈವೆಂಟ್ ಸಂಭವಿಸಿದಾಗ: ಪ್ರಶ್ನೆ, ಟೇಬಲ್ ಪ್ರವೇಶ, ಆಟೋವಾಕ್ಯೂಮ್, ಕಮಿಟ್‌ಗಳು, ನಂತರ ಇವೆಲ್ಲವೂ ಈವೆಂಟ್‌ಗಳಾಗಿವೆ. ಈ ಘಟನೆಗಳಿಗೆ ಅನುಗುಣವಾದ ಕೌಂಟರ್ಗಳನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ. ಮತ್ತು ನಾವು ಈ ಘಟನೆಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು.
- ಎರಡನೆಯ ವರ್ಗವು ಕೋಷ್ಟಕಗಳು, ಡೇಟಾಬೇಸ್ಗಳಂತಹ ವಸ್ತುಗಳ ಗುಣಲಕ್ಷಣಗಳು. ಅವರು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಇದು ಕೋಷ್ಟಕಗಳ ಗಾತ್ರವಾಗಿದೆ. ನಾವು ಕೋಷ್ಟಕಗಳ ಬೆಳವಣಿಗೆ, ಸೂಚ್ಯಂಕಗಳ ಬೆಳವಣಿಗೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು. ಡೈನಾಮಿಕ್ಸ್ನಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ನಾವು ನೋಡಬಹುದು.
- ಮತ್ತು ಮೂರನೇ ವರ್ಗವು ಈವೆಂಟ್‌ನಲ್ಲಿ ಕಳೆದ ಸಮಯ. ವಿನಂತಿಯು ಒಂದು ಘಟನೆಯಾಗಿದೆ. ಇದು ತನ್ನದೇ ಆದ ನಿರ್ದಿಷ್ಟ ಅವಧಿಯನ್ನು ಹೊಂದಿದೆ. ಇಲ್ಲಿ ಪ್ರಾರಂಭವಾಯಿತು, ಇಲ್ಲಿಯೇ ಮುಗಿಯಿತು. ನಾವು ಅದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು. ಡಿಸ್ಕ್ ಅಥವಾ ಬರವಣಿಗೆಯಿಂದ ಬ್ಲಾಕ್ ಅನ್ನು ಓದುವ ಸಮಯ. ಈ ವಿಷಯಗಳನ್ನು ಸಹ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಅಂಕಿಅಂಶಗಳ ಮೂಲಗಳನ್ನು ಈ ಕೆಳಗಿನಂತೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ:
- ಹಂಚಿದ ಮೆಮೊರಿಯಲ್ಲಿ (ಹಂಚಿದ ಬಫರ್‌ಗಳು) ಸ್ಥಿರ ಡೇಟಾವನ್ನು ಇರಿಸಲು ಒಂದು ವಿಭಾಗವಿದೆ, ಕೆಲವು ಘಟನೆಗಳು ಸಂಭವಿಸಿದಾಗ ಅಥವಾ ಡೇಟಾಬೇಸ್ನ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಕೆಲವು ಕ್ಷಣಗಳು ಸಂಭವಿಸಿದಾಗ ನಿರಂತರವಾಗಿ ಹೆಚ್ಚಾಗುವ ಕೌಂಟರ್‌ಗಳು ಸಹ ಇವೆ.
- ಈ ಎಲ್ಲಾ ಕೌಂಟರ್‌ಗಳು ಬಳಕೆದಾರರಿಗೆ ಲಭ್ಯವಿಲ್ಲ ಮತ್ತು ನಿರ್ವಾಹಕರಿಗೂ ಲಭ್ಯವಿಲ್ಲ. ಇವು ಕೆಳಮಟ್ಟದ ವಿಷಯಗಳು. ಅವುಗಳನ್ನು ಪ್ರವೇಶಿಸಲು, PostgreSQL SQL ಕಾರ್ಯಗಳ ರೂಪದಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಈ ಕಾರ್ಯಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಆಯ್ದ ಆಯ್ಕೆಗಳನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಕೆಲವು ರೀತಿಯ ಮೆಟ್ರಿಕ್ (ಅಥವಾ ಮೆಟ್ರಿಕ್‌ಗಳ ಸೆಟ್) ಅನ್ನು ಪಡೆಯಬಹುದು.
- ಆದಾಗ್ಯೂ, ಈ ಕಾರ್ಯಗಳನ್ನು ಬಳಸಲು ಯಾವಾಗಲೂ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ಕಾರ್ಯಗಳು ವೀಕ್ಷಣೆಗಳಿಗೆ ಆಧಾರವಾಗಿದೆ (ವೀಕ್ಷಣೆಗಳು). ಇವುಗಳು ನಿರ್ದಿಷ್ಟ ಉಪವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅಥವಾ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಕೆಲವು ಘಟನೆಗಳ ಮೇಲೆ ಅಂಕಿಅಂಶಗಳನ್ನು ಒದಗಿಸುವ ವರ್ಚುವಲ್ ಕೋಷ್ಟಕಗಳಾಗಿವೆ.
- ಈ ಅಂತರ್ನಿರ್ಮಿತ ವೀಕ್ಷಣೆಗಳು (ವೀಕ್ಷಣೆಗಳು) ಅಂಕಿಅಂಶಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಮುಖ್ಯ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಆಗಿದೆ. ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಲ್ಲದೆ ಅವು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಲಭ್ಯವಿವೆ, ನೀವು ತಕ್ಷಣ ಅವುಗಳನ್ನು ಬಳಸಬಹುದು, ವೀಕ್ಷಿಸಬಹುದು, ಅಲ್ಲಿಂದ ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಮತ್ತು ಕೊಡುಗೆಗಳೂ ಇವೆ. ಕೊಡುಗೆಗಳು ಅಧಿಕೃತವಾಗಿವೆ. ನೀವು postgresql-contrib ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬಹುದು (ಉದಾಹರಣೆಗೆ, postgresql94-contrib), ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಅಗತ್ಯವಾದ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಿ, ಅದಕ್ಕೆ ನಿಯತಾಂಕಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ, PostgreSQL ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ನೀವು ಅದನ್ನು ಬಳಸಬಹುದು. (ಸೂಚನೆ. ವಿತರಣೆಯನ್ನು ಅವಲಂಬಿಸಿ, ಕೊಡುಗೆಯ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಪ್ಯಾಕೇಜ್ ಮುಖ್ಯ ಪ್ಯಾಕೇಜ್‌ನ ಭಾಗವಾಗಿದೆ).
- ಮತ್ತು ಅನಧಿಕೃತ ಕೊಡುಗೆಗಳಿವೆ. ಅವುಗಳನ್ನು ಪ್ರಮಾಣಿತ PostgreSQL ವಿತರಣೆಯೊಂದಿಗೆ ಸರಬರಾಜು ಮಾಡಲಾಗಿಲ್ಲ. ಅವುಗಳನ್ನು ಕಂಪೈಲ್ ಮಾಡಬೇಕು ಅಥವಾ ಲೈಬ್ರರಿಯಾಗಿ ಸ್ಥಾಪಿಸಬೇಕು. ಈ ಅನಧಿಕೃತ ಕೊಡುಗೆಯ ಡೆವಲಪರ್ ಏನನ್ನು ತಂದರು ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಆಯ್ಕೆಗಳು ತುಂಬಾ ಭಿನ್ನವಾಗಿರಬಹುದು.
ಈ ಸ್ಲೈಡ್ ಆ ಎಲ್ಲಾ ವೀಕ್ಷಣೆಗಳನ್ನು (ವೀಕ್ಷಣೆಗಳು) ಮತ್ತು PostgreSQL 9.4 ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ನಾವು ನೋಡುವಂತೆ, ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಇವೆ. ಮತ್ತು ನೀವು ಮೊದಲ ಬಾರಿಗೆ ಅದನ್ನು ಅನುಭವಿಸುತ್ತಿದ್ದರೆ ಗೊಂದಲಕ್ಕೊಳಗಾಗುವುದು ತುಂಬಾ ಸುಲಭ.
ಆದಾಗ್ಯೂ, ನಾವು ಹಿಂದಿನ ಚಿತ್ರವನ್ನು ತೆಗೆದುಕೊಂಡರೆ Как тратится время на PostgreSQL ಮತ್ತು ಈ ಪಟ್ಟಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ, ನಾವು ಈ ಚಿತ್ರವನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಪ್ರತಿಯೊಂದು ವೀಕ್ಷಣೆ (ವೀಕ್ಷಣೆಗಳು), ಅಥವಾ ಪ್ರತಿ ಕಾರ್ಯ, ನಾವು PostgreSQL ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಸೂಕ್ತವಾದ ಅಂಕಿಅಂಶಗಳನ್ನು ಪಡೆಯಲು ನಾವು ಒಂದು ಉದ್ದೇಶಕ್ಕಾಗಿ ಅಥವಾ ಇನ್ನೊಂದು ಉದ್ದೇಶಕ್ಕಾಗಿ ಬಳಸಬಹುದು. ಮತ್ತು ಉಪವ್ಯವಸ್ಥೆಯ ಕಾರ್ಯಾಚರಣೆಯ ಬಗ್ಗೆ ನಾವು ಈಗಾಗಲೇ ಕೆಲವು ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು.
ನಾವು ನೋಡುವ ಮೊದಲ ವಿಷಯ pg_stat_database. ನಾವು ನೋಡುವಂತೆ, ಇದು ಪ್ರಾತಿನಿಧ್ಯವಾಗಿದೆ. ಇದು ಬಹಳಷ್ಟು ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ. ಅತ್ಯಂತ ವೈವಿಧ್ಯಮಯ ಮಾಹಿತಿ. ಮತ್ತು ನಾವು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದರ ಕುರಿತು ಇದು ತುಂಬಾ ಉಪಯುಕ್ತವಾದ ಜ್ಞಾನವನ್ನು ನೀಡುತ್ತದೆ.
ನಾವು ಅಲ್ಲಿಂದ ಏನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು? ಸರಳವಾದ ವಿಷಯಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ.
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;ನಾವು ನೋಡಬಹುದಾದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಸಂಗ್ರಹ ಹಿಟ್ ಶೇಕಡಾವಾರು. ಸಂಗ್ರಹ ಹಿಟ್ ಶೇಕಡಾವಾರು ಉಪಯುಕ್ತ ಮೆಟ್ರಿಕ್ ಆಗಿದೆ. ಹಂಚಿದ ಬಫರ್‌ಗಳ ಸಂಗ್ರಹದಿಂದ ಎಷ್ಟು ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಮತ್ತು ಡಿಸ್ಕ್‌ನಿಂದ ಎಷ್ಟು ಓದಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅಂದಾಜು ಮಾಡಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ ನಮ್ಮಲ್ಲಿ ಹೆಚ್ಚು ಸಂಗ್ರಹ ಹಿಟ್, ಉತ್ತಮ. ನಾವು ಈ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಶೇಕಡಾವಾರು ಎಂದು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ. ಮತ್ತು, ಉದಾಹರಣೆಗೆ, ನಾವು ಈ ಸಂಗ್ರಹದ ಶೇಕಡಾವಾರು ಹಿಟ್‌ಗಳನ್ನು 90% ಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೊಂದಿದ್ದರೆ, ಇದು ಒಳ್ಳೆಯದು. ಅದು 90% ಕ್ಕಿಂತ ಕಡಿಮೆಯಾದರೆ, ಡೇಟಾದ ಹಾಟ್ ಹೆಡ್ ಅನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಇರಿಸಿಕೊಳ್ಳಲು ನಮಗೆ ಸಾಕಷ್ಟು ಮೆಮೊರಿ ಇರುವುದಿಲ್ಲ. ಮತ್ತು ಈ ಡೇಟಾವನ್ನು ಬಳಸಲು, PostgreSQL ಅನ್ನು ಡಿಸ್ಕ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಇದು ಮೆಮೊರಿಯಿಂದ ಡೇಟಾವನ್ನು ಓದುವುದಕ್ಕಿಂತ ನಿಧಾನವಾಗಿರುತ್ತದೆ. ಮತ್ತು ನೀವು ಮೆಮೊರಿಯನ್ನು ಹೆಚ್ಚಿಸುವ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕು: ಹಂಚಿದ ಬಫರ್‌ಗಳನ್ನು ಹೆಚ್ಚಿಸಿ, ಅಥವಾ ಕಬ್ಬಿಣದ ಮೆಮೊರಿಯನ್ನು ಹೆಚ್ಚಿಸಿ (RAM).
select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;ಈ ಪ್ರಸ್ತುತಿಯಿಂದ ಇನ್ನೇನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು? ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಭವಿಸುವ ವೈಪರೀತ್ಯಗಳನ್ನು ನೀವು ನೋಡಬಹುದು. ಇಲ್ಲಿ ಏನು ತೋರಿಸಲಾಗಿದೆ? ಕಮಿಟ್‌ಗಳು, ರೋಲ್‌ಬ್ಯಾಕ್‌ಗಳು, ತಾತ್ಕಾಲಿಕ ಫೈಲ್‌ಗಳ ರಚನೆ, ಅವುಗಳ ಗಾತ್ರ, ಡೆಡ್‌ಲಾಕ್‌ಗಳು ಮತ್ತು ಸಂಘರ್ಷಗಳು ಇವೆ.
ನಾವು ಈ ವಿನಂತಿಯನ್ನು ಬಳಸಬಹುದು. ಈ SQL ಬಹಳ ಸರಳವಾಗಿದೆ. ಮತ್ತು ನಾವು ಈ ಡೇಟಾವನ್ನು ನಮಗಾಗಿ ನೋಡಬಹುದು.
ಮತ್ತು ಮಿತಿ ಮೌಲ್ಯಗಳು ಇಲ್ಲಿವೆ. ನಾವು ಕಮಿಟ್‌ಗಳು ಮತ್ತು ರೋಲ್‌ಬ್ಯಾಕ್‌ಗಳ ಅನುಪಾತವನ್ನು ನೋಡುತ್ತೇವೆ. ಕಮಿಟ್ಸ್ ವ್ಯವಹಾರದ ಯಶಸ್ವಿ ದೃಢೀಕರಣವಾಗಿದೆ. ರೋಲ್‌ಬ್ಯಾಕ್ ಒಂದು ರೋಲ್‌ಬ್ಯಾಕ್ ಆಗಿದೆ, ಅಂದರೆ ವಹಿವಾಟು ಕೆಲವು ಕೆಲಸ ಮಾಡಿದೆ, ಡೇಟಾಬೇಸ್ ಅನ್ನು ತಗ್ಗಿಸಿದೆ, ಏನನ್ನಾದರೂ ಪರಿಗಣಿಸಲಾಗಿದೆ, ಮತ್ತು ನಂತರ ವೈಫಲ್ಯ ಸಂಭವಿಸಿದೆ ಮತ್ತು ವಹಿವಾಟಿನ ಫಲಿತಾಂಶಗಳನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ಅಂದರೆ ನಿರಂತರವಾಗಿ ಹೆಚ್ಚುತ್ತಿರುವ ರೋಲ್‌ಬ್ಯಾಕ್‌ಗಳ ಸಂಖ್ಯೆ ಕೆಟ್ಟದಾಗಿದೆ. ಮತ್ತು ನೀವು ಹೇಗಾದರೂ ಅವುಗಳನ್ನು ತಪ್ಪಿಸಬೇಕು ಮತ್ತು ಇದು ಸಂಭವಿಸದಂತೆ ಕೋಡ್ ಅನ್ನು ಸಂಪಾದಿಸಿ.
ಸಂಘರ್ಷಗಳು ಪ್ರತಿಕೃತಿಗೆ ಸಂಬಂಧಿಸಿವೆ. ಮತ್ತು ಅವುಗಳನ್ನು ಸಹ ತಪ್ಪಿಸಬೇಕು. ನೀವು ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಕೆಲವು ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಸಂಘರ್ಷಗಳು ಉದ್ಭವಿಸಿದರೆ, ನೀವು ಈ ಸಂಘರ್ಷಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಬೇಕು ಮತ್ತು ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಬೇಕು. ವಿವರಗಳನ್ನು ಲಾಗ್‌ಗಳಲ್ಲಿ ಕಾಣಬಹುದು. ಮತ್ತು ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಿ ಇದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಗಳು ದೋಷಗಳಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ಡೆಡ್‌ಲಾಕ್ಸ್ ಕೂಡ ಕೆಟ್ಟ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ. ವಿನಂತಿಗಳು ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಸ್ಪರ್ಧಿಸಿದಾಗ, ಒಂದು ವಿನಂತಿಯು ಒಂದು ಸಂಪನ್ಮೂಲವನ್ನು ಪ್ರವೇಶಿಸಿ ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಿತು, ಎರಡನೆಯ ವಿನಂತಿಯು ಎರಡನೇ ಸಂಪನ್ಮೂಲವನ್ನು ಪ್ರವೇಶಿಸಿತು ಮತ್ತು ಲಾಕ್ ಅನ್ನು ಸಹ ತೆಗೆದುಕೊಂಡಿತು, ಮತ್ತು ನಂತರ ಎರಡೂ ವಿನಂತಿಗಳು ಪರಸ್ಪರ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರವೇಶಿಸಿದವು ಮತ್ತು ಲಾಕ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ನೆರೆಹೊರೆಯವರಿಗೆ ಕಾಯುವುದನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ. ಇದೂ ಒಂದು ಸಮಸ್ಯಾತ್ಮಕ ಪರಿಸ್ಥಿತಿ. ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪುನಃ ಬರೆಯುವ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಧಾರಾವಾಹಿ ಮಾಡುವ ಮಟ್ಟದಲ್ಲಿ ಅವುಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ. ಮತ್ತು ನಿಮ್ಮ ಡೆಡ್‌ಲಾಕ್‌ಗಳು ನಿರಂತರವಾಗಿ ಹೆಚ್ಚುತ್ತಿವೆ ಎಂದು ನೀವು ನೋಡಿದರೆ, ನೀವು ಲಾಗ್‌ಗಳಲ್ಲಿನ ವಿವರಗಳನ್ನು ನೋಡಬೇಕು, ಉದ್ಭವಿಸಿದ ಸಂದರ್ಭಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಬೇಕು ಮತ್ತು ಸಮಸ್ಯೆ ಏನೆಂದು ನೋಡಬೇಕು.
ತಾತ್ಕಾಲಿಕ ಫೈಲ್‌ಗಳು (temp_files) ಸಹ ಕೆಟ್ಟದಾಗಿವೆ. ಬಳಕೆದಾರರ ವಿನಂತಿಯು ಕಾರ್ಯಾಚರಣೆಯ, ತಾತ್ಕಾಲಿಕ ಡೇಟಾವನ್ನು ಸರಿಹೊಂದಿಸಲು ಸಾಕಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಅದು ಡಿಸ್ಕ್ನಲ್ಲಿ ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಮತ್ತು ಮೆಮೊರಿಯಲ್ಲಿ ತಾತ್ಕಾಲಿಕ ಬಫರ್‌ನಲ್ಲಿ ಅವನು ನಿರ್ವಹಿಸಬಹುದಾದ ಎಲ್ಲಾ ಕಾರ್ಯಾಚರಣೆಗಳು ಈಗಾಗಲೇ ಡಿಸ್ಕ್ನಲ್ಲಿ ನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಇದು ನಿಧಾನವಾಗಿದೆ. ಇದು ಪ್ರಶ್ನೆ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಮತ್ತು PostgreSQL ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದ ಕ್ಲೈಂಟ್ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ಈ ಎಲ್ಲಾ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ನಿರ್ವಹಿಸಿದರೆ, ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಹೆಚ್ಚು ವೇಗವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಕಡಿಮೆ ಕಾಯುತ್ತದೆ.
pg_stat_bgwriter - ಈ ವೀಕ್ಷಣೆಯು ಎರಡು PostgreSQL ಹಿನ್ನೆಲೆ ಉಪವ್ಯವಸ್ಥೆಗಳ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ: checkpointer и background writer.
ಮೊದಲಿಗೆ, ನಿಯಂತ್ರಣ ಬಿಂದುಗಳನ್ನು ವಿಶ್ಲೇಷಿಸೋಣ, ಕರೆಯಲ್ಪಡುವ. checkpoints. ಚೆಕ್‌ಪೋಸ್ಟ್‌ಗಳು ಯಾವುವು? ಚೆಕ್ಪಾಯಿಂಟ್ ಎನ್ನುವುದು ವಹಿವಾಟು ಲಾಗ್‌ನಲ್ಲಿನ ಸ್ಥಾನವಾಗಿದ್ದು, ಲಾಗ್‌ನಲ್ಲಿ ಮಾಡಿದ ಎಲ್ಲಾ ಡೇಟಾ ಬದಲಾವಣೆಗಳನ್ನು ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಡೇಟಾದೊಂದಿಗೆ ಯಶಸ್ವಿಯಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಕೆಲಸದ ಹೊರೆ ಮತ್ತು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿ ಪ್ರಕ್ರಿಯೆಯು ದೀರ್ಘವಾಗಿರುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಡಿಸ್ಕ್ನಲ್ಲಿನ ಡೇಟಾ ಫೈಲ್ಗಳೊಂದಿಗೆ ಹಂಚಿದ ಬಫರ್‌ಗಳಲ್ಲಿ ಕೊಳಕು ಪುಟಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಇದು ಯಾವುದಕ್ಕಾಗಿ? PostgreSQL ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಡಿಸ್ಕ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತಿದ್ದರೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದ್ದರೆ ಮತ್ತು ಪ್ರತಿ ಪ್ರವೇಶದಲ್ಲಿ ಡೇಟಾವನ್ನು ಬರೆಯುತ್ತಿದ್ದರೆ, ಅದು ನಿಧಾನವಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, PostgreSQL ಒಂದು ಮೆಮೊರಿ ವಿಭಾಗವನ್ನು ಹೊಂದಿದೆ, ಅದರ ಗಾತ್ರವು ಸಂರಚನೆಯಲ್ಲಿನ ನಿಯತಾಂಕಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಈ ಮೆಮೊರಿಯಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಯ ಡೇಟಾವನ್ನು ಮತ್ತಷ್ಟು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅಥವಾ ಪ್ರಶ್ನಿಸಲು ನಿಯೋಜಿಸುತ್ತದೆ. ಡೇಟಾ ಬದಲಾವಣೆ ವಿನಂತಿಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ನಾವು ಡೇಟಾದ ಎರಡು ಆವೃತ್ತಿಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಒಂದು ಮೆಮೊರಿಯಲ್ಲಿದೆ, ಇನ್ನೊಂದು ಡಿಸ್ಕ್ನಲ್ಲಿದೆ. ಮತ್ತು ನಿಯತಕಾಲಿಕವಾಗಿ ನೀವು ಈ ಡೇಟಾವನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಡಿಸ್ಕ್ಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಮೆಮೊರಿಯಲ್ಲಿ ಏನು ಬದಲಾಯಿಸಲಾಗಿದೆ ಎಂಬುದು ನಮಗೆ ಬೇಕಾಗುತ್ತದೆ. ಇದಕ್ಕೆ ತಪಾಸಣಾ ಕೇಂದ್ರದ ಅಗತ್ಯವಿದೆ.
ಚೆಕ್ಪಾಯಿಂಟ್ ಹಂಚಿದ ಬಫರ್‌ಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಕೊಳಕು ಪುಟಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ. ನಂತರ ಅದು ಹಂಚಿಕೊಂಡ ಬಫರ್‌ಗಳ ಮೂಲಕ ಎರಡನೇ ಪಾಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಮತ್ತು ಚೆಕ್ಪಾಯಿಂಟ್ಗಾಗಿ ಗುರುತಿಸಲಾದ ಪುಟಗಳು, ಅವರು ಈಗಾಗಲೇ ಅವುಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತಾರೆ. ಹೀಗಾಗಿ, ಡೇಟಾವನ್ನು ಈಗಾಗಲೇ ಡಿಸ್ಕ್ನೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗಿದೆ.
ಎರಡು ರೀತಿಯ ನಿಯಂತ್ರಣ ಬಿಂದುಗಳಿವೆ. ಸಮಯ ಮೀರಿದಾಗ ಒಂದು ಚೆಕ್ಪಾಯಿಂಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಈ ಚೆಕ್ಪಾಯಿಂಟ್ ಉಪಯುಕ್ತ ಮತ್ತು ಉತ್ತಮವಾಗಿದೆ - checkpoint_timed. ಮತ್ತು ಬೇಡಿಕೆಯ ಮೇರೆಗೆ ಚೆಕ್‌ಪೋಸ್ಟ್‌ಗಳಿವೆ - checkpoint required. ನಾವು ದೊಡ್ಡ ಡೇಟಾ ದಾಖಲೆಯನ್ನು ಹೊಂದಿರುವಾಗ ಇಂತಹ ಚೆಕ್ಪಾಯಿಂಟ್ ಸಂಭವಿಸುತ್ತದೆ. ನಾವು ಬಹಳಷ್ಟು ವಹಿವಾಟು ಲಾಗ್‌ಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿದ್ದೇವೆ. ಮತ್ತು PostgreSQL ಇದನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವ ಅಗತ್ಯವಿದೆ ಎಂದು ನಂಬುತ್ತದೆ, ಚೆಕ್ಪಾಯಿಂಟ್ ಮಾಡಿ ಮತ್ತು ಮುಂದುವರಿಯಿರಿ.
ಮತ್ತು ನೀವು ಅಂಕಿಅಂಶಗಳನ್ನು ನೋಡಿದರೆ pg_stat_bgwriter ಮತ್ತು ನೀವು ಹೊಂದಿರುವುದನ್ನು ನೋಡಿ ಚೆಕ್ಪಾಯಿಂಟ್_ರೆಕ್ ಚೆಕ್ಪಾಯಿಂಟ್_ಟೈಮ್ಡ್‌ಗಿಂತ ದೊಡ್ಡದಾಗಿದೆ, ನಂತರ ಇದು ಕೆಟ್ಟದಾಗಿದೆ. ಏಕೆ ಕೆಟ್ಟದು? ಇದರರ್ಥ PostgreSQL ಡಿಸ್ಕ್ಗೆ ಡೇಟಾವನ್ನು ಬರೆಯಬೇಕಾದಾಗ ನಿರಂತರ ಒತ್ತಡದಲ್ಲಿದೆ. ಸಮಯ ಮೀರಿದ ಚೆಕ್ಪಾಯಿಂಟ್ ಕಡಿಮೆ ಒತ್ತಡದಿಂದ ಕೂಡಿರುತ್ತದೆ ಮತ್ತು ಆಂತರಿಕ ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಕಾಲಾನಂತರದಲ್ಲಿ ವಿಸ್ತರಿಸಲಾಗುತ್ತದೆ. PostgreSQL ಕೆಲಸದಲ್ಲಿ ವಿರಾಮಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯನ್ನು ತಗ್ಗಿಸುವುದಿಲ್ಲ. ಇದು PostgreSQL ಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ. ಮತ್ತು ಚೆಕ್ಪಾಯಿಂಟ್ ಸಮಯದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾದ ವಿನಂತಿಗಳು ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯು ಕಾರ್ಯನಿರತವಾಗಿದೆ ಎಂಬ ಅಂಶದಿಂದ ಒತ್ತಡವನ್ನು ಅನುಭವಿಸುವುದಿಲ್ಲ.
ಮತ್ತು ಚೆಕ್ಪಾಯಿಂಟ್ ಅನ್ನು ಸರಿಹೊಂದಿಸಲು ಮೂರು ನಿಯತಾಂಕಗಳಿವೆ:
-
сheckpoint_segments. -
сheckpoint_timeout. -
сheckpoint_competion_target.
ನಿಯಂತ್ರಣ ಬಿಂದುಗಳ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಅವರು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತಾರೆ. ಆದರೆ ನಾನು ಅವರ ಮೇಲೆ ನೆಲೆಸುವುದಿಲ್ಲ. ಅವರ ಪ್ರಭಾವವು ಪ್ರತ್ಯೇಕ ವಿಷಯವಾಗಿದೆ.
ಎಚ್ಚರಿಕೆ: ವರದಿಯಲ್ಲಿ ಪರಿಗಣಿಸಲಾದ ಆವೃತ್ತಿ 9.4 ಇನ್ನು ಮುಂದೆ ಪ್ರಸ್ತುತವಾಗಿಲ್ಲ. PostgreSQL ನ ಆಧುನಿಕ ಆವೃತ್ತಿಗಳಲ್ಲಿ, ಪ್ಯಾರಾಮೀಟರ್ checkpoint_segments ನಿಯತಾಂಕಗಳಿಂದ ಬದಲಾಯಿಸಲಾಗಿದೆ min_wal_size и max_wal_size.
ಮುಂದಿನ ಉಪವ್ಯವಸ್ಥೆಯು ಹಿನ್ನೆಲೆ ಬರಹಗಾರ - background writer. ಅವನು ಏನು ಮಾಡುತ್ತಿದ್ದಾನೆ? ಇದು ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್ನಲ್ಲಿ ನಿರಂತರವಾಗಿ ಚಲಿಸುತ್ತದೆ. ಇದು ಹಂಚಿದ ಬಫರ್‌ಗಳಲ್ಲಿ ಪುಟಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಡಿಸ್ಕ್ಗೆ ಕಂಡು ಬರುವ ಕೊಳಕು ಪುಟಗಳನ್ನು ಫ್ಲಶ್ ಮಾಡುತ್ತದೆ. ಈ ರೀತಿಯಾಗಿ, ಚೆಕ್ಪಾಯಿಂಟಿಂಗ್ ಸಮಯದಲ್ಲಿ ಕಡಿಮೆ ಕೆಲಸವನ್ನು ಮಾಡಲು ಚೆಕ್ಪಾಯಿಂಟರ್ಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಅವನು ಇನ್ನೇನು ಬೇಕು? ಡೇಟಾವನ್ನು ಸರಿಹೊಂದಿಸಲು ಹಠಾತ್ತನೆ (ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಮತ್ತು ತಕ್ಷಣವೇ) ಅಗತ್ಯವಿದ್ದರೆ ಹಂಚಿದ ಬಫರ್‌ಗಳಲ್ಲಿ ಕ್ಲೀನ್ ಪುಟಗಳ ಅಗತ್ಯವನ್ನು ಇದು ಒದಗಿಸುತ್ತದೆ. ವಿನಂತಿಯು ಕ್ಲೀನ್ ಪುಟಗಳ ಅಗತ್ಯವಿರುವಾಗ ಪರಿಸ್ಥಿತಿ ಉದ್ಭವಿಸಿದೆ ಎಂದು ಭಾವಿಸೋಣ ಮತ್ತು ಅವುಗಳು ಈಗಾಗಲೇ ಹಂಚಿದ ಬಫರ್‌ಗಳಲ್ಲಿವೆ. ಪೋಸ್ಟ್ಗ್ರೆಸ್ backend ಅವನು ಅವುಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಅವುಗಳನ್ನು ಬಳಸುತ್ತಾನೆ, ಅವನು ತಾನೇ ಏನನ್ನೂ ಸ್ವಚ್ಛಗೊಳಿಸಬೇಕಾಗಿಲ್ಲ. ಆದರೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅಂತಹ ಯಾವುದೇ ಪುಟಗಳಿಲ್ಲದಿದ್ದರೆ, ಬ್ಯಾಕೆಂಡ್ ವಿರಾಮಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಡಿಸ್ಕ್ಗೆ ಫ್ಲಶ್ ಮಾಡಲು ಮತ್ತು ಅದರ ಸ್ವಂತ ಅಗತ್ಯಗಳಿಗಾಗಿ ಅವುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಪುಟಗಳನ್ನು ಹುಡುಕಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ - ಇದು ಪ್ರಸ್ತುತ ಕಾರ್ಯಗತಗೊಳಿಸುವ ವಿನಂತಿಯ ಸಮಯವನ್ನು ಋಣಾತ್ಮಕವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ನೀವು ನಿಯತಾಂಕವನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ನೀವು ನೋಡಿದರೆ maxwritten_clean ದೊಡ್ಡದು, ಇದರರ್ಥ ಹಿನ್ನೆಲೆ ಬರಹಗಾರ ತನ್ನ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿಲ್ಲ ಮತ್ತು ನೀವು ನಿಯತಾಂಕಗಳನ್ನು ಹೆಚ್ಚಿಸಬೇಕಾಗಿದೆ bgwriter_lru_maxpagesಇದರಿಂದ ಅವನು ಒಂದು ಚಕ್ರದಲ್ಲಿ ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ಮಾಡಬಹುದು, ಹೆಚ್ಚಿನ ಪುಟಗಳನ್ನು ತೆರವುಗೊಳಿಸಬಹುದು.
ಮತ್ತು ಇನ್ನೊಂದು ಅತ್ಯಂತ ಉಪಯುಕ್ತ ಸೂಚಕ buffers_backend_fsync. ಬ್ಯಾಕೆಂಡ್‌ಗಳು fsync ಅನ್ನು ಮಾಡುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಅದು ನಿಧಾನವಾಗಿರುತ್ತದೆ. ಅವರು fsync ಅನ್ನು IO ಸ್ಟಾಕ್ ಚೆಕ್ಪಾಯಿಂಟರ್ ಅನ್ನು ರವಾನಿಸುತ್ತಾರೆ. ಚೆಕ್ಪಾಯಿಂಟರ್ ತನ್ನದೇ ಆದ ಕ್ಯೂ ಅನ್ನು ಹೊಂದಿದೆ, ಇದು ನಿಯತಕಾಲಿಕವಾಗಿ fsync ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಡಿಸ್ಕ್ನಲ್ಲಿನ ಫೈಲ್ಗಳೊಂದಿಗೆ ಮೆಮೊರಿಯಲ್ಲಿ ಪುಟಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತದೆ. ಚೆಕ್ಪಾಯಿಂಟರ್ ಕ್ಯೂ ದೊಡ್ಡದಾಗಿದ್ದರೆ ಮತ್ತು ಪೂರ್ಣವಾಗಿದ್ದರೆ, ಬ್ಯಾಕೆಂಡ್ ಸ್ವತಃ fsync ಮಾಡಲು ಬಲವಂತಪಡಿಸುತ್ತದೆ ಮತ್ತು ಇದು ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ, ಅಂದರೆ ಕ್ಲೈಂಟ್ ಅದು ಸಾಧ್ಯವಾಗುವುದಕ್ಕಿಂತ ನಂತರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ನೀವು ಶೂನ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ನೀವು ನೋಡಿದರೆ, ಇದು ಈಗಾಗಲೇ ಸಮಸ್ಯೆಯಾಗಿದೆ ಮತ್ತು ನೀವು ಹಿನ್ನೆಲೆ ಬರಹಗಾರನ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಗಮನ ಕೊಡಬೇಕು ಮತ್ತು ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ಎಚ್ಚರಿಕೆ: _ಈ ಕೆಳಗಿನ ಪಠ್ಯವು ಪ್ರತಿಕೃತಿಗೆ ಸಂಬಂಧಿಸಿದ ಅಂಕಿಅಂಶಗಳ ವೀಕ್ಷಣೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ವೀಕ್ಷಣೆ ಮತ್ತು ಕಾರ್ಯದ ಹೆಸರುಗಳನ್ನು ಪೋಸ್ಟ್ಗ್ರೆಸ್ 10 ರಲ್ಲಿ ಮರುಹೆಸರಿಸಲಾಗಿದೆ. ಮರುಹೆಸರುಗಳ ಮೂಲತತ್ವವು ಬದಲಿಸುವುದು xlog ಮೇಲೆ wal и location ಮೇಲೆ lsn ಕಾರ್ಯ/ವೀಕ್ಷಣೆ ಹೆಸರುಗಳಲ್ಲಿ, ಇತ್ಯಾದಿ. ನಿರ್ದಿಷ್ಟ ಉದಾಹರಣೆ, ಕಾರ್ಯ pg_xlog_location_diff() ಎಂದು ಮರುನಾಮಕರಣ ಮಾಡಲಾಯಿತು pg_wal_lsn_diff()._
ನಮಗೂ ಇಲ್ಲಿ ಬಹಳಷ್ಟಿದೆ. ಆದರೆ ನಮಗೆ ಸ್ಥಳಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ವಸ್ತುಗಳು ಮಾತ್ರ ಬೇಕಾಗುತ್ತವೆ.
ಎಲ್ಲಾ ಮೌಲ್ಯಗಳು ಸಮಾನವಾಗಿವೆ ಎಂದು ನಾವು ನೋಡಿದರೆ, ಇದು ಸೂಕ್ತವಾಗಿದೆ ಮತ್ತು ಪ್ರತಿಕೃತಿಯು ಮಾಸ್ಟರ್ಗಿಂತ ಹಿಂದುಳಿಯುವುದಿಲ್ಲ.
ಇಲ್ಲಿ ಈ ಹೆಕ್ಸಾಡೆಸಿಮಲ್ ಸ್ಥಾನವು ವಹಿವಾಟು ಲಾಗ್‌ನಲ್ಲಿನ ಸ್ಥಾನವಾಗಿದೆ. ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಕೆಲವು ಚಟುವಟಿಕೆಯಿದ್ದರೆ ಅದು ನಿರಂತರವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ: ಒಳಸೇರಿಸುತ್ತದೆ, ಅಳಿಸುತ್ತದೆ, ಇತ್ಯಾದಿ.
сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());ಈ ವಿಷಯಗಳು ವಿಭಿನ್ನವಾಗಿದ್ದರೆ, ಕೆಲವು ರೀತಿಯ ವಿಳಂಬವಿದೆ. ಲ್ಯಾಗ್ ಎನ್ನುವುದು ಮಾಸ್ಟರ್‌ನಿಂದ ಪ್ರತಿಕೃತಿಯ ವಿಳಂಬವಾಗಿದೆ, ಅಂದರೆ ಡೇಟಾವು ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಭಿನ್ನವಾಗಿರುತ್ತದೆ.
ವಿಳಂಬಕ್ಕೆ ಮೂರು ಕಾರಣಗಳಿವೆ:
- ಇದು ಫೈಲ್ ಸಿಂಕ್ ರೈಟ್‌ಗಳನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗದ ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯಾಗಿದೆ.
- ಇವುಗಳು ಸಂಭವನೀಯ ನೆಟ್‌ವರ್ಕ್ ದೋಷಗಳು, ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಓವರ್‌ಲೋಡ್, ಡೇಟಾವು ಪ್ರತಿಕೃತಿಯನ್ನು ತಲುಪಲು ಸಮಯ ಹೊಂದಿಲ್ಲ ಮತ್ತು ಅದನ್ನು ಪುನರುತ್ಪಾದಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ.
- ಮತ್ತು ಪ್ರೊಸೆಸರ್. ಪ್ರೊಸೆಸರ್ ಬಹಳ ಅಪರೂಪದ ಪ್ರಕರಣವಾಗಿದೆ. ಮತ್ತು ನಾನು ಅದನ್ನು ಎರಡು ಅಥವಾ ಮೂರು ಬಾರಿ ನೋಡಿದ್ದೇನೆ, ಆದರೆ ಅದು ಸಂಭವಿಸಬಹುದು.
ಮತ್ತು ಅಂಕಿಅಂಶಗಳನ್ನು ಬಳಸಲು ನಮಗೆ ಅನುಮತಿಸುವ ಮೂರು ಪ್ರಶ್ನೆಗಳು ಇಲ್ಲಿವೆ. ನಮ್ಮ ವಹಿವಾಟಿನ ಲಾಗ್‌ನಲ್ಲಿ ಎಷ್ಟು ದಾಖಲಾಗಿದೆ ಎಂದು ನಾವು ಅಂದಾಜು ಮಾಡಬಹುದು. ಅಂತಹ ಒಂದು ಕಾರ್ಯವಿದೆ pg_xlog_location_diff ಮತ್ತು ನಾವು ಬೈಟ್‌ಗಳು ಮತ್ತು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಪ್ರತಿಕೃತಿ ವಿಳಂಬವನ್ನು ಅಂದಾಜು ಮಾಡಬಹುದು. ಇದಕ್ಕಾಗಿ ನಾವು ಈ ವೀಕ್ಷಣೆಯಿಂದ (ವೀಕ್ಷಣೆಗಳು) ಮೌಲ್ಯವನ್ನು ಸಹ ಬಳಸುತ್ತೇವೆ.
ಗಮನಿಸಿ: _ ಬದಲಿಗೆ pg_xlog_locationdiff() ಕಾರ್ಯ, ನೀವು ಕಳೆಯುವ ಆಪರೇಟರ್ ಅನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಒಂದು ಸ್ಥಳವನ್ನು ಇನ್ನೊಂದರಿಂದ ಕಳೆಯಬಹುದು. ಆರಾಮದಾಯಕ.
ವಿಳಂಬದೊಂದಿಗೆ, ಇದು ಸೆಕೆಂಡುಗಳಲ್ಲಿ, ಒಂದು ಕ್ಷಣವಿದೆ. ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಯಾವುದೇ ಚಟುವಟಿಕೆ ಇಲ್ಲದಿದ್ದರೆ, ವಹಿವಾಟು ಸುಮಾರು 15 ನಿಮಿಷಗಳ ಹಿಂದೆ ಇತ್ತು ಮತ್ತು ಯಾವುದೇ ಚಟುವಟಿಕೆಯಿಲ್ಲ, ಮತ್ತು ನಾವು ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಈ ವಿಳಂಬವನ್ನು ನೋಡಿದರೆ, ನಾವು 15 ನಿಮಿಷಗಳ ವಿಳಂಬವನ್ನು ನೋಡುತ್ತೇವೆ. ಇದು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಮತ್ತು ನೀವು ಈ ವಿಳಂಬವನ್ನು ವೀಕ್ಷಿಸಿದಾಗ ಅದು ಮೂರ್ಖತನಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.
pg_stat_all_tables ಮತ್ತೊಂದು ಉಪಯುಕ್ತ ವೀಕ್ಷಣೆಯಾಗಿದೆ. ಇದು ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಅಂಕಿಅಂಶಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಾವು ಕೋಷ್ಟಕಗಳನ್ನು ಹೊಂದಿರುವಾಗ, ಅದರೊಂದಿಗೆ ಕೆಲವು ಚಟುವಟಿಕೆಗಳಿವೆ, ಕೆಲವು ಕ್ರಿಯೆಗಳು, ಈ ವೀಕ್ಷಣೆಯಿಂದ ನಾವು ಈ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು.
select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;ನಾವು ನೋಡಬಹುದಾದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಅನುಕ್ರಮ ಟೇಬಲ್ ಸ್ಕ್ಯಾನ್‌ಗಳು. ಈ ಹಾದಿಗಳ ನಂತರದ ಸಂಖ್ಯೆಯು ಅಗತ್ಯವಾಗಿ ಕೆಟ್ಟದ್ದಲ್ಲ ಮತ್ತು ನಾವು ಈಗಾಗಲೇ ಏನನ್ನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ಸೂಚಿಸುವುದಿಲ್ಲ.
ಆದಾಗ್ಯೂ, ಎರಡನೇ ಮೆಟ್ರಿಕ್ ಇದೆ - seq_tup_read. ಇದು ಅನುಕ್ರಮ ಸ್ಕ್ಯಾನ್‌ನಿಂದ ಹಿಂತಿರುಗಿದ ಸಾಲುಗಳ ಸಂಖ್ಯೆ. ಸರಾಸರಿ ಸಂಖ್ಯೆಯು 1, 000, 10, 000 ಮೀರಿದರೆ, ನೀವು ಎಲ್ಲೋ ಒಂದು ಸೂಚ್ಯಂಕವನ್ನು ನಿರ್ಮಿಸಬೇಕಾಗಬಹುದು ಎಂಬುದಕ್ಕೆ ಇದು ಈಗಾಗಲೇ ಸೂಚಕವಾಗಿದೆ, ಆದ್ದರಿಂದ ಪ್ರವೇಶಗಳು ಸೂಚ್ಯಂಕದಿಂದ ಇರುತ್ತವೆ ಅಥವಾ ಅಂತಹ ಅನುಕ್ರಮ ಸ್ಕ್ಯಾನ್‌ಗಳನ್ನು ಬಳಸುವ ಪ್ರಶ್ನೆಗಳನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ಸಾಧ್ಯವಿದೆ. ಇದು ಸಂಭವಿಸುವುದಿಲ್ಲ.
ಒಂದು ಸರಳ ಉದಾಹರಣೆ - ದೊಡ್ಡ OFFSET ಮತ್ತು ಮಿತಿಯನ್ನು ಹೊಂದಿರುವ ವಿನಂತಿಯು ಯೋಗ್ಯವಾಗಿದೆ ಎಂದು ಹೇಳೋಣ. ಉದಾಹರಣೆಗೆ, ಟೇಬಲ್‌ನಲ್ಲಿ 100 ಸಾಲುಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ನಂತರ 000 ಅಗತ್ಯವಿರುವ ಸಾಲುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಹಿಂದಿನ ಸ್ಕ್ಯಾನ್ ಮಾಡಿದ ಸಾಲುಗಳನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ಇದೂ ಒಂದು ಕೆಟ್ಟ ಪ್ರಕರಣ. ಮತ್ತು ಅಂತಹ ವಿನಂತಿಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಕಾಗಿದೆ. ಮತ್ತು ಇಲ್ಲಿ ಅಂತಹ ಸರಳವಾದ SQL ಪ್ರಶ್ನೆ ಇದೆ, ಅದರಲ್ಲಿ ನೀವು ಅದನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಸ್ವೀಕರಿಸಿದ ಸಂಖ್ಯೆಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು.
select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;ಈ ಟೇಬಲ್ ಬಳಸಿ ಮತ್ತು ಹೆಚ್ಚುವರಿ ಕಾರ್ಯಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಟೇಬಲ್ ಗಾತ್ರಗಳನ್ನು ಸಹ ಪಡೆಯಬಹುದು pg_total_relation_size(), pg_relation_size().
ಸಾಮಾನ್ಯವಾಗಿ, ಮೆಟಾಕಮಾಂಡ್‌ಗಳಿವೆ dt и di, ನೀವು PSQL ನಲ್ಲಿ ಬಳಸಬಹುದು ಮತ್ತು ಟೇಬಲ್ ಮತ್ತು ಇಂಡೆಕ್ಸ್ ಗಾತ್ರಗಳನ್ನು ಸಹ ನೋಡಬಹುದು.
ಆದಾಗ್ಯೂ, ಕಾರ್ಯಗಳ ಬಳಕೆಯು ಕೋಷ್ಟಕಗಳ ಗಾತ್ರಗಳನ್ನು ನೋಡಲು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಸೂಚ್ಯಂಕಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದೆ ಅಥವಾ ಸೂಚ್ಯಂಕಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದೆ, ಮತ್ತು ಡೇಟಾಬೇಸ್ನ ಬೆಳವಣಿಗೆಯ ಆಧಾರದ ಮೇಲೆ ಈಗಾಗಲೇ ಕೆಲವು ಅಂದಾಜುಗಳನ್ನು ಮಾಡಿ, ಅಂದರೆ ಅದು ನಮ್ಮೊಂದಿಗೆ ಹೇಗೆ ಬೆಳೆಯುತ್ತದೆ. ಯಾವ ತೀವ್ರತೆ, ಮತ್ತು ಗಾತ್ರದ ಆಪ್ಟಿಮೈಸೇಶನ್ ಬಗ್ಗೆ ಈಗಾಗಲೇ ಕೆಲವು ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ.
ಚಟುವಟಿಕೆಯನ್ನು ಬರೆಯಿರಿ. ದಾಖಲೆ ಎಂದರೇನು? ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನೋಡೋಣ UPDATE - ಕೋಷ್ಟಕದಲ್ಲಿ ಸಾಲುಗಳನ್ನು ನವೀಕರಿಸುವ ಕಾರ್ಯಾಚರಣೆ. ವಾಸ್ತವವಾಗಿ, ನವೀಕರಣವು ಎರಡು ಕಾರ್ಯಾಚರಣೆಗಳು (ಅಥವಾ ಇನ್ನಷ್ಟು). ಇದು ಹೊಸ ಸಾಲಿನ ಆವೃತ್ತಿಯನ್ನು ಸೇರಿಸುತ್ತಿದೆ ಮತ್ತು ಹಳೆಯ ಸಾಲಿನ ಆವೃತ್ತಿಯನ್ನು ಬಳಕೆಯಲ್ಲಿಲ್ಲ ಎಂದು ಗುರುತಿಸುತ್ತಿದೆ. ನಂತರ, ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಬಂದು ಈ ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಸಾಲುಗಳ ಆವೃತ್ತಿಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುತ್ತದೆ, ಈ ಸ್ಥಳವನ್ನು ಮರುಬಳಕೆಗೆ ಲಭ್ಯವಿದೆ ಎಂದು ಗುರುತಿಸಿ.
ಅಲ್ಲದೆ, ನವೀಕರಣವು ಕೇವಲ ಟೇಬಲ್ ಅನ್ನು ನವೀಕರಿಸುವ ಬಗ್ಗೆ ಅಲ್ಲ. ಇದು ಇನ್ನೂ ಸೂಚ್ಯಂಕ ನವೀಕರಣವಾಗಿದೆ. ನೀವು ಟೇಬಲ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಸೂಚಿಕೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ನವೀಕರಣದೊಂದಿಗೆ, ಪ್ರಶ್ನೆಯಲ್ಲಿ ನವೀಕರಿಸಿದ ಕ್ಷೇತ್ರಗಳು ಭಾಗವಹಿಸುವ ಎಲ್ಲಾ ಸೂಚಿಕೆಗಳನ್ನು ಸಹ ನವೀಕರಿಸಬೇಕಾಗುತ್ತದೆ. ಈ ಸೂಚ್ಯಂಕಗಳು ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಸಾಲು ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಿದ್ದು ಅದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಬೇಕಾಗಿದೆ.
select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;ಮತ್ತು ಅದರ ವಿನ್ಯಾಸದ ಕಾರಣದಿಂದಾಗಿ, ನವೀಕರಣವು ಹೆವಿವೇಯ್ಟ್ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ. ಆದರೆ ಅವುಗಳನ್ನು ಸುಲಭವಾಗಿ ಮಾಡಬಹುದು. ತಿನ್ನು hot updates. ಅವರು PostgreSQL ಆವೃತ್ತಿ 8.3 ರಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡರು. ಮತ್ತು ಇದು ಏನು? ಇದು ಹಗುರವಾದ ನವೀಕರಣವಾಗಿದ್ದು, ಸೂಚ್ಯಂಕಗಳನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಲು ಕಾರಣವಾಗುವುದಿಲ್ಲ. ಅಂದರೆ, ನಾವು ದಾಖಲೆಯನ್ನು ನವೀಕರಿಸಿದ್ದೇವೆ, ಆದರೆ ಪುಟದಲ್ಲಿನ ದಾಖಲೆಯನ್ನು ಮಾತ್ರ ನವೀಕರಿಸಲಾಗಿದೆ (ಇದು ಟೇಬಲ್ಗೆ ಸೇರಿದೆ) ಮತ್ತು ಇಂಡೆಕ್ಸ್‌ಗಳು ಇನ್ನೂ ಪುಟದಲ್ಲಿ ಅದೇ ದಾಖಲೆಯನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಕೆಲಸದ ಅಂತಹ ಆಸಕ್ತಿದಾಯಕ ತರ್ಕವಿದೆ, ನಿರ್ವಾತವು ಬಂದಾಗ, ಅದು ಈ ಸರಪಳಿಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ hot ಮರುನಿರ್ಮಾಣ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸೂಚ್ಯಂಕಗಳನ್ನು ನವೀಕರಿಸದೆ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸುತ್ತದೆ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳ ಕಡಿಮೆ ತ್ಯಾಜ್ಯದೊಂದಿಗೆ ಎಲ್ಲವೂ ನಡೆಯುತ್ತದೆ.
ಮತ್ತು ನೀವು ಹೊಂದಿರುವಾಗ n_tup_hot_upd ದೊಡ್ಡದು, ತುಂಬಾ ಚೆನ್ನಾಗಿದೆ. ಇದರರ್ಥ ಹಗುರವಾದ ನವೀಕರಣಗಳು ಮೇಲುಗೈ ಸಾಧಿಸುತ್ತವೆ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳ ವಿಷಯದಲ್ಲಿ ಇದು ನಮಗೆ ಅಗ್ಗವಾಗಿದೆ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ.
ALTER TABLE table_name SET (fillfactor = 70);ಪರಿಮಾಣವನ್ನು ಹೇಗೆ ಹೆಚ್ಚಿಸುವುದು hot updateಓವ್? ನಾವು ಬಳಸಬಹುದು fillfactor. INSERTಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಟೇಬಲ್‌ನಲ್ಲಿ ಪುಟವನ್ನು ತುಂಬುವಾಗ ಇದು ಕಾಯ್ದಿರಿಸಿದ ಮುಕ್ತ ಜಾಗದ ಗಾತ್ರವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಇನ್ಸರ್ಟ್ಗಳು ಟೇಬಲ್ಗೆ ಹೋದಾಗ, ಅವರು ಸಂಪೂರ್ಣವಾಗಿ ಪುಟವನ್ನು ತುಂಬುತ್ತಾರೆ, ಅದರಲ್ಲಿ ಖಾಲಿ ಜಾಗವನ್ನು ಬಿಡಬೇಡಿ. ನಂತರ ಹೊಸ ಪುಟವನ್ನು ಹೈಲೈಟ್ ಮಾಡಲಾಗುತ್ತದೆ. ಡೇಟಾವನ್ನು ಮತ್ತೆ ತುಂಬಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಇದು ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆ, ಫಿಲ್ಫ್ಯಾಕ್ಟರ್ = 100%.
ನಾವು ಫಿಲ್ಫ್ಯಾಕ್ಟರ್ ಅನ್ನು 70% ಗೆ ಹೊಂದಿಸಬಹುದು. ಅಂದರೆ, ಒಳಸೇರಿಸುವಿಕೆಯೊಂದಿಗೆ, ಹೊಸ ಪುಟವನ್ನು ಹಂಚಲಾಯಿತು, ಆದರೆ ಪುಟದ 70% ಮಾತ್ರ ತುಂಬಿದೆ. ಮತ್ತು ನಮಗೆ 30% ಮೀಸಲು ಉಳಿದಿದೆ. ನೀವು ನವೀಕರಣವನ್ನು ಮಾಡಬೇಕಾದಾಗ, ಅದು ಅದೇ ಪುಟದಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಸಾಲಿನ ಹೊಸ ಆವೃತ್ತಿಯು ಅದೇ ಪುಟದಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತು hot_update ಮಾಡಲಾಗುವುದು. ಇದು ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಬರೆಯಲು ಸುಲಭವಾಗುತ್ತದೆ.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));ಆಟೋವಾಕ್ಯೂಮ್ ಕ್ಯೂ. Autovacuum ಇಂತಹ ಉಪವ್ಯವಸ್ಥೆಯಾಗಿದ್ದು, PostgreSQL ನಲ್ಲಿ ಕೆಲವೇ ಅಂಕಿಅಂಶಗಳಿವೆ. ಈ ಕ್ಷಣದಲ್ಲಿ ನಾವು ಎಷ್ಟು ನಿರ್ವಾತಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು pg_stat_activity ನಲ್ಲಿರುವ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಮಾತ್ರ ನಾವು ನೋಡಬಹುದು. ಆದಾಗ್ಯೂ, ಪ್ರಯಾಣದಲ್ಲಿರುವಾಗ ಅದು ಸರದಿಯಲ್ಲಿ ಎಷ್ಟು ಕೋಷ್ಟಕಗಳನ್ನು ಹೊಂದಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ತುಂಬಾ ಕಷ್ಟ.
ಗಮನಿಸಿ: _ಪೋಸ್ಟ್ಗ್ರೆಸ್ 10 ರಿಂದ, ನಿರ್ವಾತ ನಿರ್ವಾತವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ಪರಿಸ್ಥಿತಿಯು ಬಹಳಷ್ಟು ಸುಧಾರಿಸಿದೆ - pg_stat_progress ವೀಕ್ಷಣೆ ಕಾಣಿಸಿಕೊಂಡಿದೆನಿರ್ವಾತ, ಇದು ಆಟೋವಾಕ್ಯೂಮ್ ಮಾನಿಟರಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ.
ನಾವು ಈ ಸರಳೀಕೃತ ಪ್ರಶ್ನೆಯನ್ನು ಬಳಸಬಹುದು. ಮತ್ತು ನಿರ್ವಾತವನ್ನು ಯಾವಾಗ ಮಾಡಬೇಕೆಂದು ನಾವು ನೋಡಬಹುದು. ಆದರೆ, ನಿರ್ವಾತವನ್ನು ಹೇಗೆ ಮತ್ತು ಯಾವಾಗ ಪ್ರಾರಂಭಿಸಬೇಕು? ಇವುಗಳು ನಾನು ಮೊದಲು ಮಾತನಾಡಿದ ತಂತಿಗಳ ಹಳೆಯ ಆವೃತ್ತಿಗಳಾಗಿವೆ. ನವೀಕರಣ ಸಂಭವಿಸಿದೆ, ಸಾಲಿನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ಸ್ಟ್ರಿಂಗ್‌ನ ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಆವೃತ್ತಿಯು ಕಾಣಿಸಿಕೊಂಡಿದೆ. ಟೇಬಲ್ pg_stat_user_tables ಅಂತಹ ನಿಯತಾಂಕವಿದೆ n_dead_tup. ಇದು "ಸತ್ತ" ಸಾಲುಗಳ ಸಂಖ್ಯೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಮತ್ತು ಸತ್ತ ಸಾಲುಗಳ ಸಂಖ್ಯೆಯು ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಿತಿಗಿಂತ ಹೆಚ್ಚಾದ ತಕ್ಷಣ, ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಟೇಬಲ್ಗೆ ಬರುತ್ತದೆ.
ಮತ್ತು ಈ ಮಿತಿಯನ್ನು ಹೇಗೆ ಲೆಕ್ಕ ಹಾಕಲಾಗುತ್ತದೆ? ಇದು ಕೋಷ್ಟಕದಲ್ಲಿನ ಒಟ್ಟು ಸಾಲುಗಳ ಸಂಖ್ಯೆಯ ನಿರ್ದಿಷ್ಟ ಶೇಕಡಾವಾರು. ಒಂದು ಪ್ಯಾರಾಮೀಟರ್ ಇದೆ autovacuum_vacuum_scale_factor. ಇದು ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. 10% + 50 ಸಾಲುಗಳ ಹೆಚ್ಚುವರಿ ಮೂಲ ಮಿತಿ ಇದೆ ಎಂದು ಹೇಳೋಣ. ಮತ್ತು ಏನಾಗುತ್ತದೆ? ಕೋಷ್ಟಕದಲ್ಲಿನ ಎಲ್ಲಾ ಸಾಲುಗಳ "10% + 50" ಗಿಂತ ಹೆಚ್ಚು ಸತ್ತ ಸಾಲುಗಳನ್ನು ನಾವು ಹೊಂದಿರುವಾಗ, ನಾವು ಟೇಬಲ್ ಅನ್ನು ಆಟೋವಾಕ್ಯೂಮ್ನಲ್ಲಿ ಇರಿಸುತ್ತೇವೆ.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));ಆದಾಗ್ಯೂ, ಒಂದು ಅಂಶವಿದೆ. ನಿಯತಾಂಕಗಳಿಗಾಗಿ ಮೂಲ ಮಿತಿಗಳು av_base_thresh и av_scale_factor ಪ್ರತ್ಯೇಕವಾಗಿ ನಿಯೋಜಿಸಬಹುದು. ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ಮಿತಿ ಜಾಗತಿಕವಾಗಿರುವುದಿಲ್ಲ, ಆದರೆ ಟೇಬಲ್ಗೆ ಪ್ರತ್ಯೇಕವಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು, ಅಲ್ಲಿ ನೀವು ತಂತ್ರಗಳನ್ನು ಮತ್ತು ತಂತ್ರಗಳನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ನೀವು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, Avito ನಿಂದ ನಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳ ಅನುಭವವನ್ನು ನೀವು ನೋಡಬಹುದು (ಸ್ಲೈಡ್‌ನಲ್ಲಿರುವ ಲಿಂಕ್ ಅಮಾನ್ಯವಾಗಿದೆ ಮತ್ತು ಪಠ್ಯದಲ್ಲಿ ನವೀಕರಿಸಲಾಗಿದೆ).
ಅವರು ಬರೆದಿದ್ದಾರೆ ಇದು ಈ ವಿಷಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಎರಡು ಹಾಳೆಗಳ ಮೇಲೆ ಕಾಲುಬಟ್ಟೆ ಇದೆ. ಆದರೆ ಅವರು ಸರಿಯಾಗಿ ಪರಿಗಣಿಸುತ್ತಾರೆ ಮತ್ತು ಸಾಕಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಮಗೆ ಟೇಬಲ್‌ಗಳಿಗೆ ಸಾಕಷ್ಟು ನಿರ್ವಾತ ಎಲ್ಲಿ ಬೇಕು ಎಂದು ನಿರ್ಣಯಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ನಾವು ಅದರ ಬಗ್ಗೆ ಏನು ಮಾಡಬಹುದು? ನಾವು ಉದ್ದವಾದ ಸರತಿಯನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನಾವು ನಿರ್ವಾತ ಕಾರ್ಮಿಕರ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಅಥವಾ ನಿರ್ವಾತವನ್ನು ಹೆಚ್ಚು ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಮಾಡಬಹುದುಇದರಿಂದ ಅದು ಮೊದಲೇ ಪ್ರಚೋದಿಸುತ್ತದೆ, ಟೇಬಲ್ ಅನ್ನು ಸಣ್ಣ ತುಂಡುಗಳಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಹೀಗಾಗಿ ಸರತಿ ಸಾಲು ಕಡಿಮೆಯಾಗುತ್ತದೆ. - ಇಲ್ಲಿ ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಡಿಸ್ಕ್ಗಳಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು, ಏಕೆಂದರೆ. ನಿರ್ವಾತ ವಿಷಯವು ಉಚಿತವಲ್ಲ, ಆದಾಗ್ಯೂ SSD / NVMe ಸಾಧನಗಳ ಆಗಮನದೊಂದಿಗೆ, ಸಮಸ್ಯೆಯು ಕಡಿಮೆ ಗಮನಕ್ಕೆ ಬಂದಿದೆ.
pg_stat_all_indexes ಸೂಚ್ಯಂಕಗಳ ಅಂಕಿಅಂಶಗಳು. ಅವಳು ದೊಡ್ಡವಳಲ್ಲ. ಮತ್ತು ನಾವು ಅದರಿಂದ ಸೂಚ್ಯಂಕಗಳ ಬಳಕೆಯ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು. ಮತ್ತು ಉದಾಹರಣೆಗೆ, ನಾವು ಹೆಚ್ಚುವರಿ ಹೊಂದಿರುವ ಸೂಚ್ಯಂಕಗಳನ್ನು ನಾವು ನಿರ್ಧರಿಸಬಹುದು.
ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ನವೀಕರಣವು ಕೋಷ್ಟಕಗಳನ್ನು ನವೀಕರಿಸುವುದು ಮಾತ್ರವಲ್ಲ, ಇದು ಸೂಚ್ಯಂಕಗಳನ್ನು ನವೀಕರಿಸುತ್ತದೆ. ಅಂತೆಯೇ, ನಾವು ಮೇಜಿನ ಮೇಲೆ ಬಹಳಷ್ಟು ಸೂಚ್ಯಂಕಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಕೋಷ್ಟಕದಲ್ಲಿನ ಸಾಲುಗಳನ್ನು ನವೀಕರಿಸುವಾಗ, ಸೂಚ್ಯಂಕ ಕ್ಷೇತ್ರಗಳ ಸೂಚಿಕೆಗಳನ್ನು ಸಹ ನವೀಕರಿಸಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಸೂಚ್ಯಂಕ ಸ್ಕ್ಯಾನ್‌ಗಳಿಲ್ಲದ ಬಳಕೆಯಾಗದ ಸೂಚಿಕೆಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದರೆ, ಅವು ನಮ್ಮೊಂದಿಗೆ ನಿಲುಭಾರವಾಗಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತವೆ. ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ತೊಡೆದುಹಾಕಬೇಕು. ಇದಕ್ಕಾಗಿ ನಮಗೆ ಒಂದು ಜಾಗ ಬೇಕು idx_scan. ನಾವು ಸೂಚ್ಯಂಕ ಸ್ಕ್ಯಾನ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಾತ್ರ ನೋಡುತ್ತೇವೆ. ಸೂಚ್ಯಂಕಗಳು ತುಲನಾತ್ಮಕವಾಗಿ ದೀರ್ಘಾವಧಿಯ ಅಂಕಿಅಂಶಗಳ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಶೂನ್ಯ ಸ್ಕ್ಯಾನ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ (ಕನಿಷ್ಠ 2-3 ವಾರಗಳು), ಆಗ ಹೆಚ್ಚಾಗಿ ಇವುಗಳು ಕೆಟ್ಟ ಸೂಚ್ಯಂಕಗಳಾಗಿವೆ, ನಾವು ಅವುಗಳನ್ನು ತೊಡೆದುಹಾಕಬೇಕಾಗಿದೆ.
ಗಮನಿಸಿ: ಸ್ಟ್ರೀಮಿಂಗ್ ರೆಪ್ಲಿಕೇಶನ್ ಕ್ಲಸ್ಟರ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಬಳಕೆಯಾಗದ ಸೂಚಿಕೆಗಳನ್ನು ಹುಡುಕುವಾಗ, ನೀವು ಕ್ಲಸ್ಟರ್‌ನ ಎಲ್ಲಾ ನೋಡ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು, ಏಕೆಂದರೆ ಅಂಕಿಅಂಶಗಳು ಜಾಗತಿಕವಾಗಿಲ್ಲ, ಮತ್ತು ಸೂಚ್ಯಂಕವನ್ನು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಬಳಸದಿದ್ದರೆ, ಅದನ್ನು ಪ್ರತಿಕೃತಿಗಳಲ್ಲಿ ಬಳಸಬಹುದು (ಲೋಡ್ ಇದ್ದರೆ).
ಎರಡು ಲಿಂಕ್‌ಗಳು:
ಬಳಕೆಯಾಗದ ಸೂಚ್ಯಂಕಗಳನ್ನು ಹೇಗೆ ನೋಡುವುದು ಎಂಬುದಕ್ಕೆ ಇವು ಹೆಚ್ಚು ಸುಧಾರಿತ ಪ್ರಶ್ನೆ ಉದಾಹರಣೆಗಳಾಗಿವೆ.
ಎರಡನೆಯ ಲಿಂಕ್ ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ಪ್ರಶ್ನೆಯಾಗಿದೆ. ಅದರಲ್ಲಿ ತೀರಾ ಕ್ಷುಲ್ಲಕವಲ್ಲದ ತರ್ಕವಿದೆ. ನಾನು ಅದನ್ನು ವಿಮರ್ಶೆಗೆ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.
ಸೂಚ್ಯಂಕಗಳಿಂದ ಇನ್ನೇನು ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸಬೇಕು?
-
ಬಳಕೆಯಾಗದ ಸೂಚ್ಯಂಕಗಳು ಕೆಟ್ಟದಾಗಿವೆ.
-
ಅವರು ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ.
-
ನವೀಕರಣ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿಧಾನಗೊಳಿಸಿ.
-
ನಿರ್ವಾತಕ್ಕಾಗಿ ಹೆಚ್ಚುವರಿ ಕೆಲಸ.
ನಾವು ಬಳಕೆಯಾಗದ ಸೂಚಿಕೆಗಳನ್ನು ತೆಗೆದುಹಾಕಿದರೆ, ನಾವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮಾತ್ರ ಉತ್ತಮಗೊಳಿಸುತ್ತೇವೆ.
ಮುಂದಿನ ನೋಟ pg_stat_activity. ಇದು ಉಪಯುಕ್ತತೆಯ ಅನಲಾಗ್ ಆಗಿದೆ ps, PostgreSQL ನಲ್ಲಿ ಮಾತ್ರ. ಒಂದು ವೇಳೆ psಓಹ್, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನಲ್ಲಿನ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನೀವು ವೀಕ್ಷಿಸುತ್ತೀರಿ pg_stat_activity PostgreSQL ನಲ್ಲಿನ ಚಟುವಟಿಕೆಯನ್ನು ನಿಮಗೆ ತೋರಿಸುತ್ತದೆ.
ನಾವು ಅಲ್ಲಿಂದ ಏನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು?
select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಡೆಯುತ್ತಿರುವ ಒಟ್ಟಾರೆ ಚಟುವಟಿಕೆಯನ್ನು ನಾವು ನೋಡಬಹುದು. ನಾವು ಹೊಸ ನಿಯೋಜನೆಯನ್ನು ಮಾಡಬಹುದು. ಅಲ್ಲಿ ಎಲ್ಲವೂ ಸ್ಫೋಟಗೊಂಡಿದೆ, ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿಲ್ಲ, ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ದೋಷಗಳು ಸುರಿಯುತ್ತಿವೆ.
select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;ನಾವು ಈ ರೀತಿಯ ಪ್ರಶ್ನೆಯನ್ನು ರನ್ ಮಾಡಬಹುದು ಮತ್ತು ಗರಿಷ್ಠ ಸಂಪರ್ಕ ಮಿತಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಒಟ್ಟು ಶೇಕಡಾವಾರು ಸಂಪರ್ಕಗಳನ್ನು ನೋಡಬಹುದು ಮತ್ತು ನಾವು ಯಾರಿಗೆ ಹೆಚ್ಚು ಸಂಪರ್ಕಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನೋಡಬಹುದು. ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಬಳಕೆದಾರರನ್ನು ನೋಡುತ್ತೇವೆ cron_role 508 ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯಲಾಗಿದೆ. ಮತ್ತು ಅವನಿಗೆ ಏನಾದರೂ ಸಂಭವಿಸಿದೆ. ನೀವು ಅದನ್ನು ನಿಭಾಯಿಸಬೇಕು ಮತ್ತು ನೋಡಬೇಕು. ಮತ್ತು ಇದು ಕೆಲವು ರೀತಿಯ ಅಸಂಗತ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳು ಎಂದು ಸಾಕಷ್ಟು ಸಾಧ್ಯವಿದೆ.
ನಾವು OLTP ಲೋಡ್ ಹೊಂದಿದ್ದರೆ, ಪ್ರಶ್ನೆಗಳು ವೇಗವಾಗಿರಬೇಕು, ತುಂಬಾ ವೇಗವಾಗಿರಬೇಕು ಮತ್ತು ದೀರ್ಘ ಪ್ರಶ್ನೆಗಳು ಇರಬಾರದು. ಹೇಗಾದರೂ, ದೀರ್ಘ ವಿನಂತಿಗಳು ಇದ್ದರೆ, ನಂತರ ಅಲ್ಪಾವಧಿಯಲ್ಲಿ ಚಿಂತೆ ಮಾಡಲು ಏನೂ ಇಲ್ಲ, ಆದರೆ ದೀರ್ಘಾವಧಿಯಲ್ಲಿ, ದೀರ್ಘಾವಧಿಯ ಪ್ರಶ್ನೆಗಳು ಡೇಟಾಬೇಸ್‌ಗೆ ಹಾನಿ ಮಾಡುತ್ತದೆ, ಟೇಬಲ್ ವಿಘಟನೆ ಸಂಭವಿಸಿದಾಗ ಅವು ಕೋಷ್ಟಕಗಳ ಉಬ್ಬುವಿಕೆಯ ಪರಿಣಾಮವನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ. ಉಬ್ಬುವುದು ಮತ್ತು ದೀರ್ಘ ಪ್ರಶ್ನೆಗಳೆರಡನ್ನೂ ವಿಲೇವಾರಿ ಮಾಡಬೇಕಾಗಿದೆ.
select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;ದಯವಿಟ್ಟು ಗಮನಿಸಿ: ಅಂತಹ ವಿನಂತಿಯೊಂದಿಗೆ, ನಾವು ದೀರ್ಘ ವಿನಂತಿಗಳು ಮತ್ತು ವಹಿವಾಟುಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು. ನಾವು ಕಾರ್ಯವನ್ನು ಬಳಸುತ್ತೇವೆ clock_timestamp() ಕೆಲಸದ ಸಮಯವನ್ನು ನಿರ್ಧರಿಸಲು. ನಾವು ಕಂಡುಕೊಂಡ ದೀರ್ಘ ವಿನಂತಿಗಳು, ನಾವು ಅವುಗಳನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಬಹುದು, ಅವುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು explain, ಯೋಜನೆಗಳನ್ನು ನೋಡಿ ಮತ್ತು ಹೇಗಾದರೂ ಆಪ್ಟಿಮೈಜ್ ಮಾಡಿ. ನಾವು ಪ್ರಸ್ತುತ ದೀರ್ಘ ವಿನಂತಿಗಳನ್ನು ಶೂಟ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಬದುಕುತ್ತೇವೆ.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';ಕೆಟ್ಟ ವಹಿವಾಟುಗಳು ವಹಿವಾಟಿನಲ್ಲಿ ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತವೆ ಮತ್ತು ವಹಿವಾಟಿನಲ್ಲಿ ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತವೆ (ನಿರುತ್ಸಾಹಗೊಳಿಸಲಾಗಿದೆ) ವಹಿವಾಟುಗಳು.
ಅದರ ಅರ್ಥವೇನು? ವಹಿವಾಟುಗಳು ಬಹು ರಾಜ್ಯಗಳನ್ನು ಹೊಂದಿವೆ. ಮತ್ತು ಈ ರಾಜ್ಯಗಳಲ್ಲಿ ಒಂದನ್ನು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ರಾಜ್ಯಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಒಂದು ಕ್ಷೇತ್ರವಿದೆ state ಈ ದೃಷ್ಟಿಯಲ್ಲಿ. ಮತ್ತು ರಾಜ್ಯವನ್ನು ನಿರ್ಧರಿಸಲು ನಾವು ಅದನ್ನು ಬಳಸುತ್ತೇವೆ.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';ಮತ್ತು, ನಾನು ಮೇಲೆ ಹೇಳಿದಂತೆ, ಈ ಎರಡು ರಾಜ್ಯಗಳು ವಹಿವಾಟಿನಲ್ಲಿ ಐಡಲ್ ಮತ್ತು ವಹಿವಾಟಿನಲ್ಲಿ ಐಡಲ್ (ನಿರುತ್ಸಾಹಗೊಳಿಸಲಾಗಿದೆ) ಕೆಟ್ಟದು. ಅದು ಏನು? ಅಪ್ಲಿಕೇಶನ್ ವಹಿವಾಟನ್ನು ತೆರೆದಾಗ, ಕೆಲವು ಕ್ರಿಯೆಗಳನ್ನು ಮಾಡಿತು ಮತ್ತು ಅದರ ವ್ಯವಹಾರದ ಬಗ್ಗೆ ಹೋದಾಗ ಇದು. ವಹಿವಾಟು ತೆರೆದಿರುತ್ತದೆ. ಇದು ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ, ಅದರಲ್ಲಿ ಏನೂ ಆಗುವುದಿಲ್ಲ, ಇದು ಸಂಪರ್ಕವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಬದಲಾದ ಸಾಲುಗಳ ಮೇಲೆ ಲಾಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪೋಸ್ಟರ್ಜೆಸ್ ವಹಿವಾಟಿನ ಎಂಜಿನ್ನ ವಾಸ್ತುಶಿಲ್ಪದಿಂದಾಗಿ ಇತರ ಕೋಷ್ಟಕಗಳ ಉಬ್ಬುವಿಕೆಯನ್ನು ಇನ್ನೂ ಹೆಚ್ಚಿಸುತ್ತದೆ. ಮತ್ತು ಅಂತಹ ವಹಿವಾಟುಗಳನ್ನು ಸಹ ಚಿತ್ರೀಕರಿಸಬೇಕು, ಏಕೆಂದರೆ ಅವುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಹಾನಿಕಾರಕವಾಗಿರುತ್ತವೆ, ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ.
ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಅವುಗಳಲ್ಲಿ 5-10-20 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಇರುವುದನ್ನು ನೀವು ನೋಡಿದರೆ, ನೀವು ಚಿಂತಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ಅವರೊಂದಿಗೆ ಏನನ್ನಾದರೂ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಬೇಕು.
ಇಲ್ಲಿ ನಾವು ಲೆಕ್ಕಾಚಾರದ ಸಮಯವನ್ನು ಸಹ ಬಳಸುತ್ತೇವೆ clock_timestamp(). ನಾವು ವಹಿವಾಟುಗಳನ್ನು ಶೂಟ್ ಮಾಡುತ್ತೇವೆ, ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತೇವೆ.
ನಾನು ಮೇಲೆ ಹೇಳಿದಂತೆ, ಎರಡು ಅಥವಾ ಹೆಚ್ಚಿನ ವಹಿವಾಟುಗಳು ಒಂದು ಅಥವಾ ಸಂಪನ್ಮೂಲಗಳ ಗುಂಪಿಗೆ ಸ್ಪರ್ಧಿಸಿದಾಗ ಲಾಕ್‌ಗಳು. ಇದಕ್ಕಾಗಿ ನಮಗೆ ಒಂದು ಜಾಗವಿದೆ waiting ಬೂಲಿಯನ್ ಮೌಲ್ಯದೊಂದಿಗೆ true ಅಥವಾ false.
ನಿಜ - ಇದರರ್ಥ ಪ್ರಕ್ರಿಯೆಯು ಕಾಯುತ್ತಿದೆ, ಏನನ್ನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ. ಪ್ರಕ್ರಿಯೆಯು ಕಾಯುತ್ತಿರುವಾಗ, ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಕ್ಲೈಂಟ್ ಸಹ ಕಾಯುತ್ತಿರುತ್ತಾನೆ. ಬ್ರೌಸರ್‌ನಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ ಕುಳಿತುಕೊಳ್ಳುತ್ತಾನೆ ಮತ್ತು ಕಾಯುತ್ತಾನೆ.
ಎಚ್ಚರಿಕೆ: _Postgres 9.6, ಕ್ಷೇತ್ರದಿಂದ ಪ್ರಾರಂಭಿಸಿ waiting ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಮತ್ತು ಎರಡು ಹೆಚ್ಚು ತಿಳಿವಳಿಕೆ ಕ್ಷೇತ್ರಗಳಿಂದ ಬದಲಾಯಿಸಲಾಗಿದೆ wait_event_type и wait_event._
ಏನು ಮಾಡುವುದು? ನೀವು ದೀರ್ಘಕಾಲದವರೆಗೆ ನಿಜವೆಂದು ನೋಡಿದರೆ, ನೀವು ಅಂತಹ ವಿನಂತಿಗಳನ್ನು ತೊಡೆದುಹಾಕಬೇಕು. ನಾವು ಅಂತಹ ವಹಿವಾಟುಗಳನ್ನು ಶೂಟ್ ಮಾಡುತ್ತೇವೆ. ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಯಾವುದೇ ಓಟವಿಲ್ಲದಂತೆ ಹೇಗಾದರೂ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಕಾದುದನ್ನು ನಾವು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಬರೆಯುತ್ತೇವೆ. ತದನಂತರ ಡೆವಲಪರ್‌ಗಳು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡುತ್ತಾರೆ ಇದರಿಂದ ಇದು ಸಂಭವಿಸುವುದಿಲ್ಲ.
ಮತ್ತು ವಿಪರೀತ, ಆದರೆ ಸಂಭಾವ್ಯವಾಗಿ ಮಾರಣಾಂತಿಕ ಪ್ರಕರಣವಲ್ಲ ಸ್ಥಗಿತಗಳ ಸಂಭವ. ಎರಡು ವಹಿವಾಟುಗಳು ಎರಡು ಸಂಪನ್ಮೂಲಗಳನ್ನು ನವೀಕರಿಸಿವೆ, ನಂತರ ಅವರು ಮತ್ತೆ ಅವುಗಳನ್ನು ಪ್ರವೇಶಿಸುತ್ತಾರೆ, ಈಗಾಗಲೇ ವಿರುದ್ಧವಾದ ಸಂಪನ್ಮೂಲಗಳಿಗೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ PostgreSQL ವಹಿವಾಟನ್ನು ಸ್ವತಃ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಶೂಟ್ ಮಾಡುತ್ತದೆ, ಇದರಿಂದ ಇನ್ನೊಬ್ಬರು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು. ಇದು ಕೊನೆಯ ಪರಿಸ್ಥಿತಿ ಮತ್ತು ಅವಳು ತನ್ನನ್ನು ತಾನೇ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, PostgreSQL ತೀವ್ರ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವಂತೆ ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ.
ಮತ್ತು ಲಾಕ್‌ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಎರಡು ಪ್ರಶ್ನೆಗಳು ಇಲ್ಲಿವೆ. ನಾವು ವೀಕ್ಷಣೆಯನ್ನು ಬಳಸುತ್ತೇವೆ pg_locks, ಇದು ಭಾರೀ ಬೀಗಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಮತ್ತು ಮೊದಲ ಲಿಂಕ್ ವಿನಂತಿಯ ಪಠ್ಯವಾಗಿದೆ. ಇದು ಬಹಳ ಉದ್ದವಾಗಿದೆ.
ಮತ್ತು ಎರಡನೇ ಲಿಂಕ್ ಬೀಗಗಳ ಮೇಲಿನ ಲೇಖನವಾಗಿದೆ. ಇದು ಓದಲು ಉಪಯುಕ್ತವಾಗಿದೆ, ಇದು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ.
ಹಾಗಾದರೆ ನಾವು ಏನು ನೋಡುತ್ತೇವೆ? ನಾವು ಎರಡು ವಿನಂತಿಗಳನ್ನು ನೋಡುತ್ತೇವೆ. ಜೊತೆ ವ್ಯವಹಾರ ALTER TABLE ತಡೆಯುವ ವ್ಯವಹಾರವಾಗಿದೆ. ಇದು ಪ್ರಾರಂಭವಾಯಿತು, ಆದರೆ ಕೊನೆಗೊಂಡಿಲ್ಲ, ಮತ್ತು ಈ ವಹಿವಾಟನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್ ಎಲ್ಲೋ ಇತರ ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತಿದೆ. ಮತ್ತು ಎರಡನೇ ವಿನಂತಿಯು ನವೀಕರಣವಾಗಿದೆ. ಇದು ತನ್ನ ಕೆಲಸವನ್ನು ಮುಂದುವರೆಸುವ ಮೊದಲು ಆಲ್ಟರ್ ಟೇಬಲ್ ಪೂರ್ಣಗೊಳ್ಳಲು ಕಾಯುತ್ತದೆ.
ಯಾರು ಯಾರನ್ನು ಲಾಕ್ ಮಾಡಿದ್ದಾರೆ, ಯಾರು ಯಾರನ್ನು ಹಿಡಿದಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನಾವು ಕಂಡುಹಿಡಿಯಬಹುದು ಮತ್ತು ನಾವು ಇದನ್ನು ಮತ್ತಷ್ಟು ನಿಭಾಯಿಸಬಹುದು.
ಮುಂದಿನ ಮಾಡ್ಯೂಲ್ ಆಗಿದೆ pg_stat_statements. ನಾನು ಹೇಳಿದಂತೆ, ಇದು ಮಾಡ್ಯೂಲ್. ಇದನ್ನು ಬಳಸಲು, ನೀವು ಅದರ ಲೈಬ್ರರಿಯನ್ನು ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ, PostgreSQL ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ, ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ (ಒಂದು ಆಜ್ಞೆಯೊಂದಿಗೆ), ಮತ್ತು ನಂತರ ನಾವು ಹೊಸ ವೀಕ್ಷಣೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ.
Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;
Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;ನಾವು ಅಲ್ಲಿಂದ ಏನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು? ನಾವು ಸರಳ ವಿಷಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ, ನಾವು ಸರಾಸರಿ ಪ್ರಶ್ನೆ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಸಮಯವು ಬೆಳೆಯುತ್ತಿದೆ, ಅಂದರೆ PostgreSQL ನಿಧಾನವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿದೆ ಮತ್ತು ಏನನ್ನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ.
ಹಂಚಿದ ಬಫರ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸುವ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಾವು ಹೆಚ್ಚು ಸಕ್ರಿಯ ಬರವಣಿಗೆ ವಹಿವಾಟುಗಳನ್ನು ನೋಡಬಹುದು. ಅಲ್ಲಿ ಡೇಟಾವನ್ನು ಯಾರು ನವೀಕರಿಸುತ್ತಾರೆ ಅಥವಾ ಅಳಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನೋಡಿ.
ಮತ್ತು ನಾವು ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ವಿವಿಧ ಅಂಕಿಅಂಶಗಳನ್ನು ನೋಡಬಹುದು.
ನಾವು pg_stat_statements ವರದಿಗಳನ್ನು ನಿರ್ಮಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ನಾವು ದಿನಕ್ಕೆ ಒಮ್ಮೆ ಅಂಕಿಅಂಶಗಳನ್ನು ಮರುಹೊಂದಿಸುತ್ತೇವೆ. ಅದನ್ನು ಸಂಗ್ರಹಿಸೋಣ. ಮುಂದಿನ ಬಾರಿ ಅಂಕಿಅಂಶಗಳನ್ನು ಮರುಹೊಂದಿಸುವ ಮೊದಲು, ನಾವು ವರದಿಯನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ. ವರದಿಯ ಲಿಂಕ್ ಇಲ್ಲಿದೆ. ನೀವು ಅದನ್ನು ವೀಕ್ಷಿಸಬಹುದು.
ನಾವೇನು ಮಾಡುತ್ತಿದ್ದೇವೆ? ನಾವು ಎಲ್ಲಾ ಪ್ರಶ್ನೆಗಳಿಗೆ ಒಟ್ಟಾರೆ ಅಂಕಿಅಂಶಗಳನ್ನು ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ. ನಂತರ, ಪ್ರತಿ ಪ್ರಶ್ನೆಗೆ, ಈ ಒಟ್ಟಾರೆ ಅಂಕಿಅಂಶಕ್ಕೆ ಅದರ ವೈಯಕ್ತಿಕ ಕೊಡುಗೆಯನ್ನು ನಾವು ಎಣಿಸುತ್ತೇವೆ.
ಮತ್ತು ನಾವು ಏನು ನೋಡಬಹುದು? ಎಲ್ಲಾ ಇತರ ವಿನಂತಿಗಳ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಪ್ರಕಾರದ ಎಲ್ಲಾ ವಿನಂತಿಗಳ ಒಟ್ಟು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವನ್ನು ನಾವು ನೋಡಬಹುದು. ಒಟ್ಟಾರೆ ಚಿತ್ರಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ನಾವು CPU ಮತ್ತು I/O ಬಳಕೆಯನ್ನು ನೋಡಬಹುದು. ಮತ್ತು ಈಗಾಗಲೇ ಈ ವಿನಂತಿಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು. ನಾವು ಈ ವರದಿಯನ್ನು ಆಧರಿಸಿ ಉನ್ನತ ಪ್ರಶ್ನೆಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಏನನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಬೇಕೆಂಬುದರ ಕುರಿತು ಈಗಾಗಲೇ ಚಿಂತನೆಗೆ ಆಹಾರವನ್ನು ಪಡೆಯುತ್ತಿದ್ದೇವೆ.
ನಾವು ತೆರೆಮರೆಯಲ್ಲಿ ಏನು ಹೊಂದಿದ್ದೇವೆ? ನಾನು ಪರಿಗಣಿಸದ ಕೆಲವು ಸಲ್ಲಿಕೆಗಳು ಇನ್ನೂ ಇವೆ, ಏಕೆಂದರೆ ಸಮಯ ಸೀಮಿತವಾಗಿದೆ.
ಇವೆ pgstattuple ಪ್ರಮಾಣಿತ ಕೊಡುಗೆಗಳ ಪ್ಯಾಕೇಜ್‌ನಿಂದ ಹೆಚ್ಚುವರಿ ಮಾಡ್ಯೂಲ್ ಆಗಿದೆ. ಇದು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ bloat ಕೋಷ್ಟಕಗಳು, ಎಂದು ಕರೆಯಲ್ಪಡುವ. ಟೇಬಲ್ ವಿಘಟನೆ. ಮತ್ತು ವಿಘಟನೆಯು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ನೀವು ಅದನ್ನು ತೆಗೆದುಹಾಕಬೇಕು, ವಿವಿಧ ಸಾಧನಗಳನ್ನು ಬಳಸಿ. ಮತ್ತು ಕಾರ್ಯ pgstattuple ದೀರ್ಘಕಾಲ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಮತ್ತು ಹೆಚ್ಚು ಕೋಷ್ಟಕಗಳು, ಮುಂದೆ ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಮುಂದಿನ ಕೊಡುಗೆ pg_buffercache. ಹಂಚಿದ ಬಫರ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ: ಎಷ್ಟು ತೀವ್ರವಾಗಿ ಮತ್ತು ಯಾವ ಟೇಬಲ್‌ಗಳಿಗೆ ಬಫರ್ ಪುಟಗಳನ್ನು ಬಳಸಲಾಗಿದೆ. ಮತ್ತು ಹಂಚಿದ ಬಫರ್‌ಗಳನ್ನು ನೋಡಲು ಮತ್ತು ಅಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಇದು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಮುಂದಿನ ಮಾಡ್ಯೂಲ್ ಆಗಿದೆ pgfincore. ಸಿಸ್ಟಮ್ ಕರೆ ಮೂಲಕ ಕಡಿಮೆ ಮಟ್ಟದ ಟೇಬಲ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ mincore(), ಅಂದರೆ ಇದು ಟೇಬಲ್ ಅನ್ನು ಹಂಚಿದ ಬಫರ್‌ಗಳಿಗೆ ಲೋಡ್ ಮಾಡಲು ಅಥವಾ ಅದನ್ನು ಅನ್‌ಲೋಡ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಮತ್ತು ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಪುಟ ಸಂಗ್ರಹವನ್ನು ಪರಿಶೀಲಿಸಲು ಇದು ಅನುಮತಿಸುತ್ತದೆ, ಅಂದರೆ, ಪುಟದ ಸಂಗ್ರಹದಲ್ಲಿ, ಹಂಚಿದ ಬಫರ್‌ಗಳಲ್ಲಿ ಟೇಬಲ್ ಎಷ್ಟು ಆಕ್ರಮಿಸಿಕೊಂಡಿದೆ ಮತ್ತು ಮೇಜಿನ ಮೇಲಿನ ಲೋಡ್ ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಮುಂದಿನ ಮಾಡ್ಯೂಲ್ ಆಗಿದೆ pg_stat_kcache. ಇದು ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ಸಹ ಬಳಸುತ್ತದೆ getrusage(). ಮತ್ತು ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು ಮತ್ತು ನಂತರ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಮತ್ತು ಪಡೆದ ಅಂಕಿಅಂಶಗಳಲ್ಲಿ, ಡಿಸ್ಕ್ I / O ನಲ್ಲಿ ನಮ್ಮ ವಿನಂತಿಯನ್ನು ಎಷ್ಟು ಖರ್ಚು ಮಾಡಲಾಗಿದೆ ಎಂದು ಅಂದಾಜು ಮಾಡಲು ಇದು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಅಂದರೆ, ಫೈಲ್ ಸಿಸ್ಟಮ್ನೊಂದಿಗೆ ಕಾರ್ಯಾಚರಣೆಗಳು ಮತ್ತು ಪ್ರೊಸೆಸರ್ ಬಳಕೆಯನ್ನು ನೋಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಮಾಡ್ಯೂಲ್ ಚಿಕ್ಕದಾಗಿದೆ (ಖೆ-ಖೆ) ಮತ್ತು ಅದರ ಕೆಲಸಕ್ಕಾಗಿ ನಾನು ಮೊದಲೇ ಪ್ರಸ್ತಾಪಿಸಿದ PostgreSQL 9.4 ಮತ್ತು pg_stat_statements ಅಗತ್ಯವಿರುತ್ತದೆ.
-
ಅಂಕಿಅಂಶಗಳನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯವು ಉಪಯುಕ್ತವಾಗಿದೆ. ನಿಮಗೆ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಾಫ್ಟ್‌ವೇರ್ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ನೋಡಬಹುದು, ನೋಡಬಹುದು, ಏನನ್ನಾದರೂ ಮಾಡಬಹುದು, ನಿರ್ವಹಿಸಬಹುದು.
-
ಅಂಕಿಅಂಶಗಳನ್ನು ಬಳಸುವುದು ಸುಲಭ, ಇದು ಸರಳ SQL. ನೀವು ವಿನಂತಿಯನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೀರಿ, ಅದನ್ನು ಸಂಕಲಿಸಿದ್ದೀರಿ, ಕಳುಹಿಸಿದ್ದೀರಿ, ಅದನ್ನು ನೋಡಿದ್ದೀರಿ.
-
ಅಂಕಿಅಂಶಗಳು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನೀವು ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಅಂಕಿಅಂಶಗಳಿಗೆ ತಿರುಗಿ - ನೋಡಿ, ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಫಲಿತಾಂಶಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ.
-
ಮತ್ತು ಪ್ರಯೋಗ. ಸಾಕಷ್ಟು ವಿನಂತಿಗಳು, ಸಾಕಷ್ಟು ಡೇಟಾ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೆಲವು ಪ್ರಶ್ನೆಗಳನ್ನು ನೀವು ಯಾವಾಗಲೂ ಆಪ್ಟಿಮೈಜ್ ಮಾಡಬಹುದು. ಮೂಲಕ್ಕಿಂತ ನಿಮಗೆ ಸೂಕ್ತವಾದ ವಿನಂತಿಯ ನಿಮ್ಮ ಸ್ವಂತ ಆವೃತ್ತಿಯನ್ನು ನೀವು ಮಾಡಬಹುದು ಮತ್ತು ಅದನ್ನು ಬಳಸಬಹುದು.
ಉಲ್ಲೇಖಗಳು
ಲೇಖನದಲ್ಲಿ ಕಂಡುಬರುವ ಮಾನ್ಯ ಲಿಂಕ್‌ಗಳು, ಅದರ ಆಧಾರದ ಮೇಲೆ ವರದಿಯಲ್ಲಿವೆ.
ಲೇಖಕರು ಹೆಚ್ಚು ಬರೆಯಿರಿ
(ಇಂಗ್ಲೆಂಡ್)
ಅಂಕಿಅಂಶ ಕಲೆಕ್ಟರ್
ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಷನ್ ಕಾರ್ಯಗಳು
ಕೊಡುಗೆ ಮಾಡ್ಯೂಲ್‌ಗಳು
SQL ಉಪಯುಕ್ತತೆಗಳು ಮತ್ತು sql ಕೋಡ್ ಉದಾಹರಣೆಗಳು
ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಎಲ್ಲರಿಗೂ ಧನ್ಯವಾದಗಳು!
ಮೂಲ: www.habr.com