postgresql ನಲ್ಲಿ ಉಬ್ಬುವಿಕೆಗೆ ಕಾರಣವಾಗುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿನ ವಿಶಿಷ್ಟ ದೋಷಗಳು. ಆಂಡ್ರೆ ಸಾಲ್ನಿಕೋವ್

ಆಂಡ್ರೆ ಸಾಲ್ನಿಕೋವ್ ಅವರ 2016 ರ ಆರಂಭದಿಂದ ವರದಿಯ ಪ್ರತಿಲೇಖನವನ್ನು ಓದಲು ನಾನು ನಿಮಗೆ ಸಲಹೆ ನೀಡುತ್ತೇನೆ “ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ಕ್ಲ್‌ನಲ್ಲಿ ಉಬ್ಬುವಿಕೆಗೆ ಕಾರಣವಾಗುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿನ ವಿಶಿಷ್ಟ ದೋಷಗಳು”

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

ಎಲ್ಲರನ್ನು ಸ್ವಾಗತಿಸಲು ಸಂತೋಷವಾಗಿದೆ! ಈ ವರದಿಯು ನನ್ನ ಸಹೋದ್ಯೋಗಿಯಿಂದ ಹಿಂದಿನ ವರದಿಯಂತೆ ತಾಂತ್ರಿಕವಾಗಿಲ್ಲ. ಈ ವರದಿಯು ಮುಖ್ಯವಾಗಿ ಬ್ಯಾಕೆಂಡ್ ಸಿಸ್ಟಮ್ ಡೆವಲಪರ್‌ಗಳನ್ನು ಗುರಿಯಾಗಿರಿಸಿಕೊಂಡಿದೆ ಏಕೆಂದರೆ ನಾವು ಸಾಕಷ್ಟು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಅವರೆಲ್ಲರೂ ಒಂದೇ ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತಾರೆ. ನಾನು ಅವರ ಬಗ್ಗೆ ಹೇಳುತ್ತೇನೆ. ಈ ತಪ್ಪುಗಳು ಯಾವ ಮಾರಕ ಮತ್ತು ಕೆಟ್ಟ ವಿಷಯಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ನಾನು ವಿವರಿಸುತ್ತೇನೆ.

ತಪ್ಪುಗಳನ್ನು ಏಕೆ ಮಾಡಲಾಗುತ್ತದೆ? ಅವುಗಳನ್ನು ಎರಡು ಕಾರಣಗಳಿಗಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ: ಯಾದೃಚ್ಛಿಕವಾಗಿ, ಬಹುಶಃ ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ನಡುವಿನ ಮಟ್ಟದಲ್ಲಿ ಸಂಭವಿಸುವ ಕೆಲವು ಕಾರ್ಯವಿಧಾನಗಳ ಅಜ್ಞಾನದಿಂದಾಗಿ, ಹಾಗೆಯೇ ಡೇಟಾಬೇಸ್ನಲ್ಲಿಯೇ.

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

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

ಪ್ಲೇಟ್‌ನ ಆರಂಭಿಕ ಡೇಟಾ: ಇದು ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿದೆ, 2 MB. ಡೇಟಾಬೇಸ್‌ಗೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಚಿಹ್ನೆಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ ಕೂಡ ತುಂಬಾ ಒಳ್ಳೆಯದು. ಮತ್ತು ಸಾಕಷ್ಟು ಉತ್ತಮ ಲೋಡ್ - ಪ್ಲೇಟ್ ಪ್ರಕಾರ ಸೆಕೆಂಡಿಗೆ 2 ಕಾರ್ಯಾಚರಣೆಗಳು.

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

ಮತ್ತು ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ನಾವು ನಿಜವಾಗಿಯೂ ಒಂದು ಸಣ್ಣ ಚಿಹ್ನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಸೂಚ್ಯಂಕವು 2 MB ಯಲ್ಲಿ ಚಿಕ್ಕದಾಗಿದೆ. ಇದು ಎಡಭಾಗದಲ್ಲಿರುವ ಮೊದಲ ಗ್ರಾಫ್ ಆಗಿದೆ.

ಸರ್ವರ್‌ನಲ್ಲಿನ ಸರಾಸರಿ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವೂ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ ಮತ್ತು ಚಿಕ್ಕದಾಗಿದೆ. ಇದು ಮೇಲಿನ ಬಲ ಗ್ರಾಫ್ ಆಗಿದೆ.

ಕೆಳಗಿನ ಎಡಭಾಗದ ಗ್ರಾಫ್ ದೀರ್ಘ ವಹಿವಾಟುಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ವಹಿವಾಟುಗಳು ತ್ವರಿತವಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ಮತ್ತು ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಇಲ್ಲಿ ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಇದು ಪ್ರಾರಂಭದ ಪರೀಕ್ಷೆಯಾಗಿದೆ. ಇದು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ ಮತ್ತು ನಮಗೆ ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ.

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

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

ಮತ್ತು ಈಗ ನಮಗೆ ದುರಂತವಿದೆ. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ದೀರ್ಘಕಾಲ ಮರೆತುಹೋದ ವ್ಯವಹಾರವಿದೆ. ಕಾರಣಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಾ ನೀರಸವಾಗಿವೆ:

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

ಅಂತಹ ವಿಷಯಗಳು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ?

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

ಮತ್ತು ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ. ಕೆಳಗಿನ ಎಡಭಾಗದ ಗ್ರಾಫ್ ನಾವು ಸುದೀರ್ಘ ವ್ಯವಹಾರವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಮತ್ತು ನಾವು ಮೇಲಿನ ಎಡ ಗ್ರಾಫ್ ಅನ್ನು ನೋಡಿದರೆ, ನಮ್ಮ ಟೇಬಲ್ನ ಗಾತ್ರವು ಎರಡು ಮೆಗಾಬೈಟ್ಗಳಿಂದ 300 ಮೆಗಾಬೈಟ್ಗಳಿಗೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಜಿಗಿದಿರುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕೋಷ್ಟಕದಲ್ಲಿನ ಡೇಟಾದ ಪ್ರಮಾಣವು ಬದಲಾಗಿಲ್ಲ, ಅಂದರೆ ಅಲ್ಲಿ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಕಸವಿದೆ.

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

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

ನಾವು ಮತ್ತೆ ಜೀವನಕ್ಕೆ ಮರಳಬೇಕಾಗಿದೆ. ನಾವು ಆನ್‌ಲೈನ್‌ಗೆ ಹೋಗುತ್ತೇವೆ ಮತ್ತು ದೀರ್ಘ ವಹಿವಾಟುಗಳು ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ ಎಂದು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ. ನಾವು ಈ ವಹಿವಾಟನ್ನು ಹುಡುಕುತ್ತೇವೆ ಮತ್ತು ಕೊಲ್ಲುತ್ತೇವೆ. ಮತ್ತು ಎಲ್ಲವೂ ನಮಗೆ ಸಾಮಾನ್ಯವಾಗುತ್ತಿದೆ. ಎಲ್ಲವೂ ಇರಬೇಕಾದಂತೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

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

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

ನಿರ್ದಿಷ್ಟವಾಗಿ, ಖಾತೆಗಳೊಂದಿಗೆ ಪರೀಕ್ಷಾ ಫಲಕದ ಪ್ರಕಾರ, ನಾವು ಬ್ಯಾಲೆನ್ಸ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ: ವಿನಂತಿಯ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವು ಸಾಮಾನ್ಯ ಸ್ಥಿತಿಗೆ ಮರಳಿದೆ. ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಇದು ಒಂದೂವರೆ ಪಟ್ಟು ಹೆಚ್ಚಾಗಿದೆ.

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

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

ಮತ್ತು ಅಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನೀವು ಹಿಂದಿನ ವರದಿಯಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ, ಈಗ ನಾವು ಸ್ವಲ್ಪ ಸಿದ್ಧಾಂತವನ್ನು ಪಡೆಯೋಣ. ಆಂತರಿಕ ಪ್ರಕ್ರಿಯೆಯ ಸಿದ್ಧಾಂತ. ಕಾರ್ ನಿರ್ವಾತ ಏಕೆ ಮತ್ತು ಅದು ಏನು ಮಾಡುತ್ತದೆ?

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

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

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

ಅಪಘಾತದ ಸಮಯದಲ್ಲಿ ಏನಾಯಿತು? ಈ ಪ್ರಕ್ರಿಯೆ ಅಲ್ಲಿ ಹೇಗೆ ನಡೆಯಿತು?

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

ಆದರೆ ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಮೇಜಿನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. ನಾವು ಅದರಲ್ಲಿ ಏನನ್ನಾದರೂ ಮಾಡುತ್ತೇವೆ, ಅದನ್ನು ನವೀಕರಿಸುತ್ತೇವೆ, ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ. ಈ ಸಮಯದಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಏನು ಮಾಡಬೇಕು? ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಟೇಬಲ್‌ನ ಕೊನೆಯಲ್ಲಿ ಹೊಸ ಸಾಲುಗಳನ್ನು ಸೇರಿಸುವುದನ್ನು ಬಿಟ್ಟು ಅವಳಿಗೆ ಬೇರೆ ಆಯ್ಕೆಗಳಿಲ್ಲ. ಮತ್ತು ಹೀಗೆ ನಮ್ಮ ಮೇಜಿನ ಗಾತ್ರವು ಊದಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

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

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

ನಮಗೆ ಯಾವ ಪರಿಣಾಮಗಳು ಉಂಟಾಗಬಹುದು?

• ನನ್ನ ಉದಾಹರಣೆಯಲ್ಲಿ, ಟೇಬಲ್ ಮತ್ತು ಸೂಚ್ಯಂಕವು 150 ಪಟ್ಟು ಬೆಳೆದಿದೆ. ನಮ್ಮ ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳು ಡಿಸ್ಕ್ ಸ್ಥಳಾವಕಾಶದಿಂದ ಖಾಲಿಯಾಗಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಹೆಚ್ಚು ಮಾರಣಾಂತಿಕ ಪ್ರಕರಣಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ.
• ಕೋಷ್ಟಕಗಳ ಗಾತ್ರವು ಎಂದಿಗೂ ಕಡಿಮೆಯಾಗುವುದಿಲ್ಲ. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಆಟೋವಾಕ್ಯೂಮ್ ಡೆಡ್ ಲೈನ್‌ಗಳು ಮಾತ್ರ ಇದ್ದಲ್ಲಿ ಮೇಜಿನ ಬಾಲವನ್ನು ಕತ್ತರಿಸಬಹುದು. ಆದರೆ ನಿರಂತರ ತಿರುಗುವಿಕೆ ಇರುವುದರಿಂದ, ಒಂದು ಹಸಿರು ರೇಖೆಯು ಕೊನೆಯಲ್ಲಿ ಹೆಪ್ಪುಗಟ್ಟಬಹುದು ಮತ್ತು ನವೀಕರಿಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಉಳಿದವುಗಳನ್ನು ಪ್ಲೇಟ್ನ ಆರಂಭದಲ್ಲಿ ಎಲ್ಲೋ ಬರೆಯಲಾಗುತ್ತದೆ. ಆದರೆ ಇದು ಅಸಂಭವವಾದ ಘಟನೆಯಾಗಿದ್ದು, ನಿಮ್ಮ ಟೇಬಲ್ ಸ್ವತಃ ಗಾತ್ರದಲ್ಲಿ ಕುಗ್ಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಅದನ್ನು ಆಶಿಸಬಾರದು.
• ಡೇಟಾಬೇಸ್ ಅನುಪಯುಕ್ತ ಸಾಲುಗಳ ಸಂಪೂರ್ಣ ಗುಂಪಿನ ಮೂಲಕ ವಿಂಗಡಿಸಬೇಕಾಗಿದೆ. ಮತ್ತು ನಾವು ಡಿಸ್ಕ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತೇವೆ, ನಾವು ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ವಿದ್ಯುತ್ ಅನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತೇವೆ.
• ಮತ್ತು ಇದು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಏಕೆಂದರೆ ಆರಂಭದಲ್ಲಿ ನಾವು ವಿನಂತಿಯ ಮೇಲೆ 10 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳನ್ನು, ನಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ 10 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳನ್ನು ಕಳೆದರೆ, ನಂತರ ಕ್ರ್ಯಾಶ್‌ನ ಸಮಯದಲ್ಲಿ ನಾವು ವಿನಂತಿಯ ಮೇಲೆ ಸೆಕೆಂಡ್ ಮತ್ತು 10 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ಕಳೆಯಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಅಂದರೆ ಆದೇಶ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರಮಾಣವು ಕಡಿಮೆಯಾಗಿದೆ. ಮತ್ತು ಅಪಘಾತವನ್ನು ಪರಿಹರಿಸಿದಾಗ, ನಾವು ವಿನಂತಿಯ ಮೇಲೆ 20 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳನ್ನು, ಕೋಡ್‌ನಲ್ಲಿ 10 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳನ್ನು ಕಳೆಯಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಇದರರ್ಥ ನಾವು ಇನ್ನೂ ಉತ್ಪಾದಕತೆಯಲ್ಲಿ ಒಂದೂವರೆ ಪಟ್ಟು ಕಡಿಮೆಯಾಗಿದೆ. ಮತ್ತು ಇದೆಲ್ಲವೂ ಸ್ಥಗಿತಗೊಂಡ ಒಂದು ವಹಿವಾಟಿನಿಂದಾಗಿ, ಬಹುಶಃ ನಮ್ಮ ತಪ್ಪಿನಿಂದಾಗಿ.
• ಮತ್ತು ಪ್ರಶ್ನೆ: "ನಾವು ಎಲ್ಲವನ್ನೂ ಹೇಗೆ ಮರಳಿ ಪಡೆಯಬಹುದು?" ಇದರಿಂದ ಎಲ್ಲವೂ ನಮ್ಮೊಂದಿಗೆ ಉತ್ತಮವಾಗಿದೆ ಮತ್ತು ಅಪಘಾತದ ಮೊದಲು ವಿನಂತಿಗಳು ಬೇಗನೆ ಬರುತ್ತವೆ.

ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಕೆಲಸದ ಚಕ್ರವನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ.

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

ನೀವು ಈ ಕೋಷ್ಟಕಗಳನ್ನು ಕಂಡುಕೊಂಡ ನಂತರ, ನೀವು ಅವುಗಳನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ. ಇದಕ್ಕಾಗಿ ಈಗಾಗಲೇ ಉಪಕರಣಗಳಿವೆ. ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ನಾವು ಮೂರು ಸಾಧನಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಮೊದಲನೆಯದು ಅಂತರ್ನಿರ್ಮಿತ ವ್ಯಾಕ್ಯೂಮ್ ಫುಲ್. ಅವನು ಕ್ರೂರ, ಕಠೋರ ಮತ್ತು ದಯೆಯಿಲ್ಲದವನು, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಅವನು ತುಂಬಾ ಉಪಯುಕ್ತ. Pg_repack и pgcompactable - ಇವುಗಳು ಕೋಷ್ಟಕಗಳನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಲು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಉಪಯುಕ್ತತೆಗಳಾಗಿವೆ. ಮತ್ತು ಅವರು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಯಿಂದ ಪರಿಗಣಿಸುತ್ತಾರೆ.

ನಿಮಗೆ ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾದುದನ್ನು ಅವಲಂಬಿಸಿ ಅವುಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಆದರೆ ನಾನು ಇದರ ಬಗ್ಗೆ ಕೊನೆಯಲ್ಲಿ ಹೇಳುತ್ತೇನೆ. ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಮೂರು ಸಾಧನಗಳಿವೆ. ಆಯ್ಕೆ ಮಾಡಲು ಸಾಕಷ್ಟು ಇವೆ.

ನಾವು ಎಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸಿದ ನಂತರ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಂಡ ನಂತರ, ಭವಿಷ್ಯದಲ್ಲಿ ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ತಡೆಯುವುದು ಹೇಗೆ ಎಂದು ನಾವು ತಿಳಿದಿರಬೇಕು:

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

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

ಟೇಬಲ್ ಗಾತ್ರವು ತಕ್ಷಣವೇ ಒಂದೆರಡು ಮೆಗಾಬೈಟ್‌ಗಳ ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಯ ಸ್ಥಿತಿಗೆ ಮರಳಿತು. ಇದು ಸರ್ವರ್‌ನ ಸರಾಸರಿ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರಲಿಲ್ಲ.

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

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

ಎರಡನೇ ಕಥೆ, ಇದರಲ್ಲಿ ನಾವು ಲೋಡ್ ಅನ್ನು ವಿತರಿಸುತ್ತೇವೆ ಮತ್ತು ಸರ್ವರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತೇವೆ

• ನಾವು ಈಗಾಗಲೇ ಬೆಳೆದಿದ್ದೇವೆ ಮತ್ತು ಗಂಭೀರ ವ್ಯಕ್ತಿಗಳಾಗಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಲೋಡ್ ಅನ್ನು ಸಮತೋಲನಗೊಳಿಸುವುದು ನಮಗೆ ಒಳ್ಳೆಯದು ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ: ಮಾಸ್ಟರ್ಗೆ ಬರೆಯಿರಿ ಮತ್ತು ಪ್ರತಿಕೃತಿಯಿಂದ ಓದಿ. ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ನಾವು ಕೆಲವು ವರದಿಗಳು ಅಥವಾ ETL ಅನ್ನು ತಯಾರಿಸಲು ಬಯಸಿದಾಗ ಈ ಪರಿಸ್ಥಿತಿಯು ಉದ್ಭವಿಸುತ್ತದೆ. ಮತ್ತು ವ್ಯಾಪಾರವು ಈ ಬಗ್ಗೆ ತುಂಬಾ ಸಂತೋಷವಾಗಿದೆ. ಅವರು ನಿಜವಾಗಿಯೂ ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣ ವಿಶ್ಲೇಷಣೆಗಳೊಂದಿಗೆ ವಿವಿಧ ವರದಿಗಳನ್ನು ಬಯಸುತ್ತಾರೆ.
• ವರದಿಗಳು ಹಲವು ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ, ಏಕೆಂದರೆ ಸಂಕೀರ್ಣ ವಿಶ್ಲೇಷಣೆಗಳನ್ನು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಲೆಕ್ಕಹಾಕಲಾಗುವುದಿಲ್ಲ. ನಾವು, ಧೈರ್ಯಶಾಲಿ ಹುಡುಗರಂತೆ, ಕೋಡ್ ಬರೆಯುತ್ತೇವೆ. ಅಳವಡಿಕೆ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ನಾವು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ವರದಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ.
• ಲೋಡ್ ಅನ್ನು ವಿತರಿಸುವುದು.
• ಎಲ್ಲವೂ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನಾವು ಶ್ರೇಷ್ಠರು.

ಮತ್ತು ಈ ಪರಿಸ್ಥಿತಿಯು ಹೇಗೆ ಕಾಣುತ್ತದೆ? ನಿರ್ದಿಷ್ಟವಾಗಿ ಈ ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ, ನಾನು ವಹಿವಾಟಿನ ಅವಧಿಗೆ ಪ್ರತಿಕೃತಿಯಿಂದ ವಹಿವಾಟಿನ ಅವಧಿಯನ್ನು ಕೂಡ ಸೇರಿಸಿದ್ದೇನೆ. ಎಲ್ಲಾ ಇತರ ಗ್ರಾಫ್‌ಗಳು ಮಾಸ್ಟರ್ ಸರ್ವರ್ ಅನ್ನು ಮಾತ್ರ ಉಲ್ಲೇಖಿಸುತ್ತವೆ.

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

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

ಪುನರಾವರ್ತನೆಯೊಂದಿಗಿನ ಸಂಘರ್ಷದಿಂದಾಗಿ ಈ ವರದಿಗಳು ಹಿಂತಿರುಗಲು ಪ್ರಾರಂಭವಾಗುವ ಕ್ಷಣದವರೆಗೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ. ಮತ್ತು ಅವರು ನಿಯಮಿತ ಮಧ್ಯಂತರದಲ್ಲಿ ಮತ್ತೆ ಗುಂಡು ಹಾರಿಸುತ್ತಾರೆ.

ನಾವು ಆನ್‌ಲೈನ್‌ಗೆ ಹೋಗಿ ಇದು ಏಕೆ ನಡೆಯುತ್ತಿದೆ ಎಂದು ಓದಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಪರಿಹಾರವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ.

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

ಎಲ್ಲವೂ ಪರಿಪೂರ್ಣವಾಗಿರಬೇಕು ಎಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ನಾವು ಮತ್ತಷ್ಟು ಏರುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ತಂಪಾದ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ - hot_standby_feedback. ಅದನ್ನು ಆನ್ ಮಾಡೋಣ. Hot_standby_feedback ನಮಗೆ ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಆಟೋವಾಕ್ಯೂಮ್ ಅನ್ನು ತಡೆಹಿಡಿಯಲು ಅನುಮತಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, ನಾವು ಪ್ರತಿಕೃತಿ ಸಂಘರ್ಷಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೊಡೆದುಹಾಕುತ್ತೇವೆ. ಮತ್ತು ವರದಿಗಳೊಂದಿಗೆ ನಮಗೆ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

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

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

ನಾನು ಮೊದಲು ಏನು ಮಾತನಾಡುತ್ತಿದ್ದೇನೆಂದು ನಮಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ ಅದು ಹೇಗೆ ಕಾಣುತ್ತದೆ?

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

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

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

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

ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಡ್ರಾಡೌನ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಮೊದಲ ಪ್ರಕರಣದಂತೆ, ಒಂದೂವರೆ ರಿಂದ ಎರಡು ಬಾರಿ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಹೆಚ್ಚು.

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

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

ನಾವು ಅದೇ ರೀತಿಯಲ್ಲಿ ಪರಿಣಾಮಗಳನ್ನು ನಿವಾರಿಸುತ್ತೇವೆ:

• ನಾವು ಉಬ್ಬಿದ ಕೋಷ್ಟಕಗಳನ್ನು ಕಾಣುತ್ತೇವೆ.
• ಮತ್ತು ನಾವು ಅದನ್ನು ನಮಗೆ ಸೂಕ್ತವಾದ ಅತ್ಯಂತ ಅನುಕೂಲಕರ ಸಾಧನದೊಂದಿಗೆ ಸಂಕುಚಿತಗೊಳಿಸುತ್ತೇವೆ.

ಇಲ್ಲಿಗೆ ಎರಡನೇ ಕಥೆ ಮುಗಿಯಿತು. ಮೂರನೇ ಕಥೆಗೆ ಹೋಗೋಣ.

ನಾವು ವಲಸೆ ಮಾಡುವಲ್ಲಿ ನಮಗೆ ತುಂಬಾ ಸಾಮಾನ್ಯವಾಗಿದೆ.

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

ನಿಮ್ಮ ಮುಂದೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾದ ನವೀಕರಣದೊಂದಿಗೆ ವಲಸೆ ಇಲ್ಲಿದೆ. ಇವು ನನ್ನ ಖಾತೆ ವಹಿವಾಟುಗಳಾಗಿರುವುದರಿಂದ, ಪ್ಲೇಟ್ 15 ಜಿಬಿ ಆಗಿತ್ತು. ಮತ್ತು ನಾವು ಪ್ರತಿ ಸಾಲನ್ನು ನವೀಕರಿಸುವುದರಿಂದ, ನವೀಕರಣದೊಂದಿಗೆ ನಾವು ಟೇಬಲ್ನ ಗಾತ್ರವನ್ನು ದ್ವಿಗುಣಗೊಳಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಾವು ಪ್ರತಿ ಸಾಲನ್ನು ಪುನಃ ಬರೆಯುತ್ತೇವೆ.

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

ನಾವು ವಲಸೆಯನ್ನು ನಡೆಸಿದ್ದೇವೆ ಮತ್ತು ಮತ್ತೆ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ.

ವಲಸೆ ಯಶಸ್ವಿಯಾಗಿದೆ, ಆದರೆ:

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

ಮತ್ತು ಇದು ಮತ್ತೆ ಉಬ್ಬುವುದು, ಅದು ಮತ್ತೆ ನಮ್ಮ ಜೀವನವನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ.

ಹಿಂದಿನ ಎರಡು ಪ್ರಕರಣಗಳಂತೆ ಟೇಬಲ್ ಅದರ ಹಿಂದಿನ ಗಾತ್ರಗಳಿಗೆ ಹಿಂತಿರುಗುವುದಿಲ್ಲ ಎಂದು ಇಲ್ಲಿ ನಾನು ಪ್ರದರ್ಶಿಸುತ್ತೇನೆ. ಸರಾಸರಿ ಸರ್ವರ್ ಲೋಡ್ ಸಾಕಷ್ಟು ಎಂದು ತೋರುತ್ತದೆ.

ಮತ್ತು ನಾವು ಖಾತೆಗಳೊಂದಿಗೆ ಟೇಬಲ್ಗೆ ತಿರುಗಿದರೆ, ಈ ಟೇಬಲ್ಗಾಗಿ ಸರಾಸರಿ ವಿನಂತಿಯ ಸಮಯವು ದ್ವಿಗುಣಗೊಂಡಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಪ್ರೊಸೆಸರ್‌ನಲ್ಲಿನ ಹೊರೆ ಮತ್ತು ಮೆಮೊರಿಯಲ್ಲಿ ವಿಂಗಡಿಸಲಾದ ಸಾಲುಗಳ ಸಂಖ್ಯೆ 7,5 ಕ್ಕಿಂತ ಹೆಚ್ಚಾಯಿತು, ಆದರೆ ಕಡಿಮೆಯಾಗಿದೆ. ಮತ್ತು ಪ್ರೊಸೆಸರ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಇದು 2 ಬಾರಿ ಜಿಗಿದಿದೆ, ಬ್ಲಾಕ್ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ 1,5 ಬಾರಿ, ಅಂದರೆ ನಾವು ಸರ್ವರ್ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಅವನತಿಯನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ಮತ್ತು ಪರಿಣಾಮವಾಗಿ - ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವನತಿ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕರೆಗಳ ಸಂಖ್ಯೆಯು ಸರಿಸುಮಾರು ಅದೇ ಮಟ್ಟದಲ್ಲಿ ಉಳಿಯಿತು.

ಮತ್ತು ಇಲ್ಲಿ ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಅಂತಹ ವಲಸೆಗಳನ್ನು ಸರಿಯಾಗಿ ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು. ಮತ್ತು ಅವುಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. ನಾವು ಈ ವಲಸೆಗಳನ್ನು ಸಾಕಷ್ಟು ಸ್ಥಿರವಾಗಿ ಮಾಡುತ್ತೇವೆ.

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

ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನಾವು ಉಬ್ಬುವಿಕೆಯನ್ನು ಪಡೆಯುವುದಿಲ್ಲ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿಷಯದಲ್ಲಿ ಬಳಲುತ್ತಿಲ್ಲ.

ಇಲ್ಲಿಗೆ ಮೂರನೇ ಕಥೆ ಮುಗಿಯುತ್ತದೆ.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

ಮತ್ತು ಈಗ ನಾನು ಮೊದಲ ಕಥೆಯಲ್ಲಿ ಪ್ರಸ್ತಾಪಿಸಿದ ಪರಿಕರಗಳ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ವಿವರವಾಗಿ.

ಉಬ್ಬುವಿಕೆಯನ್ನು ಹುಡುಕುವ ಮೊದಲು, ನೀವು ವಿಸ್ತರಣೆಯನ್ನು ಸ್ಥಾಪಿಸಬೇಕು pgstattuple.

ಆದ್ದರಿಂದ ನೀವು ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ಬರಬೇಕಾಗಿಲ್ಲ, ನಾವು ಈಗಾಗಲೇ ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ನಮ್ಮ ಕೆಲಸದಲ್ಲಿ ಬರೆದಿದ್ದೇವೆ. ನೀವು ಅವುಗಳನ್ನು ಬಳಸಬಹುದು. ಇಲ್ಲಿ ಎರಡು ವಿನಂತಿಗಳಿವೆ.

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

ಅನುಪಯುಕ್ತ ಡೇಟಾದೊಂದಿಗೆ ಊದಿಕೊಂಡ ಕೋಷ್ಟಕಗಳನ್ನು ಹೇಗೆ ಗುರುತಿಸುವುದು ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ.

ಉಬ್ಬುವಿಕೆಯನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಈಗ:

• ನಾವು ಸಣ್ಣ ಟ್ಯಾಬ್ಲೆಟ್ ಮತ್ತು ಉತ್ತಮ ಡಿಸ್ಕ್ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅಂದರೆ, ಗಿಗಾಬೈಟ್ ವರೆಗಿನ ಟ್ಯಾಬ್ಲೆಟ್ನಲ್ಲಿ, ವ್ಯಾಕ್ಯೂಮ್ ಫುಲ್ ಅನ್ನು ಬಳಸಲು ಸಾಕಷ್ಟು ಸಾಧ್ಯವಿದೆ. ಅವನು ನಿಮ್ಮಿಂದ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಮೇಜಿನ ಮೇಲೆ ವಿಶೇಷವಾದ ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾನೆ ಮತ್ತು ಸರಿ, ಆದರೆ ಅವನು ಎಲ್ಲವನ್ನೂ ತ್ವರಿತವಾಗಿ ಮತ್ತು ಕಠಿಣವಾಗಿ ಮಾಡುತ್ತಾನೆ. ವ್ಯಾಕ್ಯೂಮ್ ಫುಲ್ ಏನು ಮಾಡುತ್ತದೆ? ಇದು ಮೇಜಿನ ಮೇಲೆ ವಿಶೇಷವಾದ ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಹಳೆಯ ಕೋಷ್ಟಕಗಳಿಂದ ಹೊಸ ಕೋಷ್ಟಕಕ್ಕೆ ಲೈವ್ ಸಾಲುಗಳನ್ನು ಪುನಃ ಬರೆಯುತ್ತದೆ. ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಅವನು ಅವರನ್ನು ಬದಲಾಯಿಸುತ್ತಾನೆ. ಇದು ಹಳೆಯ ಫೈಲ್‌ಗಳನ್ನು ಅಳಿಸುತ್ತದೆ ಮತ್ತು ಹಳೆಯದನ್ನು ಹೊಸದರೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ. ಆದರೆ ಅದರ ಕೆಲಸದ ಅವಧಿಗೆ, ಇದು ಮೇಜಿನ ಮೇಲೆ ವಿಶೇಷವಾದ ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಇದರರ್ಥ ನೀವು ಈ ಟೇಬಲ್‌ನೊಂದಿಗೆ ಏನನ್ನೂ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ: ಅದಕ್ಕೆ ಬರೆಯಬೇಡಿ, ಓದಬೇಡಿ ಅಥವಾ ಅದನ್ನು ಮಾರ್ಪಡಿಸಬೇಡಿ. ಮತ್ತು VACUM FULL ಗೆ ಡೇಟಾವನ್ನು ಬರೆಯಲು ಹೆಚ್ಚುವರಿ ಡಿಸ್ಕ್ ಸ್ಥಳಾವಕಾಶದ ಅಗತ್ಯವಿದೆ.
• ಮುಂದಿನ ಸಾಧನ pg_repack. ಅದರ ತತ್ವದಲ್ಲಿ, ಇದು VACUUM FULL ಗೆ ಹೋಲುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಹಳೆಯ ಫೈಲ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಹೊಸದಕ್ಕೆ ಪುನಃ ಬರೆಯುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಟೇಬಲ್‌ನಲ್ಲಿ ಬದಲಾಯಿಸುತ್ತದೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು ತನ್ನ ಕೆಲಸದ ಪ್ರಾರಂಭದಲ್ಲಿ ಮೇಜಿನ ಮೇಲೆ ವಿಶೇಷವಾದ ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದರೆ ಫೈಲ್ಗಳನ್ನು ಬದಲಿಸಲು ಅದು ಈಗಾಗಲೇ ಸಿದ್ಧ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವ ಕ್ಷಣದಲ್ಲಿ ಮಾತ್ರ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಇದರ ಡಿಸ್ಕ್ ಸಂಪನ್ಮೂಲ ಅವಶ್ಯಕತೆಗಳು VACUUM FULL ನಂತೆಯೇ ಇರುತ್ತವೆ. ನಿಮಗೆ ಹೆಚ್ಚುವರಿ ಡಿಸ್ಕ್ ಸ್ಥಳಾವಕಾಶ ಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ನೀವು ಟೆರಾಬೈಟ್ ಕೋಷ್ಟಕಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಇದು ಕೆಲವೊಮ್ಮೆ ನಿರ್ಣಾಯಕವಾಗಿರುತ್ತದೆ. ಮತ್ತು ಇದು ಸಾಕಷ್ಟು ಪ್ರೊಸೆಸರ್-ಹಸಿದವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು I/O ನೊಂದಿಗೆ ಸಕ್ರಿಯವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
• ಮೂರನೆಯ ಉಪಯುಕ್ತತೆ pgcompactable. ಇದು ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಹೆಚ್ಚು ಜಾಗರೂಕವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಸ್ವಲ್ಪ ವಿಭಿನ್ನ ತತ್ವಗಳ ಪ್ರಕಾರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. pgcompactable ನ ಮುಖ್ಯ ಉಪಾಯವೆಂದರೆ ಅದು ಟೇಬಲ್‌ನಲ್ಲಿನ ನವೀಕರಣಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲಾ ಲೈವ್ ಸಾಲುಗಳನ್ನು ಟೇಬಲ್‌ನ ಪ್ರಾರಂಭಕ್ಕೆ ಚಲಿಸುತ್ತದೆ. ತದನಂತರ ಅದು ಈ ಟೇಬಲ್‌ನಲ್ಲಿ ನಿರ್ವಾತವನ್ನು ನಡೆಸುತ್ತದೆ, ಏಕೆಂದರೆ ನಾವು ಆರಂಭದಲ್ಲಿ ಲೈವ್ ಸಾಲುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಸತ್ತ ಸಾಲುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ. ಮತ್ತು ನಿರ್ವಾತವು ಈ ಬಾಲವನ್ನು ಕತ್ತರಿಸುತ್ತದೆ, ಅಂದರೆ ಇದು ಹೆಚ್ಚಿನ ಹೆಚ್ಚುವರಿ ಡಿಸ್ಕ್ ಸ್ಥಳಾವಕಾಶದ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ, ಸಂಪನ್ಮೂಲಗಳ ವಿಷಯದಲ್ಲಿ ಅದನ್ನು ಇನ್ನೂ ಹಿಂಡಬಹುದು.

ಉಪಕರಣಗಳೊಂದಿಗೆ ಎಲ್ಲವೂ.

ಉಬ್ಬುವುದು ವಿಷಯವನ್ನು ಮತ್ತಷ್ಟು ಒಳಹೊಕ್ಕು ಪರಿಶೀಲಿಸುವ ವಿಷಯದಲ್ಲಿ ನಿಮಗೆ ಆಸಕ್ತಿಯಿದ್ದರೆ, ಇಲ್ಲಿ ಕೆಲವು ಉಪಯುಕ್ತ ಲಿಂಕ್‌ಗಳಿವೆ:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - ಇದು ನನ್ನ ಸಹೋದ್ಯೋಗಿಯಿಂದ ಬಂದ ವರದಿ. ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನ ಸ್ಥಳವು ಅದರ ಕೆಲಸ ಮತ್ತು ಜೀವನದಲ್ಲಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಇದು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಮತ್ತು ಉಬ್ಬುವಿಕೆಯ ಬಗ್ಗೆ ಡೇಟಾಬೇಸ್ ನಿರ್ವಾಹಕರಿಗೆ ಬಹಳ ದೊಡ್ಡ ಮತ್ತು ವಿವರವಾದ ತಾಂತ್ರಿಕ ತುಣುಕು ಇದೆ.
• https://github.com/dataegret/pg-utils - ಇದು ನಮ್ಮ ರೆಪೊಸಿಟರಿಗೆ ಲಿಂಕ್ ಆಗಿದೆ, ಅಲ್ಲಿ ನಾವು ಡೇಟಾಬೇಸ್ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲು ಉಪಯುಕ್ತ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಗುಂಪನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಅಲ್ಲಿ ನೀವು ಉಬ್ಬುವಿಕೆಯನ್ನು ಹುಡುಕಲು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಕಾಣಬಹುದು.
• ಮೂರನೇ и ನಾಲ್ಕನೇ ಚಿಹ್ನೆಗಳನ್ನು ಕುಗ್ಗಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುವ ಪರಿಕರಗಳಿಗೆ ಲಿಂಕ್‌ಗಳು.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - ಇದು ನನ್ನ ಸಹೋದ್ಯೋಗಿಯಿಂದ ಪೋಸ್ಟ್ ಆಗಿದೆ. ಅಲ್ಲಿ ಅವರು ಸಾಕಷ್ಟು ಗಂಭೀರವಾಗಿ ಮತ್ತು ತಾಂತ್ರಿಕವಾಗಿ ನಿರ್ವಾಹಕರಿಗೆ ಹತ್ತಿರವಿರುವ ಮಟ್ಟದಲ್ಲಿ ಉಬ್ಬುವಿಕೆಯನ್ನು ವಿವರವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತಾರೆ.

ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ಭಯಾನಕ ಕಥೆಯನ್ನು ತೋರಿಸಲು ನಾನು ಹೆಚ್ಚು ಪ್ರಯತ್ನಿಸಿದೆ, ಏಕೆಂದರೆ ಅವರು ಡೇಟಾಬೇಸ್‌ಗಳ ನಮ್ಮ ನೇರ ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಏನು ಮತ್ತು ಯಾವ ಕ್ರಮಗಳು ಕಾರಣವಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ನಾನು ಯಶಸ್ವಿಯಾಗಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಧನ್ಯವಾದಗಳು!

ಪ್ರಶ್ನೆಗಳು

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

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ನಿಮ್ಮ ಕಂಪನಿಯ ನಿರ್ವಾಹಕರಿಗೆ ಕಾರ್ಯವಾಗಿದೆ, DBA ಗಾಗಿ ಅಗತ್ಯವಿಲ್ಲ.

ನಾನೊಬ್ಬ ನಿರ್ವಾಹಕ.

PostgreSQL pg_stat_activity ಎಂಬ ವೀಕ್ಷಣೆಯನ್ನು ಹೊಂದಿದ್ದು ಅದು ತೂಗಾಡುತ್ತಿರುವ ಪ್ರಶ್ನೆಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಮತ್ತು ಅದು ಎಲ್ಲಿಯವರೆಗೆ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು.

ನಾನು ಪ್ರತಿ 5 ನಿಮಿಷಗಳಿಗೊಮ್ಮೆ ಬಂದು ನೋಡಬೇಕೇ?

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

ಇದು ಸಂಭವಿಸಲು ಯಾವುದೇ ಸ್ಪಷ್ಟ ಕಾರಣಗಳಿವೆಯೇ?

ನಾನು ಕೆಲವನ್ನು ಪಟ್ಟಿ ಮಾಡಿದ್ದೇನೆ. ಇತರ ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಉದಾಹರಣೆಗಳು. ಮತ್ತು ದೀರ್ಘಕಾಲದವರೆಗೆ ಸಂಭಾಷಣೆ ನಡೆಸಬಹುದು.

ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನಾನು pg_repack ಉಪಯುಕ್ತತೆಯ ಬಗ್ಗೆ ಸ್ಪಷ್ಟಪಡಿಸಲು ಬಯಸುತ್ತೇನೆ. ಅವಳು ವಿಶೇಷ ಲಾಕ್ ಮಾಡದಿದ್ದರೆ, ನಂತರ...

ಅವಳು ವಿಶೇಷ ಲಾಕ್ ಮಾಡುತ್ತಾಳೆ.

... ಆಗ ನಾನು ಸಂಭಾವ್ಯವಾಗಿ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು. ಈ ಸಮಯದಲ್ಲಿ ನನ್ನ ಅಪ್ಲಿಕೇಶನ್ ಏನನ್ನೂ ರೆಕಾರ್ಡ್ ಮಾಡಬಾರದು?

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

ಅಂದರೆ, ಅವನು ಅದನ್ನು ಕೊನೆಯಲ್ಲಿ ಮಾಡುತ್ತಾನೆಯೇ?

ಕೊನೆಯಲ್ಲಿ, ಅವರು ಈ ಫೈಲ್‌ಗಳನ್ನು ಸ್ವ್ಯಾಪ್ ಮಾಡಲು ವಿಶೇಷ ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ.

ಇದು VACUUM FULL ಗಿಂತ ವೇಗವಾಗಿರುತ್ತದೆಯೇ?

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

ನಮಸ್ಕಾರ! ನೀವು ಕಾರ್ ನಿರ್ವಾತದ ಕಾರ್ಯಾಚರಣೆಯ ಬಗ್ಗೆ ಮಾತನಾಡಿದ್ದೀರಿ. ಕೆಂಪು, ಹಳದಿ ಮತ್ತು ಹಸಿರು ರೆಕಾರ್ಡಿಂಗ್ ಕೋಶಗಳೊಂದಿಗೆ ಗ್ರಾಫ್ ಇತ್ತು. ಅಂದರೆ, ಹಳದಿ ಬಣ್ಣಗಳು - ಅವರು ಅಳಿಸಲಾಗಿದೆ ಎಂದು ಗುರುತಿಸಿದ್ದಾರೆ. ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಅವುಗಳಲ್ಲಿ ಹೊಸದನ್ನು ಬರೆಯಬಹುದೇ?

ಹೌದು. Postgres ಸಾಲುಗಳನ್ನು ಅಳಿಸುವುದಿಲ್ಲ. ಅಂತಹ ನಿರ್ದಿಷ್ಟತೆಯನ್ನು ಅವರು ಹೊಂದಿದ್ದಾರೆ. ನಾವು ಸಾಲನ್ನು ನವೀಕರಿಸಿದರೆ, ಹಳೆಯದನ್ನು ಅಳಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ಗುರುತಿಸುತ್ತೇವೆ. ಈ ಸಾಲನ್ನು ಬದಲಾಯಿಸಿದ ವಹಿವಾಟಿನ ಐಡಿ ಅಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನಾವು ಹೊಸ ಸಾಲನ್ನು ಬರೆಯುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ಸಮರ್ಥವಾಗಿ ಓದಬಲ್ಲ ಸೆಷನ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಒಂದು ಹಂತದಲ್ಲಿ ಅವರು ಸಾಕಷ್ಟು ವಯಸ್ಸಾಗುತ್ತಾರೆ. ಮತ್ತು ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಮೂಲತತ್ವವೆಂದರೆ ಅದು ಈ ಸಾಲುಗಳ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಅನಗತ್ಯವೆಂದು ಗುರುತಿಸುತ್ತದೆ. ಮತ್ತು ನೀವು ಅಲ್ಲಿ ಡೇಟಾವನ್ನು ಮೇಲ್ಬರಹ ಮಾಡಬಹುದು.

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

ಇಲ್ಲ, ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಸಂಪೂರ್ಣ ಸಾಲನ್ನು ಅಲ್ಲಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ. Postgres ಎರಡು ಡೇಟಾ ಸಂಗ್ರಹ ಮಾದರಿಗಳನ್ನು ಹೊಂದಿದೆ. ಇದು ಡೇಟಾ ಪ್ರಕಾರದಿಂದ ಆಯ್ಕೆಮಾಡುತ್ತದೆ. ಟೇಬಲ್‌ನಲ್ಲಿ ನೇರವಾಗಿ ಸಂಗ್ರಹಿಸಲಾದ ಡೇಟಾ ಇದೆ ಮತ್ತು ಟಾಸ್ ಡೇಟಾ ಕೂಡ ಇದೆ. ಇವು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾ: ಪಠ್ಯ, json. ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಫಲಕಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಈ ಮಾತ್ರೆಗಳ ಪ್ರಕಾರ, ಉಬ್ಬುವಿಕೆಯೊಂದಿಗೆ ಅದೇ ಕಥೆಯು ಸಂಭವಿಸುತ್ತದೆ, ಅಂದರೆ ಎಲ್ಲವೂ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಅವುಗಳನ್ನು ಕೇವಲ ಪ್ರತ್ಯೇಕವಾಗಿ ಪಟ್ಟಿ ಮಾಡಲಾಗಿದೆ.

ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಅವಧಿಯನ್ನು ಮಿತಿಗೊಳಿಸಲು ಹೇಳಿಕೆಯ ಅವಧಿ ಮೀರುವ ಪ್ರಶ್ನೆಗಳನ್ನು ಬಳಸುವುದು ಸ್ವೀಕಾರಾರ್ಹವೇ?

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

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

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

ಅಂದರೆ, ನವೀಕರಣದ ನಂತರ ಅದು ತಕ್ಷಣವೇ ಮುಚ್ಚುತ್ತದೆಯೇ?

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

ನಮಸ್ಕಾರ! ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನಾವು ಊತ ಮತ್ತು ಊತ ಮತ್ತು ನಂತರ ಸರ್ವರ್‌ನಲ್ಲಿನ ಸ್ಥಳವು ಖಾಲಿಯಾಗುವ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಊಹಿಸೋಣ. ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸಲು ಯಾವುದೇ ಸಾಧನಗಳಿವೆಯೇ?

ಸರ್ವರ್‌ನಲ್ಲಿನ ಸ್ಥಳವನ್ನು ಸರಿಯಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಅಗತ್ಯವಿದೆ.

ಉದಾಹರಣೆಗೆ, ಡಿಬಿಎ ಚಹಾಕ್ಕಾಗಿ ಹೋದರು, ರೆಸಾರ್ಟ್‌ನಲ್ಲಿದ್ದರು, ಇತ್ಯಾದಿ.

ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ರಚಿಸಿದಾಗ, ಡೇಟಾವನ್ನು ಬರೆಯದಿರುವಲ್ಲಿ ಕನಿಷ್ಠ ಕೆಲವು ರೀತಿಯ ಬ್ಯಾಕಪ್ ಜಾಗವನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ.

ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಶೂನ್ಯಕ್ಕಿಂತ ಕಡಿಮೆಯಿದ್ದರೆ ಏನು?

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

ಬೇರೆ ಯಾವುದೇ ಉಪಕರಣಗಳಿವೆಯೇ?

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

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

ಅವರೂ ಪ್ಯಾಕ್ ಮಾಡುತ್ತಾರೆ.

ಆದರೆ ನಿರ್ವಾತವು ಸೂಚ್ಯಂಕದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲವೇ?

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

ಮತ್ತು ಎರಡನೇ ಪ್ರಶ್ನೆ. ಪ್ರತಿಕೃತಿಗಳ ವರದಿಗಳು ಪ್ರತಿಕೃತಿಯ ಮೇಲೆ ಏಕೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿದೆ ಎಂದು ನನಗೆ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ. ವರದಿಗಳನ್ನು ಓದಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕೃತಿ ಬರೆಯಲಾಗುತ್ತದೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ.

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

ಆಂಡ್ರೇ, ನನಗೆ ಒಂದು ಪ್ರಶ್ನೆ ಇದೆ. ಪ್ರಸ್ತುತಿಯ ಸಮಯದಲ್ಲಿ ನೀವು ತೋರಿಸಿದ ಈ ಅದ್ಭುತ ಗ್ರಾಫ್‌ಗಳು, ಇವು ನಿಮ್ಮ ಕೆಲವು ರೀತಿಯ ಉಪಯುಕ್ತತೆಯ ಕೆಲಸದ ಫಲಿತಾಂಶವೇ? ಗ್ರಾಫ್‌ಗಳನ್ನು ಹೇಗೆ ರಚಿಸಲಾಗಿದೆ?

ಇದೊಂದು ಸೇವೆ ಓಕ್ಮೀಟರ್.

ಇದು ವಾಣಿಜ್ಯ ಉತ್ಪನ್ನವೇ?

ಹೌದು. ಇದು ವಾಣಿಜ್ಯ ಉತ್ಪನ್ನವಾಗಿದೆ.

ಮೂಲ: www.habr.com