VPN orqali psql vaqtini o'lchash: tarmoq kutishini so'rov ishidan ajratish

Hisobotingiz ma'lumotlar bazasi xostida taxminan bir soniyada va VPN orqali to'rt soniyada tugaydi, psql chop etadigan raqam esa to'g'ridan-to'g'ri ma'lumotlar bazasiga ishora qiladi. Bu raqam mijoz tomonidagi sekundomer, server o'lchovi emas. U bayonotning chiqish yo'lini, javob kutishni va qaytib kelgan qatorlarni qamrab oladi. Shu uchtasini ajratish qaysi tomonni sozlash kerakligini bilishning yagona yo'li.

psql taymeri aslida nimani o'lchaydi

\timing on mijoz bayonotni soketga yozishdan biroz oldin sekundomerni ishga tushiradi va o'sha natijaning oxirgi qatori o'qilganda to'xtatadi. Serverning o'z bajarilishi o'sha oynaning ichida qayerdadir, paketlarning tunnelda o'tkazadigan har bir millisekundi ham. Chiqishda hech narsa ularni ajratmaydi. EXPLAIN ham raqam chop etadi, lekin uni server yaratadi va mijozning kutishini hisobga olmaydi. Ikki raqam, ikki xil savol.

Bitta sessiya boshlang, vaqt o'lchashni yoqilgan holda qoldiring va kerakli bayonotni uning ichidan bajaring. Sessiyani qayta ishlatish ulanish xarajatini birinchi o'lchovdan tashqarida saqlaydi.

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';"

Raqam hali ham natijani uzatishni o'z ichiga oladi, bu yerda aynan shu kerak. U endi yangi chaqiruv qo'shadigan ulanish va autentifikatsiya almashinuvini o'z ichiga olmaydi.

Bitta bayonotni uch yo'lda solishtiring

Xuddi shu bayonotni Unix soketi, LAN manzili va VPN xost nomi orqali bajaring va uchtasini solishtiring. Agar faqat oxirgisi sekin bo'lsa, so'rov o'zgaruvchi emas.

Har bir chaqiruv avval ulanadi va faqat keyin bayonotni o'lchaydi, shuning uchun ulanish xarajati raqamdan tashqarida qoladi, uzatish esa ichida qoladi. WHERE bandini, qatorlar sonini va mijoz mashinasini bir xil saqlang, aks holda yo'llarni emas, ish yuklamalarini solishtirasiz.

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;"

LANda farq odatda e'tiborsiz qoldiradigan darajada kichik; VPN orqali ko'pincha unday emas. Uch natijani tartiblash keyin qaysi kutishga hujum qilishni aytadi.

Sekin mahalliy soket server ishini yoki rejalashtirishni bildiradi. Sekin LAN natijasi so'rovni yoki u ko'chiradigan hajmni bildiradi. Faqat VPN natijasining sekin bo'lishi yo'ldagi kechikish, MTU yoki mavjud o'tkazish qobiliyatini bildiradi va hech qanday indeks o'zgarishi buni tuzatmaydi.

Serverning o'z bajarilish vaqtini chiqaring

Server qancha vaqt sarflaganini xabar qilishi mumkin, mijoz raqami bilan qiyoslanadigan raqam aynan shu. EXPLAIN ANALYZE bilan bayonotni bajaradi va reja ichida rejalashtirish va bajarish vaqtini chop etadi, BUFFERS esa issiq yugurishni sovuqqa qarshi tez-tez tushuntiradigan kesh xatti-harakatini qo'shadi. Yozish niyatingiz bo'lmasa, uni yozish bayonotlariga qaratmang. Faqat o'qish uchun replikada boshlash uchun eng xavfsiz joy shu, va psql ma'lumotnomasi taymerning mijoz tomonidagi qamrovini hujjatlashtiradi.

Ilova allaqachon bajaradigan bayonotlar uchun pg_stat_statements hech narsani qayta ishga tushirmasdan server tomonidagi bajarilishni jamlaydi. Qatorlar normallashtirilgan so'rov bo'yicha, shuning uchun bitta yozuv bir nechta chaqiruv joyini qamrab olishi mumkin.

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

Ustun nomlari versiyaga qarab farq qiladi: PostgreSQL 13 va keyingilari mean_exec_time ni ko'rsatadi, eski versiyalar uni mean_time deb ataydi, shuning uchun tekshiring \d pg_stat_statements bilan, agar bu so'rov xato bersa. Bu qiymatlar rejalashtirishni va mijozingizgacha bo'lgan sayohatni istisno qiladi. Aynan shu istisno ularni solishtirish uchun foydali qiladi.

Borish-qaytishlarni sanang, faqat millisekundlarni emas

Ikki yuz kichik bog'liq bayonotdan qurilgan hisobot yo'l qo'shadigan har qanday kechikishni ikki yuzga ko'paytiradi. Bir million qator qaytaradigan bitta bayonot bu kechikishni bir marta to'laydi va keyin uzoq vaqt o'tkazish qobiliyatini to'laydi. Ikkalasi ham mijoz taymerida bir xil ko'rinadi va ularga qarama-qarshi tuzatishlar kerak.

Bayonotlar sonini taxmin qilish o'rniga o'lchang. Jamini o'qing, hisobotni bir marta bajaring, keyin yana o'qing va ayiring.

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

Agar delta katta bo'lsa va har bir bayonot serverda arzon bo'lsa, to'plamlash foyda beradigan tuzatishdir. Bog'liq so'rovlarni birlashtiring, bitta to'plamga asoslangan bayonotdan foydalaning yoki tsiklni kursordan boshqaring. Interaktiv psql ichida, \set FETCH_COUNT 1000 katta natija to'plamlar bilan keladi va uzatish hamda mijoz xotirasining xatti-harakatini o'zgartiradi. Bu server ishini kamaytirmaydi, shuning uchun sekin so'rovni qutqarmaydi.

Tunnelni qayta yuborishlar va MTU to'xtashlari uchun tekshiring

Kichik bayonotlar tez, katta natijalar esa yo'lning yarmida to'xtab qolsa, so'rov odatda joyida, yo'l esa yo'q. MTU asosiy bo'g'indan past bo'lgan tunnel bloklangan ICMP bilan birga aynan shu naqshni hosil qiladi: birinchi paketlar keladi, kattalari yo'qoladi va uzatish qayta urinmaguncha osilib turadi. Mijoz tomonidagi qayta yuborish hisoblagichlari buni ko'rsatadi.

Ataylab sekin uzatish ketayotganda soket va yadro hisoblagichlarini kuzating. Qayta yuborish yig'indilari jamlanadi, shuning uchun bitta namunani o'qish o'rniga ularni oldin va keyin yozib oling.

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

Uzatish paytida o'sadigan qayta yuborishlar, 1400 baytda muvaffaqiyatli bo'lib 1472 da muvaffaqiyatsiz bo'lgan ping bilan birga, ma'lumotlar bazasi emas, MTU muammosiga ishora qiladi. Tunnel interfeysining MTU sini pasaytirish yoki shlyuzda MSS ni siqish odatiy tuzatish, va o'sha uch buyruq buni keyin tasdiqlaydi. Agar uzatish hali sekin bo'lganda qayta yuborishlar tekis qolsa, yo'qotishga emas, tunnelga ruxsat berilgan o'tkazish qobiliyatiga qarang.

Qisqa ketma-ketlik keyingi sekin hisobotni qamrab oladi: bitta bayonotni mahalliy, LANda va VPN orqali solishtiring; server bajarilishini EXPLAIN yoki pg_stat_statements dan o'qing; bir marta ishga tushirishdan oldin va keyin chaqiruvlarni sanang; va katta natija harakatlanayotganda qayta yuborishlarni kuzating. Har bir qadam yo'lning bir tomonini istisno qiladi. Ulardan hech biri qaysi komponentni qayta ishga tushirishni taxmin qilishni talab qilmaydi.