PostgreSQL ಮಾನಿಟರಿಂಗ್‌ನ ಮೂಲಭೂತ ಅಂಶಗಳು. ಅಲೆಕ್ಸಿ ಲೆಸೊವ್ಸ್ಕಿ

ಡೇಟಾ ಎಗ್ರೆಟ್‌ನಿಂದ ಅಲೆಕ್ಸಿ ಲೆಸೊವ್ಸ್ಕಿಯವರ ವರದಿಯ ಪ್ರತಿಲೇಖನವನ್ನು ಓದಲು ನಾನು ನಿಮಗೆ ಸಲಹೆ ನೀಡುತ್ತೇನೆ “Fundamentals of PostgreSQL Monitoring”

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

ನನ್ನ ಹೆಸರು ಅಲೆಕ್ಸಿ ಲೆಸೊವ್ಸ್ಕಿ, ನಾನು ಡೇಟಾ ಎಗ್ರೆಟ್ ಕಂಪನಿಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತೇನೆ.

ನನ್ನ ಬಗ್ಗೆ ಕೆಲವು ಮಾತುಗಳು. ನಾನು ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಆಗಿ ಬಹಳ ಹಿಂದೆಯೇ ಪ್ರಾರಂಭಿಸಿದೆ.

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

ಮತ್ತು ನನ್ನ ವೃತ್ತಿಜೀವನದುದ್ದಕ್ಕೂ, ನಾನು ಯಾವಾಗಲೂ ಅಂಕಿಅಂಶಗಳು, ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಟೆಲಿಮೆಟ್ರಿ ವಿಷಯಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ. ಮತ್ತು ನಾನು ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಆಗಿದ್ದಾಗ, ನಾನು ಜಬ್ಬಿಕ್ಸ್‌ನೊಂದಿಗೆ ಬಹಳ ನಿಕಟವಾಗಿ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ. ಮತ್ತು ನಾನು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಒಂದು ಸಣ್ಣ ಸೆಟ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ zabbix-ವಿಸ್ತರಣೆಗಳು. ಅವರ ಕಾಲದಲ್ಲಿ ಅವರು ಸಾಕಷ್ಟು ಜನಪ್ರಿಯರಾಗಿದ್ದರು. ಮತ್ತು ಅಲ್ಲಿ ಲಿನಕ್ಸ್ ಮಾತ್ರವಲ್ಲದೆ ವಿವಿಧ ಘಟಕಗಳನ್ನು ಸಹ ವಿಭಿನ್ನವಾದ ಪ್ರಮುಖ ವಿಷಯಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು.

ಈಗ ನಾನು PostgreSQL ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ. PostgreSQL ಅಂಕಿಅಂಶಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಇನ್ನೊಂದು ವಿಷಯವನ್ನು ನಾನು ಈಗಾಗಲೇ ಬರೆಯುತ್ತಿದ್ದೇನೆ. ಇದನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ pgCenter (ಹಾಬ್ರೆ ಕುರಿತು ಲೇಖನ - ನರಗಳು ಮತ್ತು ಉದ್ವೇಗವಿಲ್ಲದೆ ಪೋಸ್ಟ್-ಗ್ರೆಸ್ ಅಂಕಿಅಂಶಗಳು).

ಸ್ವಲ್ಪ ಪರಿಚಯಾತ್ಮಕ ಟಿಪ್ಪಣಿ. ನಮ್ಮ ಗ್ರಾಹಕರು, ನಮ್ಮ ಗ್ರಾಹಕರು ಯಾವ ಸಂದರ್ಭಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ? ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಕೆಲವು ರೀತಿಯ ಅಪಘಾತವಿದೆ. ಮತ್ತು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಈಗಾಗಲೇ ಪುನಃಸ್ಥಾಪಿಸಿದಾಗ, ವಿಭಾಗದ ಮುಖ್ಯಸ್ಥರು ಅಥವಾ ಅಭಿವೃದ್ಧಿಯ ಮುಖ್ಯಸ್ಥರು ಬಂದು ಹೇಳುತ್ತಾರೆ: "ಸ್ನೇಹಿತರೇ, ನಾವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗಿದೆ, ಏಕೆಂದರೆ ಏನಾದರೂ ಕೆಟ್ಟದು ಸಂಭವಿಸಿದೆ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಇದು ಸಂಭವಿಸುವುದನ್ನು ನಾವು ತಡೆಯಬೇಕಾಗಿದೆ." ಮತ್ತು ಇಲ್ಲಿ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವ ಆಸಕ್ತಿದಾಯಕ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಇದರಿಂದ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನೀವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು - PostgreSQL, MySQL ಅಥವಾ ಕೆಲವು. ಮತ್ತು ಸಹೋದ್ಯೋಗಿಗಳು ಸೂಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ: “ಅಂತಹ ಮತ್ತು ಅಂತಹ ಡೇಟಾಬೇಸ್ ಇದೆ ಎಂದು ನಾನು ಕೇಳಿದೆ. ಅದನ್ನು ಉಪಯೋಗಿಸೋಣ." ಸಹೋದ್ಯೋಗಿಗಳು ಪರಸ್ಪರ ವಾದ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ನಾವು ಕೆಲವು ರೀತಿಯ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ, ಆದರೆ PostgreSQL ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಅದರಲ್ಲಿ ಕಳಪೆಯಾಗಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ನಾವು ಯಾವಾಗಲೂ ಏನನ್ನಾದರೂ ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ. GitHub ನಿಂದ ಕೆಲವು ರೆಪೊಸಿಟರಿಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಅವುಗಳನ್ನು ಕ್ಲೋನ್ ಮಾಡಿ, ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಅಳವಡಿಸಿ ಮತ್ತು ಹೇಗಾದರೂ ಕಸ್ಟಮೈಸ್ ಮಾಡಿ. ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಇದು ಕೆಲವು ರೀತಿಯ ಹಸ್ತಚಾಲಿತ ಕೆಲಸವಾಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಆದ್ದರಿಂದ, ಈ ಚರ್ಚೆಯಲ್ಲಿ ನಾನು PostgreSQL ಗಾಗಿ ಮಾತ್ರವಲ್ಲದೆ ಡೇಟಾಬೇಸ್‌ಗೆ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ಸ್ವಲ್ಪ ಜ್ಞಾನವನ್ನು ನೀಡಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಮತ್ತು ನಿಮ್ಮ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ನಿಮಗೆ ಜ್ಞಾನವನ್ನು ನೀಡಿ ಇದರಿಂದ ಸ್ವಲ್ಪ ಲಾಭವನ್ನು ಪಡೆದುಕೊಳ್ಳಬಹುದು, ಇದರಿಂದ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರಯೋಜನದೊಂದಿಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು, ಮುಂಬರುವ ಯಾವುದೇ ತುರ್ತು ಸಂದರ್ಭಗಳನ್ನು ತ್ವರಿತವಾಗಿ ತಡೆಯಲು.

ಮತ್ತು ಈ ವರದಿಯಲ್ಲಿರುವ ವಿಚಾರಗಳನ್ನು ನೇರವಾಗಿ ಯಾವುದೇ ಡೇಟಾಬೇಸ್‌ಗೆ ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದು, ಅದು DBMS ಅಥವಾ noSQL ಆಗಿರಬಹುದು. ಆದ್ದರಿಂದ, PostgreSQL ಮಾತ್ರವಲ್ಲ, PostgreSQL ನಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂಬುದರ ಕುರಿತು ಅನೇಕ ಪಾಕವಿಧಾನಗಳಿವೆ. ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯೂಎಲ್ ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ ಹೊಂದಿರುವ ಪ್ರಶ್ನೆಗಳ ಉದಾಹರಣೆಗಳು, ಘಟಕಗಳ ಉದಾಹರಣೆಗಳು ಇರುತ್ತವೆ. ಮತ್ತು ನಿಮ್ಮ DBMS ಅದೇ ವಿಷಯಗಳನ್ನು ನೀವು ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಇರಿಸಲು ಅನುಮತಿಸಿದರೆ, ನೀವು ಅವುಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದು, ಸೇರಿಸಬಹುದು ಮತ್ತು ಅದು ಉತ್ತಮವಾಗಿರುತ್ತದೆ.

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

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

ಆದ್ದರಿಂದ, ನಮ್ಮ ಅಭ್ಯಾಸದಿಂದ, ನಾವು ಗ್ರಾಹಕರ ಬಳಿಗೆ ಬಂದಾಗ, ಮೇಲ್ವಿಚಾರಣೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಅಪೂರ್ಣವಾಗಿರುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಉತ್ತಮ ಕೆಲಸವನ್ನು ಮಾಡಲು ನಮಗೆ ಸಹಾಯ ಮಾಡುವ ಯಾವುದೇ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಆದ್ದರಿಂದ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಯಾವಾಗಲೂ ಪೂರ್ಣಗೊಳಿಸಬೇಕು.

ಡೇಟಾಬೇಸ್‌ಗಳು ಅಂತಹ ಸಂಕೀರ್ಣ ವಿಷಯಗಳಾಗಿದ್ದು, ಅವುಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಡೇಟಾಬೇಸ್‌ಗಳು ಮಾಹಿತಿಯ ಭಂಡಾರವಾಗಿದೆ. ಮತ್ತು ಕಂಪನಿಗೆ ಮಾಹಿತಿಯು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ; ಅದನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಕಳೆದುಕೊಳ್ಳಲಾಗುವುದಿಲ್ಲ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಡೇಟಾಬೇಸ್ಗಳು ಬಹಳ ಸಂಕೀರ್ಣವಾದ ಸಾಫ್ಟ್ವೇರ್ ತುಣುಕುಗಳಾಗಿವೆ. ಅವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಮತ್ತು ಈ ಅನೇಕ ಘಟಕಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

ನಾವು ವಿಶೇಷವಾಗಿ PostgreSQL ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಅದನ್ನು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಯೋಜನೆಯ ರೂಪದಲ್ಲಿ ಪ್ರತಿನಿಧಿಸಬಹುದು. ಈ ಘಟಕಗಳು ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ, PostgreSQL ಅಂಕಿಅಂಶ ಸಂಗ್ರಾಹಕ ಉಪವ್ಯವಸ್ಥೆ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ, ಇದು ಈ ಉಪವ್ಯವಸ್ಥೆಗಳ ಕಾರ್ಯಾಚರಣೆಯ ಬಗ್ಗೆ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ನಿರ್ವಾಹಕರು ಅಥವಾ ಬಳಕೆದಾರರಿಗೆ ಕೆಲವು ರೀತಿಯ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಒದಗಿಸಲು ಅನುಮತಿಸುತ್ತದೆ ಇದರಿಂದ ಅವರು ಈ ಅಂಕಿಅಂಶಗಳನ್ನು ವೀಕ್ಷಿಸಬಹುದು.

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

ನೀವು ಈ ಸಂಖ್ಯೆಗಳನ್ನು ನಿಮ್ಮ ಮೆಚ್ಚಿನ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ಸೇರಿಸಬಹುದು, ಗ್ರಾಫ್‌ಗಳನ್ನು ಸೆಳೆಯಬಹುದು, ಕಾರ್ಯಗಳನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ದೀರ್ಘಾವಧಿಯಲ್ಲಿ ವಿಶ್ಲೇಷಣೆಗಳನ್ನು ಪಡೆಯಬಹುದು.

ಆದರೆ ಈ ವರದಿಯಲ್ಲಿ ನಾನು ಈ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಇದು ಇಡೀ ದಿನವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ನಾನು ಅಕ್ಷರಶಃ ಎರಡು, ಮೂರು ಅಥವಾ ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ತಿಳಿಸುತ್ತೇನೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ಅವು ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತವೆ ಎಂದು ಹೇಳುತ್ತೇನೆ.

ಮತ್ತು ನಾವು ಡೇಟಾಬೇಸ್ ಮಾನಿಟರಿಂಗ್ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ, ನಂತರ ಏನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು? ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಲಭ್ಯತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗಿದೆ, ಏಕೆಂದರೆ ಡೇಟಾಬೇಸ್ ಗ್ರಾಹಕರಿಗೆ ಡೇಟಾಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುವ ಸೇವೆಯಾಗಿದೆ ಮತ್ತು ನಾವು ಲಭ್ಯತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ಕೆಲವು ಗುಣಾತ್ಮಕ ಮತ್ತು ಪರಿಮಾಣಾತ್ಮಕ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಹ ಒದಗಿಸಬೇಕು.

ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿಸುವ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅವರು ಸಾಮಾನ್ಯ ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗೆ ಹಾನಿ ಮಾಡುವ ಹಾನಿಕಾರಕ ಕ್ಲೈಂಟ್‌ಗಳಾಗಿರಬಹುದು. ಅವರನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು ಮತ್ತು ಅವರ ಚಟುವಟಿಕೆಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

ಕ್ಲೈಂಟ್‌ಗಳು ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿಸಿದಾಗ, ಅವರು ನಮ್ಮ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್‌ಗಳು ಡೇಟಾದೊಂದಿಗೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ: ಯಾವ ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಮತ್ತು ಸ್ವಲ್ಪ ಮಟ್ಟಿಗೆ, ಯಾವ ಸೂಚ್ಯಂಕಗಳೊಂದಿಗೆ. ಅಂದರೆ, ನಮ್ಮ ಗ್ರಾಹಕರು ರಚಿಸಿದ ಕೆಲಸದ ಹೊರೆಯನ್ನು ನಾವು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕಾಗಿದೆ.

ಆದರೆ ಕೆಲಸದ ಹೊರೆಯು ಸಹಜವಾಗಿ ವಿನಂತಿಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತವೆ, ಪ್ರಶ್ನೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಾವು ಯಾವ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು, ಅವುಗಳ ಸಮರ್ಪಕತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು, ಅವು ವಕ್ರವಾಗಿ ಬರೆಯಲಾಗಿಲ್ಲ, ಕೆಲವು ಆಯ್ಕೆಗಳನ್ನು ಪುನಃ ಬರೆಯಬೇಕು ಮತ್ತು ಮಾಡಬೇಕಾಗಿದೆ ಇದರಿಂದ ಅವು ವೇಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಮತ್ತು ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯೊಂದಿಗೆ.

ಮತ್ತು ನಾವು ಡೇಟಾಬೇಸ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿರುವುದರಿಂದ, ಡೇಟಾಬೇಸ್ ಯಾವಾಗಲೂ ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳು. ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳು ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಉತ್ತಮ ಮಟ್ಟದಲ್ಲಿ ನಿರ್ವಹಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅವುಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ನಿರ್ದಿಷ್ಟ ಪ್ರಮಾಣದ ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ, ಅವರು ಕ್ಲೈಂಟ್ ವಿನಂತಿಯ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಅತಿಕ್ರಮಿಸಬಹುದು, ಆದ್ದರಿಂದ ದುರಾಸೆಯ ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳು ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರಬಹುದು. ಆದ್ದರಿಂದ, ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳ ವಿಷಯದಲ್ಲಿ ಯಾವುದೇ ವಿರೂಪಗಳಿಲ್ಲದಂತೆ ಅವುಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

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

ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ ಎಲ್ಲವೂ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಉತ್ತಮವಾಗಿದೆ, ಎಲ್ಲಾ ಆಧುನಿಕ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳು ಈಗಾಗಲೇ ಈ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, ಕೆಲವು ಘಟಕಗಳು ಇನ್ನೂ ಸಾಕಾಗುವುದಿಲ್ಲ ಮತ್ತು ಕೆಲವು ವಿಷಯಗಳನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ. ನಾನು ಅವುಗಳನ್ನು ಸ್ಪರ್ಶಿಸುತ್ತೇನೆ, ಅವುಗಳ ಬಗ್ಗೆ ಹಲವಾರು ಸ್ಲೈಡ್‌ಗಳು ಇರುತ್ತವೆ.

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

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

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

ಈ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳಿಗೆ ನೀವು ಏನು ಸೇರಿಸಬೇಕು? ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯದಂತಹ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ನೀವು ಪ್ರಾರಂಭಿಸಬಹುದು. PostgreSQL pg_stat_statements ವೀಕ್ಷಣೆಯನ್ನು ಹೊಂದಿದೆ. ಇದನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ, ಆದರೆ ಇದು ಯಾವಾಗಲೂ ಸಕ್ರಿಯಗೊಳಿಸಬೇಕಾದ ಮತ್ತು ಬಳಸಬೇಕಾದ ಪ್ರಮುಖ ಸಿಸ್ಟಮ್ ವೀಕ್ಷಣೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾದ ಎಲ್ಲಾ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಶ್ನೆಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಇದು ಸಂಗ್ರಹಿಸುತ್ತದೆ.

ಅಂತೆಯೇ, ನಾವು ಎಲ್ಲಾ ವಿನಂತಿಗಳ ಒಟ್ಟು ಮರಣದಂಡನೆಯ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಮೇಲಿನ ಕ್ಷೇತ್ರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯಿಂದ ಅದನ್ನು ಭಾಗಿಸಬಹುದು ಎಂಬ ಅಂಶದಿಂದ ನಾವು ಪ್ರಾರಂಭಿಸಬಹುದು. ಆದರೆ ಇದು ಆಸ್ಪತ್ರೆಯಲ್ಲಿ ಸರಾಸರಿ ತಾಪಮಾನವಾಗಿದೆ. ನಾವು ಇತರ ಕ್ಷೇತ್ರಗಳಿಂದ ಪ್ರಾರಂಭಿಸಬಹುದು - ಕನಿಷ್ಠ ಪ್ರಶ್ನೆ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸಮಯ, ಗರಿಷ್ಠ ಮತ್ತು ಸರಾಸರಿ. ಮತ್ತು ನಾವು ಶೇಕಡಾವಾರುಗಳನ್ನು ಸಹ ನಿರ್ಮಿಸಬಹುದು; PostgreSQL ಇದಕ್ಕೆ ಅನುಗುಣವಾದ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಈಗಾಗಲೇ ಪೂರ್ಣಗೊಂಡ ವಿನಂತಿಗಳಿಗಾಗಿ ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ನ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ನಿರೂಪಿಸುವ ಕೆಲವು ಸಂಖ್ಯೆಗಳನ್ನು ನಾವು ಪಡೆಯಬಹುದು, ಅಂದರೆ ನಾವು ನಕಲಿ ವಿನಂತಿಯನ್ನು 'ಆಯ್ಕೆ 1' ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದಿಲ್ಲ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ನೋಡುತ್ತೇವೆ, ಆದರೆ ನಾವು ಈಗಾಗಲೇ ಪೂರ್ಣಗೊಂಡ ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ ಮತ್ತು ಸೆಳೆಯುತ್ತೇವೆ. ಪ್ರತ್ಯೇಕ ವ್ಯಕ್ತಿ, ಅಥವಾ ನಾವು ಅದರ ಆಧಾರದ ಮೇಲೆ ಗ್ರಾಫ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ.

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

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

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

ಹಲವಾರು ವಿನಂತಿಗಳು ಒಂದು ವಹಿವಾಟಿಗೆ ಹೊಂದಿಕೆಯಾಗಬಹುದು ಎಂದು ಪ್ರತಿಯೊಬ್ಬರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆಯೇ? ಆದ್ದರಿಂದ TPS ಮತ್ತು QPS ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿವೆ.

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು pg_stat_statements ನಿಂದ ಪಡೆಯಬಹುದು ಮತ್ತು ಎಲ್ಲಾ ಪೂರ್ಣಗೊಂಡ ವಿನಂತಿಗಳ ಮೊತ್ತವನ್ನು ಸರಳವಾಗಿ ಲೆಕ್ಕಹಾಕಬಹುದು. ನಾವು ಪ್ರಸ್ತುತ ಮೌಲ್ಯವನ್ನು ಹಿಂದಿನದರೊಂದಿಗೆ ಹೋಲಿಸುತ್ತೇವೆ, ಅದನ್ನು ಕಳೆಯಿರಿ, ಡೆಲ್ಟಾವನ್ನು ಪಡೆಯಿರಿ ಮತ್ತು ಪ್ರಮಾಣವನ್ನು ಪಡೆಯುತ್ತೇವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.

ಬಯಸಿದಲ್ಲಿ ನೀವು ಹೆಚ್ಚುವರಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸೇರಿಸಬಹುದು, ಇದು ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ನ ಲಭ್ಯತೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಮತ್ತು ಯಾವುದೇ ಅಲಭ್ಯತೆಯನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

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

ನೀವು ನಿರ್ವಾತ ಕಾರ್ಮಿಕರ ಸಂಖ್ಯೆಯನ್ನು ಸಹ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು. PostgreSQL ನಲ್ಲಿ ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಏನೆಂದು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿದೆಯೇ? ಇದು PostgreSQL ನಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕ ಉಪವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಅವಳ ಬಗ್ಗೆ ಅನೇಕ ಲೇಖನಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ, ಅನೇಕ ವರದಿಗಳನ್ನು ಮಾಡಲಾಗಿದೆ. ನಿರ್ವಾತ ಮತ್ತು ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕು ಎಂಬುದರ ಕುರಿತು ಸಾಕಷ್ಟು ಚರ್ಚೆಗಳು ನಡೆಯುತ್ತಿವೆ. ಅನೇಕರು ಇದನ್ನು ಅಗತ್ಯವಾದ ದುಷ್ಟತನವೆಂದು ಪರಿಗಣಿಸುತ್ತಾರೆ. ಆದರೆ ಅದು ಹೇಗಿದೆ. ಇದು ಕಸ ಸಂಗ್ರಾಹಕನ ಒಂದು ರೀತಿಯ ಅನಲಾಗ್ ಆಗಿದ್ದು ಅದು ಯಾವುದೇ ವಹಿವಾಟಿನಿಂದ ಅಗತ್ಯವಿಲ್ಲದ ಸಾಲುಗಳ ಹಳೆಯ ಆವೃತ್ತಿಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಹೊಸ ಸಾಲುಗಳಿಗಾಗಿ ಕೋಷ್ಟಕಗಳು ಮತ್ತು ಸೂಚ್ಯಂಕಗಳಲ್ಲಿ ಜಾಗವನ್ನು ಮುಕ್ತಗೊಳಿಸುತ್ತದೆ.

ನೀವು ಅದನ್ನು ಏಕೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು? ಏಕೆಂದರೆ ನಿರ್ವಾತವು ಕೆಲವೊಮ್ಮೆ ತುಂಬಾ ನೋವುಂಟು ಮಾಡುತ್ತದೆ. ಇದು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳು ಪರಿಣಾಮವಾಗಿ ಬಳಲುತ್ತಿದ್ದಾರೆ.

ಮತ್ತು ಇದನ್ನು pg_stat_activity ವೀಕ್ಷಣೆಯ ಮೂಲಕ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು, ಅದನ್ನು ನಾನು ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ ಮಾತನಾಡುತ್ತೇನೆ. ಈ ವೀಕ್ಷಣೆಯು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಪ್ರಸ್ತುತ ಚಟುವಟಿಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಮತ್ತು ಈ ಚಟುವಟಿಕೆಯ ಮೂಲಕ ನಾವು ಇದೀಗ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ನಿರ್ವಾತಗಳ ಸಂಖ್ಯೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು. ನಾವು ನಿರ್ವಾತಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು ಮತ್ತು ನಾವು ಮಿತಿಯನ್ನು ಮೀರಿದ್ದರೆ, ಇದು PostgreSQL ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನೋಡಲು ಮತ್ತು ನಿರ್ವಾತದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಹೇಗಾದರೂ ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ಒಂದು ಕಾರಣವಾಗಿದೆ.

PostgreSQL ನ ಇನ್ನೊಂದು ವಿಷಯವೆಂದರೆ PostgreSQL ದೀರ್ಘ ವಹಿವಾಟುಗಳಿಂದ ತುಂಬಾ ಅನಾರೋಗ್ಯಕ್ಕೆ ಒಳಗಾಗಿದೆ. ವಿಶೇಷವಾಗಿ ದೀರ್ಘಕಾಲ ಸುತ್ತುವರಿದ ಮತ್ತು ಏನನ್ನೂ ಮಾಡದ ವಹಿವಾಟುಗಳಿಂದ. ಇದು ಸ್ಟಾಟ್ ಐಡಲ್-ಇನ್-ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ. ಅಂತಹ ವ್ಯವಹಾರವು ಬೀಗಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನಿರ್ವಾತವು ಕೆಲಸ ಮಾಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಕೋಷ್ಟಕಗಳು ಉಬ್ಬುತ್ತವೆ ಮತ್ತು ಗಾತ್ರದಲ್ಲಿ ಹೆಚ್ಚಾಗುತ್ತವೆ. ಮತ್ತು ಈ ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಪ್ರಶ್ನೆಗಳು ನಿಧಾನವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ನೀವು ಮೆಮೊರಿಯಿಂದ ಡಿಸ್ಕ್ ಮತ್ತು ಹಿಂದಕ್ಕೆ ಸಾಲುಗಳ ಎಲ್ಲಾ ಹಳೆಯ ಆವೃತ್ತಿಗಳನ್ನು ಸಲಿಕೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಸಮಯ, ಸುದೀರ್ಘ ವಹಿವಾಟಿನ ಅವಧಿ, ದೀರ್ಘಾವಧಿಯ ನಿರ್ವಾತ ವಿನಂತಿಗಳನ್ನು ಸಹ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು OLTP ಲೋಡ್‌ಗಾಗಿ ಈಗಾಗಲೇ 10-20-30 ನಿಮಿಷಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಮಯದಿಂದ ಚಾಲನೆಯಲ್ಲಿರುವ ಕೆಲವು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಾವು ನೋಡಿದರೆ, ನಾವು ಅವುಗಳ ಬಗ್ಗೆ ಗಮನ ಹರಿಸಬೇಕು ಮತ್ತು ಬಲವಂತವಾಗಿ ಅವುಗಳನ್ನು ಕೊನೆಗೊಳಿಸಬೇಕು ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಬೇಕು. ಎಂದು ಕರೆಯಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅಷ್ಟು ಹೊತ್ತು ಸ್ಥಗಿತಗೊಳ್ಳಬೇಡಿ. ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಕೆಲಸದ ಹೊರೆಗಾಗಿ, 10-20-30 ನಿಮಿಷಗಳು ಸಾಮಾನ್ಯವಾಗಿದೆ; ದೀರ್ಘವಾದವುಗಳೂ ಇವೆ.

ಮುಂದೆ ನಾವು ಸಂಪರ್ಕಿತ ಗ್ರಾಹಕರೊಂದಿಗೆ ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಈಗಾಗಲೇ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅನ್ನು ರಚಿಸಿದಾಗ ಮತ್ತು ಅದರಲ್ಲಿ ಪ್ರಮುಖ ಲಭ್ಯತೆಯ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿದಾಗ, ನಾವು ಅಲ್ಲಿ ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್‌ಗಳ ಕುರಿತು ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯನ್ನು ಸೇರಿಸಬಹುದು.

ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್‌ಗಳ ಕುರಿತು ಮಾಹಿತಿಯು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ, PostgreSQL ದೃಷ್ಟಿಕೋನದಿಂದ, ಕ್ಲೈಂಟ್‌ಗಳು ವಿಭಿನ್ನವಾಗಿವೆ. ಒಳ್ಳೆಯ ಗ್ರಾಹಕರಿದ್ದಾರೆ ಮತ್ತು ಕೆಟ್ಟ ಗ್ರಾಹಕರಿದ್ದಾರೆ.

ಒಂದು ಸರಳ ಉದಾಹರಣೆ. ಕ್ಲೈಂಟ್ ಮೂಲಕ ನಾನು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕ ಹೊಂದಿದೆ ಮತ್ತು ತಕ್ಷಣವೇ ಅದರ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಡೇಟಾಬೇಸ್ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಇವರು ಉತ್ತಮ ಮತ್ತು ಸರಿಯಾದ ಗ್ರಾಹಕರು.

ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಾಗ ಸಂದರ್ಭಗಳಿವೆ, ಅದು ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ಇದು ನಿಷ್ಕ್ರಿಯ ಸ್ಥಿತಿಯಲ್ಲಿದೆ.

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

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

ಮೇಲ್ವಿಚಾರಣೆಯ ಮತ್ತೊಂದು ಉದಾಹರಣೆ. ಮತ್ತು ಇಲ್ಲಿ ಈಗಾಗಲೇ ಯೋಗ್ಯವಾದ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಇದೆ. ಮೇಲಿನ ಸಂಪರ್ಕಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿ ಇದೆ. ಡಿಬಿ ಸಂಪರ್ಕ - 8 ತುಣುಕುಗಳು. ಮತ್ತು ಇದು ಎಲ್ಲಾ. ಯಾವ ಕ್ಲೈಂಟ್‌ಗಳು ಸಕ್ರಿಯರಾಗಿದ್ದಾರೆ, ಯಾವ ಕ್ಲೈಂಟ್‌ಗಳು ನಿಷ್ಕ್ರಿಯರಾಗಿದ್ದಾರೆ, ಏನನ್ನೂ ಮಾಡುತ್ತಿಲ್ಲ ಎಂಬ ಬಗ್ಗೆ ನಮಗೆ ಯಾವುದೇ ಮಾಹಿತಿ ಇಲ್ಲ. ಬಾಕಿ ಇರುವ ವಹಿವಾಟುಗಳು ಮತ್ತು ಬಾಕಿ ಇರುವ ಸಂಪರ್ಕಗಳ ಬಗ್ಗೆ ಯಾವುದೇ ಮಾಹಿತಿ ಇಲ್ಲ, ಅಂದರೆ ಇದು ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯನ್ನು ತೋರಿಸುವ ಅಂಕಿ ಮತ್ತು ಅದು ಅಷ್ಟೆ. ತದನಂತರ ನೀವೇ ಊಹಿಸಿ.

ಅಂತೆಯೇ, ಈ ಮಾಹಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆಗೆ ಸೇರಿಸಲು, ನೀವು pg_stat_activity ಸಿಸ್ಟಮ್ ವೀಕ್ಷಣೆಯನ್ನು ಪ್ರವೇಶಿಸಬೇಕಾಗುತ್ತದೆ. ನೀವು PostgreSQL ನಲ್ಲಿ ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆದರೆ, ಇದು ನಿಮ್ಮ ಸ್ನೇಹಿತರಾಗಬೇಕಾದ ಉತ್ತಮ ನೋಟವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು PostgreSQL ನಲ್ಲಿ ಪ್ರಸ್ತುತ ಚಟುವಟಿಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಅಂದರೆ ಅದರಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ. ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೆ ಈ ಪ್ರಕ್ರಿಯೆಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ತೋರಿಸುವ ಪ್ರತ್ಯೇಕ ಸಾಲು ಇರುತ್ತದೆ: ಯಾವ ಹೋಸ್ಟ್‌ನಿಂದ ಸಂಪರ್ಕವನ್ನು ಮಾಡಲಾಗಿದೆ, ಯಾವ ಬಳಕೆದಾರರ ಅಡಿಯಲ್ಲಿ, ಯಾವ ಹೆಸರಿನಲ್ಲಿ, ವಹಿವಾಟು ಯಾವಾಗ ಪ್ರಾರಂಭವಾಯಿತು, ಪ್ರಸ್ತುತ ಯಾವ ವಿನಂತಿಯು ಚಾಲನೆಯಲ್ಲಿದೆ, ಯಾವ ವಿನಂತಿಯನ್ನು ಕೊನೆಯದಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ. ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ನಾವು ಸ್ಟ್ಯಾಟ್ ಕ್ಷೇತ್ರವನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ಲೈಂಟ್ನ ಸ್ಥಿತಿಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು. ತುಲನಾತ್ಮಕವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಾವು ಈ ಕ್ಷೇತ್ರದ ಮೂಲಕ ಗುಂಪು ಮಾಡಬಹುದು ಮತ್ತು ಪ್ರಸ್ತುತ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿರುವ ಅಂಕಿಅಂಶಗಳನ್ನು ಮತ್ತು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಈ ಅಂಕಿಅಂಶವನ್ನು ಹೊಂದಿರುವ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯನ್ನು ಪಡೆಯಬಹುದು. ಮತ್ತು ನಾವು ಈಗಾಗಲೇ ಸ್ವೀಕರಿಸಿದ ಸಂಖ್ಯೆಗಳನ್ನು ನಮ್ಮ ಮೇಲ್ವಿಚಾರಣೆಗೆ ಕಳುಹಿಸಬಹುದು ಮತ್ತು ಅವುಗಳ ಆಧಾರದ ಮೇಲೆ ಗ್ರಾಫ್ಗಳನ್ನು ಸೆಳೆಯಬಹುದು.
ವಹಿವಾಟಿನ ಅವಧಿಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಸಹ ಮುಖ್ಯವಾಗಿದೆ. ನಿರ್ವಾತಗಳ ಅವಧಿಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಮುಖ್ಯ ಎಂದು ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದ್ದೇನೆ, ಆದರೆ ವಹಿವಾಟುಗಳನ್ನು ಅದೇ ರೀತಿಯಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತದೆ. xact_start ಮತ್ತು query_start ಕ್ಷೇತ್ರಗಳಿವೆ. ಅವರು, ತುಲನಾತ್ಮಕವಾಗಿ ಹೇಳುವುದಾದರೆ, ವಹಿವಾಟಿನ ಪ್ರಾರಂಭದ ಸಮಯ ಮತ್ತು ವಿನಂತಿಯ ಪ್ರಾರಂಭದ ಸಮಯವನ್ನು ತೋರಿಸುತ್ತಾರೆ. ನಾವು ಈಗ() ಕಾರ್ಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಇದು ಪ್ರಸ್ತುತ ಸಮಯಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ ಮತ್ತು ವಹಿವಾಟು ಮತ್ತು ವಿನಂತಿಯ ಸಮಯಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಕಳೆಯಿರಿ. ಮತ್ತು ನಾವು ವಹಿವಾಟಿನ ಅವಧಿಯನ್ನು, ವಿನಂತಿಯ ಅವಧಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ.

ನಾವು ದೀರ್ಘ ವಹಿವಾಟುಗಳನ್ನು ನೋಡಿದರೆ, ನಾವು ಅವುಗಳನ್ನು ಈಗಾಗಲೇ ಪೂರ್ಣಗೊಳಿಸಬೇಕು. OLTP ಲೋಡ್‌ಗಾಗಿ, ದೀರ್ಘ ವಹಿವಾಟುಗಳು ಈಗಾಗಲೇ 1-2-3 ನಿಮಿಷಗಳಿಗಿಂತ ಹೆಚ್ಚು. OLAP ಕೆಲಸದ ಹೊರೆಗಾಗಿ, ದೀರ್ಘ ವಹಿವಾಟುಗಳು ಸಾಮಾನ್ಯವಾಗಿದೆ, ಆದರೆ ಅವು ಪೂರ್ಣಗೊಳ್ಳಲು ಎರಡು ಗಂಟೆಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡರೆ, ಇದು ನಮಗೆ ಎಲ್ಲೋ ಒಂದು ಓರೆಯಾಗಿದೆ ಎಂಬುದರ ಸಂಕೇತವಾಗಿದೆ.

ಕ್ಲೈಂಟ್‌ಗಳು ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡ ನಂತರ, ಅವರು ನಮ್ಮ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಅವರು ಕೋಷ್ಟಕಗಳನ್ನು ಪ್ರವೇಶಿಸುತ್ತಾರೆ, ಅವರು ಕೋಷ್ಟಕದಿಂದ ಡೇಟಾವನ್ನು ಪಡೆಯಲು ಸೂಚ್ಯಂಕಗಳನ್ನು ಪ್ರವೇಶಿಸುತ್ತಾರೆ. ಮತ್ತು ಗ್ರಾಹಕರು ಈ ಡೇಟಾದೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಮುಖ್ಯವಾಗಿದೆ.

ನಮ್ಮ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಮತ್ತು ಯಾವ ಕೋಷ್ಟಕಗಳು ನಮಗೆ "ಹೆಚ್ಚು" ಎಂದು ಸ್ಥೂಲವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ಅವಶ್ಯಕವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಕೆಲವು ರೀತಿಯ ವೇಗದ SSD ಸಂಗ್ರಹಣೆಯಲ್ಲಿ "ಬಿಸಿ" ಕೋಷ್ಟಕಗಳನ್ನು ಇರಿಸಲು ಬಯಸುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ದೀರ್ಘಕಾಲ ಬಳಸದ ಕೆಲವು ಆರ್ಕೈವ್ ಕೋಷ್ಟಕಗಳನ್ನು ಕೆಲವು ರೀತಿಯ "ಶೀತ" ಆರ್ಕೈವ್‌ಗೆ, SATA ಡ್ರೈವ್‌ಗಳಿಗೆ ಸರಿಸಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಅಲ್ಲಿ ವಾಸಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಡಿ, ಅಗತ್ಯವಿರುವಂತೆ ಅವುಗಳನ್ನು ಪ್ರವೇಶಿಸಲಾಗುತ್ತದೆ.

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

"ಫ್ಲೋಟಿಂಗ್" ಅಂಕಿಅಂಶಗಳಲ್ಲಿ ನೀವು ವೈಪರೀತ್ಯಗಳನ್ನು ಸಹ ಕಂಡುಹಿಡಿಯಬಹುದು. ಅದರ ಅರ್ಥವೇನು? PostgreSQL ಅತ್ಯಂತ ಬಲವಾದ ಮತ್ತು ಉತ್ತಮವಾದ ಪ್ರಶ್ನೆ ಯೋಜಕವನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಅಭಿವರ್ಧಕರು ಅದರ ಅಭಿವೃದ್ಧಿಗೆ ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ವಿನಿಯೋಗಿಸುತ್ತಾರೆ. ಅವನು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾನೆ? ಉತ್ತಮ ಯೋಜನೆಗಳನ್ನು ಮಾಡಲು, PostgreSQL ನಿರ್ದಿಷ್ಟ ಸಮಯದ ಮಧ್ಯಂತರದಲ್ಲಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಆವರ್ತನದೊಂದಿಗೆ ಕೋಷ್ಟಕಗಳಲ್ಲಿನ ಡೇಟಾದ ವಿತರಣೆಯ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಇವುಗಳು ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಮೌಲ್ಯಗಳಾಗಿವೆ: ಅನನ್ಯ ಮೌಲ್ಯಗಳ ಸಂಖ್ಯೆ, ಕೋಷ್ಟಕದಲ್ಲಿ NULL ಬಗ್ಗೆ ಮಾಹಿತಿ, ಬಹಳಷ್ಟು ಮಾಹಿತಿ.

ಈ ಅಂಕಿಅಂಶಗಳ ಆಧಾರದ ಮೇಲೆ, ಯೋಜಕರು ಹಲವಾರು ಪ್ರಶ್ನೆಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ, ಹೆಚ್ಚು ಸೂಕ್ತವಾದದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಪ್ರಶ್ನೆಯನ್ನು ಸ್ವತಃ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತು ಡೇಟಾವನ್ನು ಹಿಂತಿರುಗಿಸಲು ಈ ಪ್ರಶ್ನೆ ಯೋಜನೆಯನ್ನು ಬಳಸುತ್ತಾರೆ.

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

ಮತ್ತು ನಾವು ಇದನ್ನು ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ನೋಡಬಹುದು. ಮತ್ತು ಈಗಾಗಲೇ ಈ ಪ್ರಶ್ನೆಯನ್ನು ನೋಡಿ, ಅದರ ವಿವರಣೆಯನ್ನು ರನ್ ಮಾಡಿ, ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ, ಹೊಸ ಹೆಚ್ಚುವರಿ ಸೂಚ್ಯಂಕವನ್ನು ನಿರ್ಮಿಸಿ. ಮತ್ತು ಈಗಾಗಲೇ ಈ ಸಮಸ್ಯೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿ. ಅದಕ್ಕಾಗಿಯೇ ಇದು ಮುಖ್ಯವಾಗಿದೆ.

ಮೇಲ್ವಿಚಾರಣೆಯ ಮತ್ತೊಂದು ಉದಾಹರಣೆ. ಅವನು ಬಹಳ ಜನಪ್ರಿಯನಾಗಿರುವುದರಿಂದ ಅನೇಕ ಜನರು ಅವನನ್ನು ಗುರುತಿಸಿದ್ದಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಯಾರು ಅದನ್ನು ತಮ್ಮ ಯೋಜನೆಗಳಲ್ಲಿ ಬಳಸುತ್ತಾರೆ ಪ್ರಮೀತಿಯಸ್? ಪ್ರಮೀತಿಯಸ್ ಜೊತೆಯಲ್ಲಿ ಈ ಉತ್ಪನ್ನವನ್ನು ಯಾರು ಬಳಸುತ್ತಾರೆ? ವಾಸ್ತವವೆಂದರೆ ಈ ಮಾನಿಟರಿಂಗ್‌ನ ಪ್ರಮಾಣಿತ ಭಂಡಾರದಲ್ಲಿ PostgreSQL ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಇದೆ - postgres_exporter ಪ್ರಮೀತಿಯಸ್. ಆದರೆ ಒಂದು ಕೆಟ್ಟ ವಿವರವಿದೆ.

ಹಲವಾರು ಗ್ರಾಫ್‌ಗಳಿವೆ. ಮತ್ತು ಬೈಟ್‌ಗಳನ್ನು ಏಕತೆ ಎಂದು ಸೂಚಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ 5 ಗ್ರಾಫ್‌ಗಳಿವೆ. ಅವುಗಳೆಂದರೆ ಡೇಟಾ ಸೇರಿಸು, ಡೇಟಾವನ್ನು ನವೀಕರಿಸಿ, ಡೇಟಾವನ್ನು ಅಳಿಸಿ, ಡೇಟಾವನ್ನು ಪಡೆದುಕೊಳ್ಳಿ ಮತ್ತು ಡೇಟಾವನ್ನು ಹಿಂತಿರುಗಿ. ಘಟಕ ಮಾಪನವು ಬೈಟ್‌ಗಳು. ಆದರೆ ವಿಷಯವೆಂದರೆ PostgreSQL ನಲ್ಲಿನ ಅಂಕಿಅಂಶಗಳು ಟುಪಲ್ (ಸಾಲುಗಳು) ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ಈ ಗ್ರಾಫ್‌ಗಳು ನಿಮ್ಮ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಹಲವಾರು ಬಾರಿ, ಹತ್ತಾರು ಬಾರಿ ಕಡಿಮೆ ಅಂದಾಜು ಮಾಡಲು ಉತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ, ಏಕೆಂದರೆ ಟುಪಲ್ ಬೈಟ್ ಅಲ್ಲ, ಟ್ಯೂಪಲ್ ಒಂದು ಸ್ಟ್ರಿಂಗ್, ಇದು ಅನೇಕ ಬೈಟ್‌ಗಳು ಮತ್ತು ಇದು ಯಾವಾಗಲೂ ವೇರಿಯಬಲ್ ಉದ್ದವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಅಂದರೆ, ಟುಪಲ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಬೈಟ್‌ಗಳಲ್ಲಿ ಕೆಲಸದ ಹೊರೆ ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು ಅವಾಸ್ತವಿಕ ಕೆಲಸ ಅಥವಾ ತುಂಬಾ ಕಷ್ಟ. ಆದ್ದರಿಂದ, ನೀವು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅಥವಾ ಅಂತರ್ನಿರ್ಮಿತ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಬಳಸುವಾಗ, ಅದು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಸರಿಯಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದ ಡೇಟಾವನ್ನು ನಿಮಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಯಾವಾಗಲೂ ಮುಖ್ಯವಾಗಿದೆ.

ಈ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಅಂಕಿಅಂಶಗಳನ್ನು ಹೇಗೆ ಪಡೆಯುವುದು? ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, PostgreSQL ಒಂದು ನಿರ್ದಿಷ್ಟ ಕುಟುಂಬದ ವೀಕ್ಷಣೆಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಮುಖ್ಯ ನೋಟ pg_stat_user_tables. User_tables - ಇದರರ್ಥ ಬಳಕೆದಾರರ ಪರವಾಗಿ ರಚಿಸಲಾದ ಕೋಷ್ಟಕಗಳು. ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, PostgreSQL ಸ್ವತಃ ಬಳಸುವ ಸಿಸ್ಟಮ್ ವೀಕ್ಷಣೆಗಳಿವೆ. ಮತ್ತು ಆಲ್ಟೇಬಲ್‌ಗಳ ಸಾರಾಂಶ ಕೋಷ್ಟಕವಿದೆ, ಇದು ಸಿಸ್ಟಮ್ ಮತ್ತು ಬಳಕೆದಾರರ ಎರಡನ್ನೂ ಒಳಗೊಂಡಿರುತ್ತದೆ. ನೀವು ಇಷ್ಟಪಡುವ ಯಾವುದನ್ನಾದರೂ ನೀವು ಪ್ರಾರಂಭಿಸಬಹುದು.

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

ಈ ಡೇಟಾವನ್ನು ಆಧರಿಸಿ, ನಾವು TopN ಕೋಷ್ಟಕಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಟಾಪ್-5, ಟಾಪ್-10. ಮತ್ತು ಇತರರಿಗಿಂತ ಹೆಚ್ಚು ಮರುಬಳಕೆ ಮಾಡಲಾದ ಬಿಸಿ ಕೋಷ್ಟಕಗಳನ್ನು ನೀವು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು. ಉದಾಹರಣೆಗೆ, ಅಳವಡಿಕೆಗಾಗಿ 5 "ಬಿಸಿ" ಕೋಷ್ಟಕಗಳು. ಮತ್ತು ಈ ಟಾಪ್‌ಎನ್ ಕೋಷ್ಟಕಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ನಮ್ಮ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಯಾವುದೇ ಬಿಡುಗಡೆಗಳು, ನವೀಕರಣಗಳು ಮತ್ತು ನಿಯೋಜನೆಗಳ ನಂತರ ಕೆಲಸದ ಹೊರೆಯ ಸ್ಫೋಟಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು.

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

ಮತ್ತು ಈಗ ನಿಮಗಾಗಿ ಒಂದು ಸಣ್ಣ ಪ್ರಶ್ನೆ. ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ನೀವು ಗಮನಿಸಿದಾಗ ಯಾವ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ? ನಿಮ್ಮ ಮುಂದಿನ ಪ್ರಶ್ನೆ ಏನು?

ಆದರೆ ವಾಸ್ತವವಾಗಿ ಪ್ರಶ್ನೆಯು ಈ ಕೆಳಗಿನಂತೆ ಉದ್ಭವಿಸುತ್ತದೆ. ಲೋಡ್ ಯಾವ ವಿನಂತಿಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ? ಅಂದರೆ, ಹೊರೆಯಿಂದ ಉಂಟಾಗುವ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನೋಡಲು ಆಸಕ್ತಿದಾಯಕವಲ್ಲ. ಹೋಸ್ಟ್ ಡೇಟಾಬೇಸ್ ಹೊಂದಿದ್ದರೆ, ಡೇಟಾಬೇಸ್ ಅಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಮಾತ್ರ ಅಲ್ಲಿ ವಿಲೇವಾರಿ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಾವು ಟಾಪ್ ಅನ್ನು ತೆರೆದರೆ, PostgreSQL ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಮಾಡುತ್ತಿರುವ ಪ್ರಕ್ರಿಯೆಗಳ ಪಟ್ಟಿಯನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ಅವರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದು ಟಾಪ್‌ನಿಂದ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.

ಅಂತೆಯೇ, ಹೆಚ್ಚಿನ ಹೊರೆಗೆ ಕಾರಣವಾಗುವ ಪ್ರಶ್ನೆಗಳನ್ನು ನೀವು ಕಂಡುಹಿಡಿಯಬೇಕು, ಏಕೆಂದರೆ ಟ್ಯೂನಿಂಗ್ ಪ್ರಶ್ನೆಗಳು ನಿಯಮದಂತೆ, PostgreSQL ಅಥವಾ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಟ್ಯೂನ್ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಲಾಭವನ್ನು ನೀಡುತ್ತದೆ ಅಥವಾ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಟ್ಯೂನ್ ಮಾಡುತ್ತವೆ. ನನ್ನ ಅಂದಾಜಿನ ಪ್ರಕಾರ, ಇದು ಸರಿಸುಮಾರು 80-85-90% ಆಗಿದೆ. ಮತ್ತು ಇದನ್ನು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ. ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದಕ್ಕಿಂತ ವಿನಂತಿಯನ್ನು ಸರಿಪಡಿಸಲು ಇದು ವೇಗವಾಗಿರುತ್ತದೆ, ಮರುಪ್ರಾರಂಭವನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಅಥವಾ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಸೇರಿಸುವುದು. ಈ ಪ್ರಶ್ನೆಯಿಂದ ಉತ್ತಮ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯಲು ಪ್ರಶ್ನೆಯನ್ನು ಎಲ್ಲೋ ಪುನಃ ಬರೆಯುವುದು ಅಥವಾ ಸೂಚ್ಯಂಕವನ್ನು ಸೇರಿಸುವುದು ಸುಲಭ.

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

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

ನೀವು ದೀರ್ಘವಾದ ಪ್ರಶ್ನೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು, ಅಂದರೆ, ಪೂರ್ಣಗೊಳ್ಳಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಪ್ರಶ್ನೆಗಳು. ಅವರು ಪ್ರೊಸೆಸರ್ನಲ್ಲಿ ರನ್ ಮಾಡುತ್ತಾರೆ, ಅವರು I/O ಅನ್ನು ಸೇವಿಸುತ್ತಾರೆ. ಒಟ್ಟು_ಸಮಯ, ಸರಾಸರಿ_ಸಮಯ, blk_write_time ಮತ್ತು blk_read_time ಕ್ಷೇತ್ರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಇದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು.

ಸಂಪನ್ಮೂಲ ಬಳಕೆ, ಡಿಸ್ಕ್‌ನಿಂದ ಓದುವ, ಮೆಮೊರಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ, ಅಥವಾ ಪ್ರತಿಯಾಗಿ, ಕೆಲವು ರೀತಿಯ ಬರವಣಿಗೆಯ ಲೋಡ್ ಅನ್ನು ರಚಿಸುವ ವಿಷಯದಲ್ಲಿ ನಾವು ಭಾರೀ ವಿನಂತಿಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು.

ನಾವು ಅತ್ಯಂತ ಉದಾರವಾದ ವಿನಂತಿಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು. ಇವುಗಳು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಾಲುಗಳನ್ನು ಹಿಂದಿರುಗಿಸುವ ಪ್ರಶ್ನೆಗಳಾಗಿವೆ. ಉದಾಹರಣೆಗೆ, ಇದು ಕೆಲವು ವಿನಂತಿಯಾಗಿರಬಹುದು, ಅಲ್ಲಿ ಅವರು ಮಿತಿಯನ್ನು ಹೊಂದಿಸಲು ಮರೆತಿದ್ದಾರೆ. ಮತ್ತು ಇದು ಟೇಬಲ್‌ನ ಸಂಪೂರ್ಣ ವಿಷಯಗಳನ್ನು ಅಥವಾ ಪ್ರಶ್ನಿಸಿದ ಕೋಷ್ಟಕಗಳಾದ್ಯಂತ ಪ್ರಶ್ನೆಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ಮತ್ತು ನೀವು ತಾತ್ಕಾಲಿಕ ಫೈಲ್‌ಗಳು ಅಥವಾ ತಾತ್ಕಾಲಿಕ ಕೋಷ್ಟಕಗಳನ್ನು ಬಳಸುವ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಹ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು.

ಮತ್ತು ನಾವು ಇನ್ನೂ ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳು ಪ್ರಾಥಮಿಕವಾಗಿ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳು ಅಥವಾ ಅವುಗಳನ್ನು ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳು ಎಂದೂ ಕರೆಯುತ್ತಾರೆ, ಇವು ಆಟೋವಾಕ್ಯೂಮ್ ಮತ್ತು ರೆಪ್ಲಿಕೇಶನ್.

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

ನಾವು ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ನೋಡಿದಾಗ, ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳು ಚೂರುಚೂರು ಮೆಮೊರಿ ಪ್ರದೇಶದಿಂದ ಡಿಸ್ಕ್‌ಗೆ ಕೊಳಕು ಪುಟಗಳನ್ನು ಫ್ಲಶ್ ಮಾಡುತ್ತದೆ, ನಂತರ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ರಚಿಸಿ. ಮತ್ತು ತುರ್ತು ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ PostgreSQL ಅನ್ನು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಕೊನೆಗೊಳಿಸಿದರೆ ಈ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಚೇತರಿಕೆಯ ಸ್ಥಳವಾಗಿ ಬಳಸಬಹುದು.

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

ಅಂತೆಯೇ, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಕ್ಷೇತ್ರಗಳನ್ನು ಬಳಸಿಕೊಂಡು pg_stat_bgwriter ಮೂಲಕ ನಾವು ಸಂಭವಿಸುವ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು. ಮತ್ತು ನಾವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಅವಧಿಯಲ್ಲಿ (10-15-20 ನಿಮಿಷಗಳಲ್ಲಿ, ಅರ್ಧ ಗಂಟೆಯಲ್ಲಿ) ಸಾಕಷ್ಟು ಚೆಕ್ಪಾಯಿಂಟ್ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, 3-4-5, ಆಗ ಇದು ಈಗಾಗಲೇ ಸಮಸ್ಯೆಯಾಗಿರಬಹುದು. ಮತ್ತು ನೀವು ಈಗಾಗಲೇ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನೋಡಬೇಕು, ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ನೋಡಿ, ಅಂತಹ ಹೇರಳವಾದ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳಿಗೆ ಕಾರಣವೇನು. ಬಹುಶಃ ಕೆಲವು ರೀತಿಯ ದೊಡ್ಡ ರೆಕಾರ್ಡಿಂಗ್ ನಡೆಯುತ್ತಿದೆ. ನಾವು ಈಗಾಗಲೇ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು, ಏಕೆಂದರೆ ನಾವು ಈಗಾಗಲೇ ಕೆಲಸದ ಹೊರೆ ಗ್ರಾಫ್ಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ನಾವು ಈಗಾಗಲೇ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ತಿರುಚಬಹುದು ಮತ್ತು ಅವು ಪ್ರಶ್ನೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ನಾನು ಮತ್ತೊಮ್ಮೆ ಆಟೊವಾಕ್ಯೂಮ್‌ಗೆ ಹಿಂತಿರುಗುತ್ತಿದ್ದೇನೆ ಏಕೆಂದರೆ ಇದು ಡಿಸ್ಕ್ ಮತ್ತು ಪ್ರಶ್ನೆ ಕಾರ್ಯಕ್ಷಮತೆ ಎರಡನ್ನೂ ಸುಲಭವಾಗಿ ಸೇರಿಸಬಹುದು, ಆದ್ದರಿಂದ ಆಟೋವ್ಯಾಕ್ಯೂಮ್‌ನ ಪ್ರಮಾಣವನ್ನು ಅಂದಾಜು ಮಾಡುವುದು ಯಾವಾಗಲೂ ಮುಖ್ಯವಾಗಿದೆ.

ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಕೆಲಸಗಾರರ ಸಂಖ್ಯೆ ಸೀಮಿತವಾಗಿದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಅವುಗಳಲ್ಲಿ ಮೂರು ಇವೆ, ಆದ್ದರಿಂದ ನಾವು ಯಾವಾಗಲೂ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಮೂರು ಕೆಲಸಗಾರರನ್ನು ಹೊಂದಿದ್ದರೆ, ಇದರರ್ಥ ನಮ್ಮ ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿಲ್ಲ, ನಾವು ಮಿತಿಗಳನ್ನು ಹೆಚ್ಚಿಸಬೇಕು, ಆಟೋವಾಕ್ಯೂಮ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪರಿಷ್ಕರಿಸಬೇಕು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಹೋಗಬೇಕು.
ನಾವು ಯಾವ ನಿರ್ವಾತ ಕೆಲಸಗಾರರನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಒಂದೋ ಅದನ್ನು ಬಳಕೆದಾರರಿಂದ ಪ್ರಾರಂಭಿಸಲಾಯಿತು, DBA ಬಂದು ಕೈಯಾರೆ ಕೆಲವು ರೀತಿಯ ನಿರ್ವಾತವನ್ನು ಪ್ರಾರಂಭಿಸಿತು ಮತ್ತು ಇದು ಲೋಡ್ ಅನ್ನು ರಚಿಸಿತು. ನಮಗೆ ಕೆಲವು ರೀತಿಯ ಸಮಸ್ಯೆ ಇದೆ. ಅಥವಾ ಇದು ವಹಿವಾಟು ಕೌಂಟರ್ ಅನ್ನು ತಿರುಗಿಸದ ನಿರ್ವಾತಗಳ ಸಂಖ್ಯೆ. PostgreSQL ನ ಕೆಲವು ಆವೃತ್ತಿಗಳಿಗೆ ಇವು ತುಂಬಾ ಭಾರವಾದ ನಿರ್ವಾತಗಳಾಗಿವೆ. ಮತ್ತು ಅವರು ಸುಲಭವಾಗಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸೇರಿಸಬಹುದು ಏಕೆಂದರೆ ಅವರು ಸಂಪೂರ್ಣ ಟೇಬಲ್ ಅನ್ನು ಓದುತ್ತಾರೆ, ಆ ಕೋಷ್ಟಕದಲ್ಲಿನ ಎಲ್ಲಾ ಬ್ಲಾಕ್ಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತಾರೆ.

ಮತ್ತು, ಸಹಜವಾಗಿ, ನಿರ್ವಾತಗಳ ಅವಧಿ. ನಾವು ದೀರ್ಘಕಾಲದವರೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ದೀರ್ಘಕಾಲೀನ ನಿರ್ವಾತಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಇದರರ್ಥ ನಾವು ಮತ್ತೆ ನಿರ್ವಾತ ಸಂರಚನೆಗೆ ಗಮನ ಕೊಡಬೇಕು ಮತ್ತು ಬಹುಶಃ ಅದರ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮರುಪರಿಶೀಲಿಸಬೇಕು. ಏಕೆಂದರೆ ನಿರ್ವಾತವು ದೀರ್ಘಕಾಲದವರೆಗೆ (3-4 ಗಂಟೆಗಳ) ಮೇಜಿನ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವಾಗ ಪರಿಸ್ಥಿತಿ ಉಂಟಾಗಬಹುದು, ಆದರೆ ನಿರ್ವಾತವು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸಮಯದಲ್ಲಿ, ದೊಡ್ಡ ಪ್ರಮಾಣದ ಸತ್ತ ಸಾಲುಗಳು ಮತ್ತೆ ಮೇಜಿನ ಮೇಲೆ ಸಂಗ್ರಹಗೊಳ್ಳಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದವು. ಮತ್ತು ನಿರ್ವಾತವು ಪೂರ್ಣಗೊಂಡ ತಕ್ಷಣ, ಅವನು ಮತ್ತೆ ಈ ಟೇಬಲ್ ಅನ್ನು ನಿರ್ವಾತ ಮಾಡಬೇಕಾಗಿದೆ. ಮತ್ತು ನಾವು ಪರಿಸ್ಥಿತಿಗೆ ಬರುತ್ತೇವೆ - ಅಂತ್ಯವಿಲ್ಲದ ನಿರ್ವಾತ. ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಿರ್ವಾತವು ಅದರ ಕೆಲಸವನ್ನು ನಿಭಾಯಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಕೋಷ್ಟಕಗಳು ಕ್ರಮೇಣ ಗಾತ್ರದಲ್ಲಿ ಊದಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ, ಆದರೂ ಅದರಲ್ಲಿ ಉಪಯುಕ್ತ ಡೇಟಾದ ಪರಿಮಾಣವು ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ದೀರ್ಘ ನಿರ್ವಾತಗಳ ಸಮಯದಲ್ಲಿ, ನಾವು ಯಾವಾಗಲೂ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯು ತೊಂದರೆಯಾಗುವುದಿಲ್ಲ.

ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಯಾವುದೇ PostgreSQL ಅನುಸ್ಥಾಪನೆಯು ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿಲ್ಲ. ನಕಲು ಎಂದರೆ ಮಾಸ್ಟರ್‌ನಿಂದ ಪ್ರತಿಕೃತಿಗೆ ಡೇಟಾವನ್ನು ಚಲಿಸುವ ಪ್ರಕ್ರಿಯೆ.

PostgreSQL ನಲ್ಲಿ ನಕಲು ವಹಿವಾಟು ಲಾಗ್ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ. ಮಾಂತ್ರಿಕನು ವಹಿವಾಟು ಲಾಗ್ ಅನ್ನು ರಚಿಸುತ್ತಾನೆ. ವಹಿವಾಟಿನ ಲಾಗ್ ಪ್ರತಿಕೃತಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕದ ಮೂಲಕ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಪುನರುತ್ಪಾದಿಸಲಾಗುತ್ತದೆ. ಇದು ಸರಳವಾಗಿದೆ.

ಅದರಂತೆ, pg_stat_replication ವೀಕ್ಷಣೆಯನ್ನು ಪುನರಾವರ್ತನೆಯ ವಿಳಂಬವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಬಳಸಲಾಗುತ್ತದೆ. ಆದರೆ ಅವಳೊಂದಿಗೆ ಎಲ್ಲವೂ ಸರಳವಾಗಿಲ್ಲ. ಆವೃತ್ತಿ 10 ರಲ್ಲಿ, ವೀಕ್ಷಣೆಯು ಹಲವಾರು ಬದಲಾವಣೆಗಳಿಗೆ ಒಳಗಾಯಿತು. ಮೊದಲನೆಯದಾಗಿ, ಕೆಲವು ಕ್ಷೇತ್ರಗಳನ್ನು ಮರುನಾಮಕರಣ ಮಾಡಲಾಗಿದೆ. ಮತ್ತು ಕೆಲವು ಕ್ಷೇತ್ರಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ಆವೃತ್ತಿ 10 ರಲ್ಲಿ, ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಪುನರಾವರ್ತನೆಯ ವಿಳಂಬವನ್ನು ಅಂದಾಜು ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಕ್ಷೇತ್ರಗಳು ಕಾಣಿಸಿಕೊಂಡವು. ಇದು ತುಂಬಾ ಆರಾಮದಾಯಕವಾಗಿದೆ. ಆವೃತ್ತಿ 10 ರ ಮೊದಲು, ಬೈಟ್‌ಗಳಲ್ಲಿ ಪ್ರತಿಕೃತಿ ವಿಳಂಬವನ್ನು ಅಂದಾಜು ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು. ಈ ಆಯ್ಕೆಯು ಆವೃತ್ತಿ 10 ರಲ್ಲಿ ಉಳಿದಿದೆ, ಅಂದರೆ ನಿಮಗೆ ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾದುದನ್ನು ನೀವು ಆಯ್ಕೆ ಮಾಡಬಹುದು - ಬೈಟ್‌ಗಳಲ್ಲಿ ವಿಳಂಬವನ್ನು ಅಂದಾಜು ಮಾಡಿ ಅಥವಾ ಸೆಕೆಂಡುಗಳಲ್ಲಿ ವಿಳಂಬವನ್ನು ಅಂದಾಜು ಮಾಡಿ. ಅನೇಕ ಜನರು ಎರಡನ್ನೂ ಮಾಡುತ್ತಾರೆ.

ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ, ಪುನರಾವರ್ತನೆಯ ಮಂದಗತಿಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು, ವ್ಯವಹಾರದಲ್ಲಿ ಲಾಗ್ನ ಸ್ಥಾನವನ್ನು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕು. ಮತ್ತು ಈ ವಹಿವಾಟಿನ ಲಾಗ್ ಸ್ಥಾನಗಳು ನಿಖರವಾಗಿ pg_stat_replication ವೀಕ್ಷಣೆಯಲ್ಲಿವೆ. ತುಲನಾತ್ಮಕವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಾವು pg_xlog_location_diff() ಕಾರ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ವಹಿವಾಟು ಲಾಗ್‌ನಲ್ಲಿ ಎರಡು ಅಂಕಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಅವುಗಳ ನಡುವಿನ ಡೆಲ್ಟಾವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ ಮತ್ತು ಬೈಟ್‌ಗಳಲ್ಲಿ ಪ್ರತಿಕೃತಿ ಮಂದಗತಿಯನ್ನು ಪಡೆಯಿರಿ. ಇದು ತುಂಬಾ ಅನುಕೂಲಕರ ಮತ್ತು ಸರಳವಾಗಿದೆ.

ಆವೃತ್ತಿ 10 ರಲ್ಲಿ, ಈ ಕಾರ್ಯವನ್ನು pg_wal_lsn_diff() ಎಂದು ಮರುಹೆಸರಿಸಲಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, "xlog" ಎಂಬ ಪದವು ಕಾಣಿಸಿಕೊಂಡ ಎಲ್ಲಾ ಕಾರ್ಯಗಳು, ವೀಕ್ಷಣೆಗಳು ಮತ್ತು ಉಪಯುಕ್ತತೆಗಳಲ್ಲಿ, ಅದನ್ನು "ವಾಲ್" ಮೌಲ್ಯದಿಂದ ಬದಲಾಯಿಸಲಾಯಿತು. ಇದು ವೀಕ್ಷಣೆಗಳು ಮತ್ತು ಕಾರ್ಯಗಳೆರಡಕ್ಕೂ ಅನ್ವಯಿಸುತ್ತದೆ. ಇದು ಅಂತಹ ನಾವೀನ್ಯತೆಯಾಗಿದೆ.

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

ಬಹುತೇಕ ಎಲ್ಲವೂ ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ ಕ್ರಮದಲ್ಲಿದೆ. ಯಾವುದೇ ಮೇಲ್ವಿಚಾರಣೆ ಪ್ರಾರಂಭವಾದಾಗ, ಅದು ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಇದು ಪ್ರೊಸೆಸರ್ಗಳು, ಮೆಮೊರಿ, ಸ್ವಾಪ್, ನೆಟ್ವರ್ಕ್ ಮತ್ತು ಡಿಸ್ಕ್ನ ವಿಲೇವಾರಿಯಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಅನೇಕ ನಿಯತಾಂಕಗಳು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಇರುವುದಿಲ್ಲ.

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

ಮೇಲಾಗಿ, ಈ ಅಂಕಿಅಂಶಗಳನ್ನು ಮರುಬಳಕೆಯ ಪ್ರೊಸೆಸರ್‌ಗಳಿಗೆ ಮಾಡುವಂತೆ /proc ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಿಂದ ಕೂಡ ಪಡೆಯಬಹುದು. ಈ ಮಾಹಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆಗೆ ಏಕೆ ಸೇರಿಸಲಾಗಿಲ್ಲ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ. ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ, ನಿಮ್ಮ ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಇದನ್ನು ಹೊಂದಿರುವುದು ಮುಖ್ಯವಾಗಿದೆ.

ಅದೇ ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ, ಬೈಟ್‌ಗಳಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಥ್ರೋಪುಟ್ ಬಗ್ಗೆ ಮಾಹಿತಿ ಇದೆ, ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ ಲೇಟೆನ್ಸಿ ಬಗ್ಗೆ ಯಾವುದೇ ಮಾಹಿತಿ ಇಲ್ಲ ಮತ್ತು ಬಳಕೆಯ ಬಗ್ಗೆ ಯಾವುದೇ ಮಾಹಿತಿ ಇಲ್ಲ, ಆದರೂ ಇದು ಉಪಯುಕ್ತ ಮಾಹಿತಿಯಾಗಿದೆ.

ಯಾವುದೇ ಮೇಲ್ವಿಚಾರಣೆಯು ನ್ಯೂನತೆಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ನೀವು ಯಾವ ರೀತಿಯ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ತೆಗೆದುಕೊಂಡರೂ, ಅದು ಯಾವಾಗಲೂ ಕೆಲವು ಮಾನದಂಡಗಳನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ. ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ, ಅವರು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದಾರೆ, ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳು ಮತ್ತು ಹೊಸ ವಿಷಯಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ, ಆದ್ದರಿಂದ ಏನನ್ನಾದರೂ ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಮುಗಿಸಿ.

ಮತ್ತು ಮುಗಿಸಲು, ಒದಗಿಸಿದ ಅಂಕಿಅಂಶಗಳ ಅರ್ಥವೇನು ಮತ್ತು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ನೀವು ಅವುಗಳನ್ನು ಹೇಗೆ ಬಳಸಬಹುದು ಎಂಬ ಕಲ್ಪನೆಯನ್ನು ನೀವು ಯಾವಾಗಲೂ ಹೊಂದಿರಬೇಕು.

ಮತ್ತು ಕೆಲವು ಪ್ರಮುಖ ಅಂಶಗಳು:

• ನೀವು ಯಾವಾಗಲೂ ಲಭ್ಯತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು ಮತ್ತು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ಹೊಂದಿರಬೇಕು ಆದ್ದರಿಂದ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಕ್ರಮದಲ್ಲಿದೆ ಎಂದು ನೀವು ತ್ವರಿತವಾಗಿ ನಿರ್ಣಯಿಸಬಹುದು.
• ಕೆಟ್ಟ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಹೊರಹಾಕಲು ಮತ್ತು ಅವುಗಳನ್ನು ಶೂಟ್ ಮಾಡಲು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕ್ಲೈಂಟ್‌ಗಳು ಏನು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬ ಕಲ್ಪನೆಯನ್ನು ನೀವು ಯಾವಾಗಲೂ ಹೊಂದಿರಬೇಕು.
• ಈ ಗ್ರಾಹಕರು ಡೇಟಾದೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಮುಖ್ಯ. ನಿಮ್ಮ ಕೆಲಸದ ಹೊರೆಯ ಬಗ್ಗೆ ನೀವು ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿರಬೇಕು.
• ಯಾವ ಪ್ರಶ್ನೆಗಳ ಸಹಾಯದಿಂದ ಈ ಕೆಲಸದ ಹೊರೆ ಹೇಗೆ ರೂಪುಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಮುಖ್ಯ. ನೀವು ಪ್ರಶ್ನೆಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು, ನೀವು ಅವುಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬಹುದು, ಅವುಗಳನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಬಹುದು, ಅವುಗಳಿಗೆ ಸೂಚ್ಯಂಕಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು. ಇದು ಅತೀ ಮುಖ್ಯವಾದುದು.
• ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳು ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ಋಣಾತ್ಮಕವಾಗಿ ಪರಿಣಾಮ ಬೀರಬಹುದು, ಆದ್ದರಿಂದ ಅವರು ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತಿಲ್ಲ ಎಂಬುದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಮುಖ್ಯವಾಗಿದೆ.
• ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳು ನಿಮ್ಮ ಸರ್ವರ್‌ಗಳ ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಸಾಮರ್ಥ್ಯವನ್ನು ಹೆಚ್ಚಿಸಲು ಯೋಜನೆಗಳನ್ನು ಮಾಡಲು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಮತ್ತು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಸಹ ಮುಖ್ಯವಾಗಿದೆ.

ನೀವು ಈ ವಿಷಯದಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ನಂತರ ನೀವು ಈ ಲಿಂಕ್‌ಗಳನ್ನು ಅನುಸರಿಸಬಹುದು.
http://bit.do/stats_collector - ಇದು ಅಂಕಿಅಂಶ ಸಂಗ್ರಾಹಕರಿಂದ ಅಧಿಕೃತ ದಾಖಲೆಯಾಗಿದೆ. ಎಲ್ಲಾ ಅಂಕಿಅಂಶಗಳ ವೀಕ್ಷಣೆಗಳ ವಿವರಣೆ ಮತ್ತು ಎಲ್ಲಾ ಕ್ಷೇತ್ರಗಳ ವಿವರಣೆ ಇದೆ. ನೀವು ಅವುಗಳನ್ನು ಓದಬಹುದು, ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ವಿಶ್ಲೇಷಿಸಬಹುದು. ಮತ್ತು ಅವುಗಳ ಆಧಾರದ ಮೇಲೆ, ನಿಮ್ಮ ಗ್ರಾಫ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ನಿಮ್ಮ ಮೇಲ್ವಿಚಾರಣೆಗೆ ಸೇರಿಸಿ.

ಉದಾಹರಣೆ ವಿನಂತಿಗಳು:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

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

ಪ್ರಶ್ನೆಗಳು

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

ಪ್ರಶ್ನೆ: AWR ವರದಿಗಳ ಯಾವುದೇ ಸಾದೃಶ್ಯಗಳು ಅಥವಾ... ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ ಇದೆಯೇ? ಅಂತಹ ವಿಷಯದ ಬಗ್ಗೆ ನಿಮಗೆ ತಿಳಿದಿದೆಯೇ?
ಉತ್ತರ: ಹೌದು, AWR ಎಂದರೇನು ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ, ಇದು ತಂಪಾದ ವಿಷಯ. ಈ ಸಮಯದಲ್ಲಿ ಸರಿಸುಮಾರು ಕೆಳಗಿನ ಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ವಿವಿಧ ಬೈಸಿಕಲ್‌ಗಳಿವೆ. ಕೆಲವು ಸಮಯದ ಮಧ್ಯಂತರದಲ್ಲಿ, ಕೆಲವು ಬೇಸ್‌ಲೈನ್‌ಗಳನ್ನು ಅದೇ PostgreSQL ಗೆ ಅಥವಾ ಪ್ರತ್ಯೇಕ ಸಂಗ್ರಹಣೆಗೆ ಬರೆಯಲಾಗುತ್ತದೆ. ನೀವು ಅವುಗಳನ್ನು ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಗೂಗಲ್ ಮಾಡಬಹುದು, ಅವುಗಳು ಇವೆ. ಅಂತಹ ವಿಷಯದ ಡೆವಲಪರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರು PostgreSQL ಥ್ರೆಡ್‌ನಲ್ಲಿ sql.ru ಫೋರಮ್‌ನಲ್ಲಿ ಕುಳಿತಿದ್ದಾರೆ. ನೀವು ಅವನನ್ನು ಅಲ್ಲಿ ಹಿಡಿಯಬಹುದು. ಹೌದು, ಅಂತಹ ವಿಷಯಗಳಿವೆ, ಅವುಗಳನ್ನು ಬಳಸಬಹುದು. ಜೊತೆಗೆ ಅದರಲ್ಲಿ pgCenter ನಾನು ಅದೇ ಕೆಲಸವನ್ನು ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ವಿಷಯವನ್ನು ಸಹ ಬರೆಯುತ್ತಿದ್ದೇನೆ.

PS1 ನೀವು postgres_exporter ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನೀವು ಯಾವ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಬಳಸುತ್ತಿರುವಿರಿ? ಅವುಗಳಲ್ಲಿ ಹಲವಾರು ಇವೆ. ಅವು ಈಗಾಗಲೇ ಹಳೆಯದಾಗಿವೆ. ಬಹುಶಃ ಸಮುದಾಯವು ನವೀಕರಿಸಿದ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ರಚಿಸಬಹುದೇ?

PS2 pganalyze ಅನ್ನು ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ನಿರ್ವಹಣೆಯ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಶ್ರುತಿ ಸಲಹೆಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವ ಸ್ವಾಮ್ಯದ SaaS ಕೊಡುಗೆಯಾಗಿದೆ.

ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. ಸೈನ್ ಇನ್ ಮಾಡಿ, ದಯವಿಟ್ಟು.

ಯಾವ ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿದ postgresql ಮಾನಿಟರಿಂಗ್ (ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನೊಂದಿಗೆ) ನೀವು ಉತ್ತಮವೆಂದು ಪರಿಗಣಿಸುತ್ತೀರಿ?

• 30,0%ಅಲೆಕ್ಸಿ ಲೆಸೊವ್ಸ್ಕಿ ಅಥವಾ zabbix 4.4 ಅಥವಾ libzbxpgsql + zabbix libzbxpgsql + zabbix3 ನಿಂದ Zabbix + ಸೇರ್ಪಡೆಗಳು

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze ಸ್ವಾಮ್ಯದ SaaS ಆಗಿದೆ - ನಾನು ಅದನ್ನು ಅಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 26 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.

ಮೂಲ: www.habr.com