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 эсвэл боломжтой зурвасын өргөн гэсэн үг бөгөөд ямар ч индекс өөрчлөлт үүнийг засахгүй.

Серверийн өөрийнх нь гүйцэтгэлийн хугацааг гаргаж аваарай

Сервер хэдий хугацаа зарцуулснаа мэдээлж чадна, клиентийн тоотой харьцуулах тоо нь яг тэр юм. EXPLAIN ANALYZE-тай мэдэгдлийг гүйцэтгэж, төлөвлөгөөний дотор төлөвлөлт ба гүйцэтгэлийн хугацааг хэвлэдэг бол 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-аас унших; нэг удаа ажиллуулахын өмнө болон дараа дуудлагыг тоолох; том үр дүн хөдөлж байх үед дахин илгээлтийг ажиглах. Алхам бүр замын нэг талыг хасана. Аль нэг нь ч аль бүрэлдэхүүнийг дахин эхлүүлэхийг таамаглахыг шаарддаггүй.