VPN ಮೂಲಕ psql ಸಮಯ ಮಾಪನ: ನೆಟ್ವರ್ಕ್ ಕಾಯುವಿಕೆಯನ್ನು ಪ್ರಶ್ನೆಯ ಕೆಲಸದಿಂದ ಬೇರ್ಪಡಿಸುವುದು

ನಿಮ್ಮ ವರದಿ ಡೇಟಾಬೇಸ್ ಹೋಸ್ಟ್ನಲ್ಲಿ ಸುಮಾರು ಒಂದು ಸೆಕೆಂಡಿನಲ್ಲಿ ಮತ್ತು VPN ಮೂಲಕ ನಾಲ್ಕರಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ, ಮತ್ತು psql ಮುದ್ರಿಸುವ ಸಂಖ್ಯೆ ನೇರವಾಗಿ ಡೇಟಾಬೇಸ್ಗೆ ತೋರಿಸುತ್ತದೆ. ಆ ಸಂಖ್ಯೆ ಕ್ಲೈಂಟ್ ಬದಿಯ ಸ್ಟಾಪ್ವಾಚ್, ಸರ್ವರ್ನ ಅಳತೆ ಅಲ್ಲ. ಅದು ಹೇಳಿಕೆಯ ಹೊರಹೋಗುವ ದಾರಿ, ಉತ್ತರಕ್ಕಾಗಿ ಕಾಯುವಿಕೆ ಮತ್ತು ಹಿಂತಿರುಗುವ ಸಾಲುಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಈ ಮೂರನ್ನು ಬೇರ್ಪಡಿಸುವುದೇ ಯಾವ ಬದಿಯನ್ನು ಟ್ಯೂನ್ ಮಾಡಬೇಕೆಂದು ತಿಳಿಯುವ ಏಕೈಕ ದಾರಿ.

psql ಟೈಮರ್ ನಿಜವಾಗಿ ಏನನ್ನು ಅಳೆಯುತ್ತದೆ

\timing on ಕ್ಲೈಂಟ್ ಹೇಳಿಕೆಯನ್ನು ಸಾಕೆಟ್ಗೆ ಬರೆಯುವ ಮೊದಲೇ ಸ್ಟಾಪ್ವಾಚ್ ಆರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಆ ಫಲಿತಾಂಶದ ಕೊನೆಯ ಸಾಲು ಓದಿದಾಗ ನಿಲ್ಲಿಸುತ್ತದೆ. ಸರ್ವರ್ನ ಸ್ವಂತ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಆ ಕಿಟಕಿಯ ಒಳಗೆ ಎಲ್ಲೋ ಇದೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ಗಳು ಸುರಂಗದಲ್ಲಿ ಕಳೆಯುವ ಪ್ರತಿ ಮಿಲಿಸೆಕೆಂಡೂ ಸಹ. ಔಟ್ಪುಟ್ನಲ್ಲಿ ಯಾವುದೂ ಅವನ್ನು ಬೇರ್ಪಡಿಸುವುದಿಲ್ಲ. EXPLAIN ಕೂಡ ಸಂಖ್ಯೆಯನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಆದರೆ ಅದನ್ನು ಸರ್ವರ್ ಉತ್ಪಾದಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಕಾಯುವಿಕೆಯನ್ನು ಹೊರಗಿಡುತ್ತದೆ. ಎರಡು ಸಂಖ್ಯೆಗಳು, ಎರಡು ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳು.

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

psql "host=db.internal port=5432 dbname=appdb user=app" \
  -c "\timing on" \
  -c "select count(*) from orders where created_at > now() - interval '1 day';"

ಸಂಖ್ಯೆ ಇನ್ನೂ ಫಲಿತಾಂಶದ ವರ್ಗಾವಣೆಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ಅದೇ ಇಲ್ಲಿ ನಿಮಗೆ ಬೇಕಾದುದು. ಹೊಸ ಕರೆ ಸೇರಿಸುವ ಸಂಪರ್ಕ ಮತ್ತು ದೃಢೀಕರಣ ವಿನಿಮಯವನ್ನು ಅದು ಇನ್ನು ಮುಂದೆ ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ.

ಒಂದು ಹೇಳಿಕೆಯನ್ನು ಮೂರು ಮಾರ್ಗಗಳಲ್ಲಿ ಹೋಲಿಸಿ

ಅದೇ ಹೇಳಿಕೆಯನ್ನು Unix ಸಾಕೆಟ್, LAN ವಿಳಾಸ ಮತ್ತು VPN ಹೋಸ್ಟ್ ಹೆಸರಿನ ಮೂಲಕ ಚಲಾಯಿಸಿ ಮತ್ತು ಮೂರನ್ನು ಹೋಲಿಸಿ. ಕೊನೆಯದು ಮಾತ್ರ ನಿಧಾನವಾಗಿದ್ದರೆ, ಪ್ರಶ್ನೆ ಚರವಲ್ಲ.

ಪ್ರತಿ ಕರೆ ಮೊದಲು ಸಂಪರ್ಕಿಸಿ ನಂತರವೇ ಹೇಳಿಕೆಯನ್ನು ಅಳೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಪರ್ಕದ ವೆಚ್ಚ ಸಂಖ್ಯೆಯ ಹೊರಗೆ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ವರ್ಗಾವಣೆ ಒಳಗೆ ಉಳಿಯುತ್ತದೆ. WHERE ವಾಕ್ಯಾಂಶ, ಸಾಲು ಎಣಿಕೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಯಂತ್ರವನ್ನು ಒಂದೇ ರೀತಿ ಇರಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ನೀವು ಮಾರ್ಗಗಳಲ್ಲ, ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಹೋಲಿಸುತ್ತಿದ್ದೀರಿ.

psql -h /var/run/postgresql -U app -d appdb -c "\timing on" -c "select count(*) from orders;"
psql -h 10.40.0.12 -U app -d appdb -c "\timing on" -c "select count(*) from orders;"
psql -h db.vpn.internal -U app -d appdb -c "\timing on" -c "select count(*) from orders;"

LAN ನಲ್ಲಿ ವ್ಯತ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಬಹುದಾದಷ್ಟು ಚಿಕ್ಕದು; VPN ಮೂಲಕ ಹಲವು ಬಾರಿ ಹಾಗಲ್ಲ. ಮೂರು ಫಲಿತಾಂಶಗಳನ್ನು ಜೋಡಿಸಿದರೆ ಯಾವ ಕಾಯುವಿಕೆಗೆ ದಾಳಿ ಮಾಡಬೇಕೆಂದು ತಿಳಿಯುತ್ತದೆ.

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

ಸರ್ವರ್ನ ಸ್ವಂತ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವನ್ನು ತೆಗೆಯಿರಿ

ಸರ್ವರ್ ಎಷ್ಟು ಸಮಯ ಕಳೆಯಿತೆಂದು ವರದಿ ಮಾಡಬಲ್ಲದು, ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಸಂಖ್ಯೆಗೆ ಎದುರಾಗಿ ಇಡಬೇಕಾದ ಸಂಖ್ಯೆ ಅದೇ. ANALYZE ಜೊತೆ EXPLAIN ಹೇಳಿಕೆಯನ್ನು ಚಲಾಯಿಸಿ ಯೋಜನೆಯ ಒಳಗೆ ಯೋಜನೆ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, BUFFERS ಕ್ಯಾಶ್ ವರ್ತನೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ, ಅದು ಬೆಚ್ಚಗಿನ ಓಟವನ್ನು ತಣ್ಣನೆಯದಕ್ಕೆ ಎದುರಾಗಿ ವಿವರಿಸುತ್ತದೆ. ಬರೆಯಲು ಉದ್ದೇಶವಿಲ್ಲದಿದ್ದರೆ ಅದನ್ನು ಬರವಣಿಗೆ ಹೇಳಿಕೆಗಳಿಗೆ ತಿರುಗಿಸಬೇಡಿ. ಓದಲು-ಮಾತ್ರ ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಇದು ಆರಂಭಿಸಲು ಅತ್ಯಂತ ಸುರಕ್ಷಿತ ಸ್ಥಳ, ಮತ್ತು psql ಉಲ್ಲೇಖ ಟೈಮರ್ನ ಕ್ಲೈಂಟ್ ಬದಿಯ ವ್ಯಾಪ್ತಿಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ.

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

select calls, round(mean_exec_time::numeric, 2) as mean_ms, rows
from pg_stat_statements
order by mean_exec_time desc
limit 5;

ಕಾಲಮ್ ಹೆಸರುಗಳು ಬಿಡುಗಡೆಯ ಪ್ರಕಾರ ಬದಲಾಗುತ್ತವೆ: PostgreSQL 13 ಮತ್ತು ನಂತರದವು mean_exec_time ತೋರಿಸುತ್ತವೆ, ಹಳೆಯ ಆವೃತ್ತಿಗಳು ಅದನ್ನು mean_time ಎನ್ನುತ್ತವೆ, ಆದ್ದರಿಂದ ಪರಿಶೀಲಿಸಿ \d pg_stat_statements ಮೂಲಕ, ಆ ಪ್ರಶ್ನೆ ದೋಷ ನೀಡಿದರೆ. ಈ ಮೌಲ್ಯಗಳು ಯೋಜನೆಯನ್ನು ಹೊರಗಿಡುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ವರೆಗಿನ ಪ್ರಯಾಣವನ್ನೂ ಹೊರಗಿಡುತ್ತವೆ. ಆ ಹೊರಗಿಡುವಿಕೆಯೇ ಅವನ್ನು ಹೋಲಿಕೆಗೆ ಉಪಯುಕ್ತವಾಗಿಸುತ್ತದೆ.

ಹೋಗಿ-ಬಂದ ಪ್ರವಾಸಗಳನ್ನು ಎಣಿಸಿ, ಮಿಲಿಸೆಕೆಂಡುಗಳನ್ನು ಮಾತ್ರವಲ್ಲ

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

ಹೇಳಿಕೆಗಳ ಎಣಿಕೆಯನ್ನು ಅಂದಾಜಿಸುವ ಬದಲು ಅಳೆಯಿರಿ. ಒಟ್ಟನ್ನು ಓದಿ, ವರದಿಯನ್ನು ಒಮ್ಮೆ ಚಲಾಯಿಸಿ, ನಂತರ ಮತ್ತೆ ಓದಿ ಕಳೆಯಿರಿ.

select sum(calls) as calls from pg_stat_statements;
-- run the report here
select sum(calls) as calls from pg_stat_statements;

ಡೆಲ್ಟಾ ದೊಡ್ಡದಾಗಿದ್ದರೆ ಮತ್ತು ಪ್ರತಿ ಹೇಳಿಕೆ ಸರ್ವರ್ನಲ್ಲಿ ಅಗ್ಗವಾಗಿದ್ದರೆ, ಬ್ಯಾಚಿಂಗ್ ಫಲ ನೀಡುವ ಪರಿಹಾರ. ಅವಲಂಬಿತ ಪ್ರಶ್ನೆಗಳನ್ನು ಸೇರಿಸಿ, ಒಂದು ಗಣ ಆಧಾರಿತ ಹೇಳಿಕೆ ಬಳಸಿ, ಅಥವಾ ಕರ್ಸರ್ನಿಂದ ಲೂಪ್ ನಡೆಸಿ. ಸಂವಾದಾತ್ಮಕ psql ನಲ್ಲಿ, \set FETCH_COUNT 1000 ದೊಡ್ಡ ಫಲಿತಾಂಶವನ್ನು ಬ್ಯಾಚ್ಗಳಲ್ಲಿ ಬರಲು ಬಿಡುತ್ತದೆ ಮತ್ತು ವರ್ಗಾವಣೆ ಹಾಗೂ ಕ್ಲೈಂಟ್ ಮೆಮೊರಿಯ ವರ್ತನೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ. ಅದು ಸರ್ವರ್ ಕೆಲಸವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಿಧಾನ ಪ್ರಶ್ನೆಯನ್ನು ಉಳಿಸುವುದಿಲ್ಲ.

ಸುರಂಗವನ್ನು ಮರುಹರಿವು ಮತ್ತು MTU ನಿಲುಗಡೆಗಳಿಗಾಗಿ ಪರಿಶೀಲಿಸಿ

ಸಣ್ಣ ಹೇಳಿಕೆಗಳು ವೇಗವಾಗಿದ್ದು ದೊಡ್ಡ ಫಲಿತಾಂಶಗಳು ಅರ್ಧ ದಾರಿಯಲ್ಲಿ ನಿಲ್ಲುತ್ತಿದ್ದರೆ, ಪ್ರಶ್ನೆ ಸಾಮಾನ್ಯವಾಗಿ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಮಾರ್ಗವಲ್ಲ. MTU ಕೆಳಗಿನ ಕೊಂಡಿಗಿಂತ ಕಡಿಮೆಯಿರುವ ಸುರಂಗವು ತಡೆಯಲಾದ ICMP ಜೊತೆಗೂಡಿ ನಿಖರವಾಗಿ ಆ ಮಾದರಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ: ಮೊದಲ ಪ್ಯಾಕೆಟ್ಗಳು ಬರುತ್ತವೆ, ದೊಡ್ಡವು ಕಣ್ಮರೆಯಾಗುತ್ತವೆ, ಮತ್ತು ವರ್ಗಾವಣೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವವರೆಗೆ ನೇತಾಡುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಬದಿಯ ಮರುಹರಿವು ಎಣಿಕೆಗಳು ಅದನ್ನು ತೋರಿಸುತ್ತವೆ.

ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಧಾನ ವರ್ಗಾವಣೆ ನಡೆಯುತ್ತಿರುವಾಗ ಸಾಕೆಟ್ ಮತ್ತು ಕೆರ್ನೆಲ್ ಎಣಿಕೆಗಳನ್ನು ಗಮನಿಸಿ. ಮರುಹರಿವು ಮೊತ್ತಗಳು ಸಂಚಿತ, ಆದ್ದರಿಂದ ಒಂದು ಮಾದರಿ ಓದುವ ಬದಲು ಮೊದಲು ಮತ್ತು ನಂತರ ದಾಖಲಿಸಿ.

ss -tin dst 10.40.0.12
netstat -s | grep -iE "retransmit|segments retransmitted"
ping -M do -s 1400 -c 3 10.40.0.12

ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಏರುವ ಮರುಹರಿವುಗಳು, 1400 ಬೈಟ್ನಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿ 1472 ನಲ್ಲಿ ವಿಫಲವಾಗುವ ping ಜೊತೆಗೆ, ಡೇಟಾಬೇಸ್ ಸಮಸ್ಯೆಯಲ್ಲ ಬದಲಾಗಿ MTU ಸಮಸ್ಯೆಯನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ನ MTU ಕಡಿಮೆ ಮಾಡುವುದು ಅಥವಾ ಗೇಟ್ವೇಯಲ್ಲಿ MSS ಒತ್ತುವುದು ಸಾಮಾನ್ಯ ಪರಿಹಾರ, ಮತ್ತು ಅದೇ ಮೂರು ಆದೇಶಗಳು ನಂತರ ಅದನ್ನು ದೃಢೀಕರಿಸುತ್ತವೆ. ವರ್ಗಾವಣೆ ಇನ್ನೂ ನಿಧಾನವಾಗಿರುವಾಗ ಮರುಹರಿವುಗಳು ಸಮತಟ್ಟಾಗಿ ಉಳಿದರೆ, ನಷ್ಟದ ಬದಲು ಸುರಂಗಕ್ಕೆ ಅನುಮತಿಸಿದ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ನೋಡಿ.

ಸಣ್ಣ ಅನುಕ್ರಮ ಮುಂದಿನ ನಿಧಾನ ವರದಿಯನ್ನು ಆವರಿಸುತ್ತದೆ: ಒಂದು ಹೇಳಿಕೆಯನ್ನು ಸ್ಥಳೀಯವಾಗಿ, LAN ನಲ್ಲಿ ಮತ್ತು VPN ಮೂಲಕ ಹೋಲಿಸಿ; EXPLAIN ಅಥವಾ pg_stat_statements ನಿಂದ ಸರ್ವರ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಓದಿ; ಒಮ್ಮೆ ಚಲಾಯಿಸುವ ಮೊದಲು ಮತ್ತು ನಂತರ ಕರೆಗಳನ್ನು ಎಣಿಸಿ; ಮತ್ತು ದೊಡ್ಡ ಫಲಿತಾಂಶ ಚಲಿಸುವಾಗ ಮರುಹರಿವುಗಳನ್ನು ಗಮನಿಸಿ. ಪ್ರತಿ ಹೆಜ್ಜೆ ಮಾರ್ಗದ ಒಂದು ಬದಿಯನ್ನು ಹೊರಗಿಡುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಯಾವ ಘಟಕವನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬೇಕೆಂದು ಊಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.