🥇PostgreSQL daxili statistikasına dərindən daxil olun. Aleksey Lesovski

Aleksey Lesovskinin 2015-ci il hesabatının transkripsiyası "PostgreSQL daxili statistikasına dərindən girin"

Hesabatın müəllifindən imtina: Qeyd edim ki, bu hesabat 2015-ci ilin noyabr ayına aiddir - 4 ildən çox vaxt keçib və xeyli vaxt keçib. Hesabatda müzakirə olunan 9.4 versiyası artıq dəstəklənmir. Son 4 il ərzində statistika ilə bağlı çoxlu yeniliklər, təkmilləşdirmələr və dəyişikliklərin meydana çıxdığı, bəzi materialların köhnəlmiş və uyğun olmadığı 5 yeni buraxılış buraxıldı. Nəzərdən keçirərkən oxucunu yanıltmamaq üçün bu yerləri qeyd etməyə çalışdım. Mən bu yerləri yenidən yazmamışam, çox var və nəticədə tam fərqli hesabat çıxacaq.

PostgreSQL DBMS nəhəng mexanizmdir və bu mexanizm koordinasiyalı işi DBMS-nin işinə birbaşa təsir edən bir çox alt sistemlərdən ibarətdir. Əməliyyat zamanı statistik məlumatlar və komponentlərin işləməsi haqqında məlumatlar toplanır ki, bu da PostgreSQL-in effektivliyini qiymətləndirməyə və performansı yaxşılaşdırmaq üçün tədbirlər görməyə imkan verir. Bununla belə, bu məlumatların çoxu var və olduqca sadələşdirilmiş formada təqdim olunur. Bu məlumatı emal etmək və şərh etmək bəzən tamamilə qeyri-trivial bir işdir və alətlər və kommunal proqramların "zooparkı" hətta inkişaf etmiş DBA-nı asanlıqla çaşdıra bilər.

Günortanız Xeyir Mənim adım Alekseydir. İlyanın dediyi kimi, PostgreSQL statistikası haqqında danışacağam.

PostgreSQL fəaliyyət statistikası. PostgreSQL-in iki statistikası var. Müzakirə olunacaq fəaliyyət statistikası. Və məlumatların paylanması haqqında planlaşdırıcı statistikası. Performansı mühakimə etməyə və birtəhər onu təkmilləşdirməyə imkan verən PostgreSQL fəaliyyət statistikası haqqında xüsusi olaraq danışacağam.

Sizə mövcud və ya ola biləcək müxtəlif problemləri həll etmək üçün statistikadan necə səmərəli istifadə edəcəyinizi söyləyəcəyəm.

Hesabatda nə olmayacaq? Hesabatda planlaşdırıcının statistikasına toxunmayacağam, çünki. Bu, verilənlər bazasında məlumatların necə saxlandığı və sorğu planlayıcısının bu məlumatların keyfiyyət və kəmiyyət xüsusiyyətləri haqqında necə təsəvvür əldə etdiyi barədə ayrıca hesabat üçün ayrıca bir mövzudur.

Və alət rəyləri olmayacaq, bir məhsulu digəri ilə müqayisə etməyəcəyəm. Reklam olmayacaq. Bunu buraxaq.

Mən sizə göstərmək istəyirəm ki, statistikadan istifadə etmək faydalıdır. Vacibdir. Qorxmadan istifadə edin. Bizə lazım olan tək şey sadə SQL və əsas SQL biliyidir.

Və problemləri həll etmək üçün hansı statistikanı seçmək barədə danışacağıq.

PostgreSQL-ə baxsaq və proseslərə baxmaq üçün əməliyyat sistemində əmr işlədirsək, “qara qutu” görəcəyik. Biz nəyisə edən bəzi proseslər görəcəyik və adı ilə onların orada nə etdiklərini, nə etdiklərini təxminən təsəvvür edə bilərik. Amma əslində bu qara qutudur, içərisinə baxa bilmirik.

CPU yükünə baxa bilərik top, biz bəzi sistem yardım proqramları tərəfindən yaddaşdan istifadəni görə bilərik, lakin PostgreSQL-in içərisinə baxa bilməyəcəyik. Bunun üçün bizə başqa vasitələr lazımdır.

Və daha da davam edərək, sizə vaxtın hara xərcləndiyini söyləyəcəyəm. PostgreSQL-i belə bir sxem şəklində təqdim etsək, o zaman vaxtın hara sərf edildiyinə cavab vermək mümkün olacaq. Bunlar iki şeydir: bu, tətbiqlərdən gələn müştəri sorğularının işlənməsi və PostgreSQL-in işləməsini təmin etmək üçün yerinə yetirdiyi fon tapşırıqlarıdır.

Yuxarı sol küncə baxmağa başlasaq, müştəri sorğularının necə işləndiyini görə bilərik. Sorğu proqramdan gəlir və gələcək iş üçün müştəri sessiyası açılır. Sorğu planlaşdırıcıya ötürülür. Planlayıcı sorğu planı qurur. Onu icraata göndərir. Cədvəllər və indekslərlə əlaqəli bir növ blok I / O məlumatları var. Lazımi məlumatlar disklərdən yaddaşa xüsusi "paylaşılan buferlər" sahəsinə oxunur. Sorğu nəticələri, əgər onlar yeniləmələrdirsə, silinirsə, WAL-da əməliyyat jurnalında qeyd olunur. Bəzi statistik məlumatlar jurnalda və ya statistika kollektorunda bitir. Və sorğunun nəticəsi müştəriyə qaytarılır. Bundan sonra müştəri hər şeyi yeni sorğu ilə təkrarlaya bilər.

Fon tapşırıqları və arxa plan prosesləri ilə bağlı nələrimiz var? Bizdə verilənlər bazasını normal iş rejimində saxlayan bir neçə proses var. Hesabatda bu proseslərə də toxunulacaq: bunlar avtovakuum, yoxlama nöqtəsi, replikasiya ilə bağlı proseslər, fon yazıcıdır. Mən hesabat verərkən onların hər birinə toxunacağam.

Statistikada hansı problemlər var?

Çoxlu məlumat. PostgreSQL 9.4 statistik məlumatlara baxmaq üçün 109 ölçü təmin edir. Bununla belə, verilənlər bazasında çoxlu cədvəllər, sxemlər, verilənlər bazaları saxlanılırsa, bütün bu ölçüləri müvafiq cədvəllərin, verilənlər bazalarının sayına vurmaq lazımdır. Yəni daha çox məlumat var. Və onun içində boğulmaq çox asandır.
Növbəti problem statistikanın sayğaclarla təmsil olunmasıdır. Bu statistikaya nəzər salsaq, sayğacların durmadan artdığını görərik. Statistikanın sıfırlanmasından çox vaxt keçsə, milyardlarla dəyər görəcəyik. Və bizə heç nə demirlər.
Tarixi yoxdur. Əgər bir növ uğursuzluğunuz varsa, 15-30 dəqiqə əvvəl bir şey düşdüsə, statistikadan istifadə edə və 15-30 dəqiqə əvvəl nə baş verdiyini görə bilməyəcəksiniz. Bu problemdir.
PostgreSQL-də quraşdırılmış alətin olmaması problemdir. Kernel tərtibatçıları heç bir yardım proqramı təqdim etmirlər. Onlarda belə bir şey yoxdur. Sadəcə verilənlər bazasında statistik məlumatlar verirlər. İstifadə edin, ona müraciət edin, istədiyinizi edin, sonra edin.
PostgreSQL-də quraşdırılmış alət olmadığı üçün bu başqa problemə səbəb olur. Çoxlu üçüncü tərəf alətləri. Az-çox birbaşa əli olan hər bir şirkət öz proqramını yazmağa çalışır. Nəticə etibarı ilə cəmiyyətdə statistika ilə işləmək üçün istifadə edə biləcəyiniz çoxlu alətlər var. Və bəzi alətlərdə bəzi xüsusiyyətlər var, digər alətlərdə başqa xüsusiyyətlər yoxdur və ya bəzi yeni xüsusiyyətlər var. Və belə bir vəziyyət yaranır ki, bir-birini üst-üstə düşən və müxtəlif funksiyaları olan iki və ya üç və ya dörd alətdən istifadə etmək lazımdır. Bu çox bezdiricidir.

Bundan nə çıxır? Proqramlardan asılı olmamaq və ya bu proqramları özünüz təkmilləşdirməmək üçün birbaşa statistika götürə bilmək vacibdir: fayda əldə etmək üçün bəzi funksiyalar əlavə edin.

Və sizə əsas SQL biliyi lazımdır. Statistikadan bəzi məlumatları əldə etmək üçün siz SQL sorğuları etməlisiniz, yəni seçmək, qoşulmaq necə edildiyini bilməlisiniz.

Statistika bizə bir neçə şey deyir. Onları kateqoriyalara bölmək olar.

Birinci kateqoriya verilənlər bazasında baş verən hadisələrdir. Bu, verilənlər bazasında bəzi hadisə baş verdiyi zamandır: sorğu, cədvələ giriş, avtovakuum, öhdəçiliklər, onda bunların hamısı hadisələrdir. Bu hadisələrə uyğun sayğaclar artırılır. Və biz bu hadisələri izləyə bilərik.
İkinci kateqoriya cədvəllər, verilənlər bazası kimi obyektlərin xüsusiyyətləridir. Onların xassələri var. Bu cədvəllərin ölçüsüdür. Cədvəllərin artımını, indekslərin artımını izləyə bilərik. Biz dinamikada dəyişiklikləri görə bilərik.
Üçüncü kateqoriya isə tədbirə sərf olunan vaxtdır. Müraciət bir hadisədir. Onun özünəməxsus müddət ölçüsü var. Burada başladı, burada bitdi. Biz bunu izləyə bilərik. Ya diskdən blok oxumaq, ya da yazma vaxtı. Bu işlər də izlənilir.

Statistikanın mənbələri aşağıdakı kimi təqdim olunur:

Paylaşılan yaddaşda (ortaq buferlər) orada statik məlumatların yerləşdirilməsi üçün bir seqment var, müəyyən hadisələr baş verdikdə və ya verilənlər bazasının işində bəzi məqamlar yarandıqda daim artırılan sayğaclar da var.
Bütün bu sayğaclar istifadəçi üçün mövcud deyil və hətta administrator üçün də mövcud deyil. Bunlar aşağı səviyyəli şeylərdir. Onlara daxil olmaq üçün PostgreSQL SQL funksiyaları şəklində interfeys təqdim edir. Biz bu funksiyalardan istifadə edərək seçmə seçimlər edə və bir növ metrik (və ya ölçülər dəsti) əldə edə bilərik.
Bununla belə, bu funksiyalardan istifadə etmək həmişə əlverişli deyil, ona görə də funksiyalar baxışlar üçün əsasdır (VIEWs). Bunlar müəyyən bir alt sistem və ya verilənlər bazasındakı bəzi hadisələr toplusu üzrə statistik məlumat verən virtual cədvəllərdir.
Bu daxili görünüşlər (Görünüşlər) statistika ilə işləmək üçün əsas istifadəçi interfeysidir. Onlar standart olaraq heç bir əlavə parametr olmadan mövcuddur, siz dərhal onlardan istifadə edə, baxa, oradan məlumat ala bilərsiniz. Və töhfələr də var. Töhfələr rəsmidir. Siz postgresql-contrib paketini (məsələn, postgresql94-contrib) quraşdıra, lazımi modulu konfiqurasiyaya yükləyə, onun üçün parametrləri təyin edə, PostgreSQL-i yenidən başladın və ondan istifadə edə bilərsiniz. (Qeyd. Dağıtımdan asılı olaraq, töhfənin son versiyalarında paket əsas paketin bir hissəsidir).
Və qeyri-rəsmi töhfələr var. Onlar standart PostgreSQL paylanması ilə təmin edilmir. Onlar ya tərtib edilməli, ya da kitabxana kimi quraşdırılmalıdır. Seçimlər, bu qeyri-rəsmi töhfənin tərtibatçısının nə ilə gəldiyindən asılı olaraq çox fərqli ola bilər.

Bu slayd PostgreSQL 9.4-də mövcud olan bütün görünüşləri (GÖRÜNÜŞLƏR) və bəzi funksiyaları göstərir. Gördüyümüz kimi, onların sayı çoxdur. Və bunu ilk dəfə yaşayırsınızsa, çaşmaq olduqca asandır.

Ancaq əvvəlki şəkli çəksək Как тратится время на PostgreSQL və bu siyahıya uyğun gələndə bu şəkli əldə edirik. Hər bir görünüş (Görünüşlər) və ya hər bir funksiyadan PostgreSQL işlədiyimiz zaman müvafiq statistikanı əldə etmək üçün bu və ya digər məqsəd üçün istifadə edə bilərik. Və biz artıq alt sistemin işləməsi haqqında müəyyən məlumat əldə edə bilərik.

Baxacağımız ilk şey budur pg_stat_database. Gördüyümüz kimi, bu bir təmsilçilikdir. O, çoxlu məlumat ehtiva edir. Ən müxtəlif məlumatlar. Və bu, verilənlər bazasında baş verənlərlə bağlı çox faydalı məlumat verir.

Oradan nə götürə bilərik? Ən sadə şeylərdən başlayaq.

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

Baxa biləcəyimiz ilk şey önbellek hit faizidir. Cache hit faizi faydalı bir metrikdir. Bu, paylaşılan bufer keşindən nə qədər məlumat götürüldüyünü və diskdən nə qədər oxunduğunu təxmin etməyə imkan verir.

Aydındır ki nə qədər çox önbellek vursaq, bir o qədər yaxşıdır. Bu metrikanı faizlə qiymətləndiririk. Və, məsələn, əgər bizdə bu cache hitlərinin faizi 90%-dən çox olarsa, bu yaxşıdır. Əgər 90%-dən aşağı düşərsə, o zaman məlumatın isti başını yaddaşda saxlamaq üçün kifayət qədər yaddaşımız yoxdur. Və bu məlumatlardan istifadə etmək üçün PostgreSQL diskə daxil olmağa məcbur olur və bu, məlumatların yaddaşdan oxunduğundan daha yavaşdır. Və yaddaşı artırmaq barədə düşünmək lazımdır: ya paylaşılan buferləri artırın, ya da dəmir yaddaşı (RAM) artırın.

select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;

Bu tamaşadan başqa nə götürmək olar? Verilənlər bazasında baş verən anomaliyaları görə bilərsiniz. Burada nə göstərilir? Öhdəliklər, geri çəkilmələr, müvəqqəti faylların yaradılması, onların ölçüsü, çıxılmaz vəziyyətlər və münaqişələr var.

Bu sorğudan istifadə edə bilərik. Bu SQL olduqca sadədir. Və bu məlumatları özümüz görə bilərik.

Və burada həddi dəyərlər var. Biz öhdəliklərin və geri çəkilmələrin nisbətinə baxırıq. Öhdəliklər əməliyyatın uğurlu təsdiqidir. Geri dönmələr geri çəkilmədir, yəni tranzaksiya bəzi iş gördü, verilənlər bazası gərginləşdirildi, bir şey hesab edildi və sonra uğursuzluq baş verdi və əməliyyatın nəticələri ləğv edildi. yəni. daim artan geri çəkilmələrin sayı pisdir. Və birtəhər onlardan qaçınmalı və bunun baş verməməsi üçün kodu redaktə etməlisiniz.

Münaqişələr replikasiya ilə bağlıdır. Və onlardan da çəkinmək lazımdır. Əgər replikada yerinə yetirilən bəzi sorğularınız varsa və münaqişələr yaranarsa, bu münaqişələri təhlil etməli və nə baş verdiyini görməlisiniz. Təfərrüatları qeydlərdə tapa bilərsiniz. Tətbiq sorğularının səhvsiz işləməsi üçün münaqişələri həll edin.

Kilidlər də pis vəziyyətdir. Sorğular resurslar uğrunda rəqabət apardıqda, bir sorğu bir resursa daxil olub kilidi götürdü, ikinci sorğu ikinci resursa daxil oldu və həmçinin kilidi götürdü, sonra hər iki sorğu bir-birinin resurslarına daxil oldu və qonşunun kilidi buraxmasını gözləyərək bloklandı. Bu da problemli vəziyyətdir. Onlara müraciətlərin yenidən yazılması və resurslara girişin seriallaşdırılması səviyyəsində həll edilməlidir. Və əgər siz dalana dirənmələrinizin durmadan artdığını görsəniz, qeydlərdəki detallara baxmaq, yaranmış vəziyyətləri təhlil etmək və problemin nədən ibarət olduğunu görmək lazımdır.

Müvəqqəti fayllar (temp_files) da pisdir. İstifadəçi sorğusunun operativ, müvəqqəti məlumatları yerləşdirmək üçün kifayət qədər yaddaşı olmadıqda, o, diskdə fayl yaradır. Yaddaşdakı müvəqqəti buferdə yerinə yetirə biləcəyi bütün əməliyyatlar artıq diskdə yerinə yetirilməyə başlayır. Yavaşdır. Bu, sorğunun icra müddətini artırır. PostgreSQL-ə sorğu göndərən müştəri isə bir az sonra cavab alacaq. Bütün bu əməliyyatlar yaddaşda yerinə yetirilərsə, Postgres çox daha sürətli cavab verəcək və müştəri daha az gözləyəcək.

pg_stat_bgwriter - Bu görünüş iki PostgreSQL fon alt sisteminin işini təsvir edir: checkpointer и background writer.

Başlamaq üçün, sözdə nəzarət nöqtələrini təhlil edək. checkpoints. Nəzarət məntəqələri nədir? Yoxlama nöqtəsi əməliyyat jurnalında qeyd edilən bütün məlumat dəyişikliklərinin diskdəki məlumatlarla uğurla sinxronlaşdırıldığını göstərən mövqedir. Proses iş yükündən və parametrlərdən asılı olaraq uzun ola bilər və əsasən paylaşılan buferlərdəki çirkli səhifələrin diskdəki məlumat faylları ilə sinxronlaşdırılmasından ibarətdir. Bu nə üçündür? PostgreSQL hər zaman diskə daxil olsa və oradan məlumat götürsə və hər girişdə məlumat yazsaydı, bu, yavaş olardı. Buna görə də PostgreSQL yaddaş seqmentinə malikdir, onun ölçüsü konfiqurasiyadakı parametrlərdən asılıdır. Postgres sonrakı emal və ya sorğu üçün bu yaddaşda əməliyyat məlumatları ayırır. Məlumatların dəyişdirilməsi tələbləri olduqda, onlar dəyişdirilir. Və məlumatların iki versiyasını alırıq. Biri yaddaşda, digəri diskdə. Və vaxtaşırı bu məlumatları sinxronlaşdırmalısınız. Bizə yaddaşda dəyişdirilənlərin diskə sinxronizasiyası lazımdır. Bunun üçün yoxlama məntəqələri lazımdır.

Yoxlama məntəqəsi paylaşılan buferlərdən keçir, yoxlama məntəqəsi üçün lazım olan çirkli səhifələri qeyd edir. Sonra ortaq buferlərdən ikinci keçidə başlayır. Və yoxlama nöqtəsi üçün qeyd olunan səhifələr, o, artıq onları sinxronlaşdırır. Beləliklə, məlumatlar artıq disklə sinxronlaşdırılır.

İki növ nəzarət nöqtəsi var. Bir yoxlama nöqtəsi vaxt aşımı zamanı yerinə yetirilir. Bu keçid məntəqəsi faydalı və yaxşıdır - checkpoint_timed. Və tələb olunan keçid məntəqələri var - checkpoint required. Belə bir yoxlama nöqtəsi çox böyük məlumat qeydimiz olduqda baş verir. Biz çoxlu əməliyyat qeydlərini qeyd etdik. PostgreSQL isə hesab edir ki, o, bütün bunları mümkün qədər tez sinxronizasiya etməli, yoxlama nöqtəsi yaratmalı və davam etməlidir.

Və statistikaya baxsanız pg_stat_bgwriter və nəyə sahib olduğunuzu görün checkpoint_req checkpoint_timed-dən çox böyükdür, onda bu pisdir. Niyə pis? Bu o deməkdir ki, PostgreSQL diskə məlumat yazmaq lazım olduqda daimi stress altında olur. Taymout ilə yoxlama məntəqəsi daha az streslidir və daxili cədvələ uyğun olaraq həyata keçirilir və sanki zamanla uzanır. PostgreSQL işdə fasilə vermək və disk alt sistemini gərginləşdirməmək qabiliyyətinə malikdir. Bu PostgreSQL üçün faydalıdır. Yoxlama məntəqəsi zamanı yerinə yetirilən sorğular disk alt sisteminin məşğul olması səbəbindən stress keçirməyəcək.

Yoxlama məntəqəsini tənzimləmək üçün üç parametr var:

сheckpoint_segments.
сheckpoint_timeout.
сheckpoint_competion_target.

Onlar nəzarət nöqtələrinin işinə nəzarət etməyə imkan verir. Amma mən onların üzərində dayanmayacağam. Onların təsiri ayrı bir məsələdir.

Diqqət: Hesabatda nəzərdən keçirilən 9.4-cü versiya artıq aktual deyil. PostgreSQL-in müasir versiyalarında parametr checkpoint_segments parametrləri ilə əvəz olunur min_wal_size и max_wal_size.

Növbəti alt sistem fon müəllifidir - background writer. O nə edir? Daim sonsuz bir döngədə işləyir. Səhifələri paylaşılan buferlərə skan edir və tapdığı çirkli səhifələri diskə təmizləyir. Bu yolla, yoxlama zamanı nəzarətçinin daha az iş görməsinə kömək edir.

O, başqa nəyə lazımdır? O, məlumatların yerləşdirilməsi üçün qəflətən (böyük miqdarda və dərhal) tələb olunarsa, paylaşılan buferlərdə təmiz səhifələrə ehtiyacı təmin edir. Tutaq ki, sorğunun təmiz səhifələr tələb olunduğu və onlar artıq paylaşılan buferlərdə olduğu bir vəziyyət yaranıb. Postgres backend sadəcə götürüb istifadə edir, özü heç nə təmizləmək məcburiyyətində deyil. Ancaq birdən belə səhifələr yoxdursa, backend fasilə verir və onları diskə silmək və öz ehtiyacları üçün götürmək üçün səhifələri axtarmağa başlayır - bu, hazırda icra olunan sorğunun vaxtına mənfi təsir göstərir. Əgər bir parametriniz olduğunu görsəniz maxwritten_clean böyükdür, bu o deməkdir ki, fon yazıçısı öz işini görmür və parametrləri artırmaq lazımdır bgwriter_lru_maxpagesbir dövrədə daha çox iş görə bilsin, daha çox səhifə təmizləsin.

Və başqa bir çox faydalı göstəricidir buffers_backend_fsync. Yavaş olduğu üçün arxa uçlar fsync etmir. Onlar fsync-i IO yığını yoxlama nöqtəsinə keçirlər. Yoxlama nöqtəsinin öz növbəsi var, o, vaxtaşırı fsync-i emal edir və yaddaşdakı səhifələri diskdəki fayllarla sinxronlaşdırır. Yoxlama nöqtəsi növbəsi böyük və doludursa, o zaman arxa uç özü fsync etməyə məcbur olur və bu, arxa ucunu yavaşlatır., yəni müştəri mümkün olduğundan daha gec cavab alacaq. Bu dəyərin sıfırdan böyük olduğunu görsəniz, bu artıq bir problemdir və fon yazıcısının parametrlərinə diqqət yetirməli və həmçinin disk alt sisteminin işini qiymətləndirməlisiniz.

Diqqət: _Aşağıdakı mətn təkrarlama ilə bağlı statistik baxışları təsvir edir. Görünüşün və funksiyaların adlarının əksəriyyəti Postgres 10-da dəyişdirilib. xlog haqqında wal и location haqqında lsn funksiya/görüntü adlarında və s. Xüsusi misal, funksiya pg_xlog_location_diff() olaraq adlandırıldı pg_wal_lsn_diff()._

Bizdə də burada çox şey var. Ancaq bizə yalnız yerlə bağlı maddələr lazımdır.

Bütün dəyərlərin bərabər olduğunu görsək, bu idealdır və replika ustadan geri qalmır.

Buradakı bu onaltılıq mövqe əməliyyat jurnalındakı mövqedir. Verilənlər bazasında hər hansı bir fəaliyyət varsa, o, daim artır: daxil edir, silir və s.

сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());

Əgər bunlar fərqlidirsə, deməli, bir növ gecikmə var. Lag, replikanın masterdan geri qalmasıdır, yəni verilənlər serverlər arasında fərqlənir.

Gecikmənin üç səbəbi var:

Bu, fayl sinxronizasiyasını idarə edə bilməyən disk alt sistemidir.
Bunlar mümkün şəbəkə xətaları və ya məlumatların replikaya çatmağa vaxtı olmadığı və onu təkrarlaya bilmədiyi zaman şəbəkənin həddindən artıq yüklənməsidir.
Və prosessor. Prosessor çox nadir haldır. Mən bunu iki-üç dəfə görmüşəm, amma bu da ola bilər.

Və burada statistikadan istifadə etməyə imkan verən üç sorğu var. Əməliyyat jurnalımızda nə qədər qeyd edildiyini təxmin edə bilərik. Belə bir funksiya var pg_xlog_location_diff və replikasiya gecikməsini bayt və saniyələrlə qiymətləndirə bilərik. Bunun üçün biz də bu görünüşdən (GÖRÜNÜŞLƏR) dəyəri istifadə edirik.

Qeyd: _pg_xlog_location əvəzinədiff() funksiyası ilə siz çıxarma operatorundan istifadə edib bir yeri digərindən çıxara bilərsiniz. Rahat.

Saniyədə olan gecikmə ilə bir an var. Ustada heç bir aktivlik yoxdursa, əməliyyat təxminən 15 dəqiqə əvvəl orada olub və heç bir aktivlik yoxdur və replikadakı bu geriliyə baxsaq, 15 dəqiqəlik bir gecikmə görəcəyik. Bunu xatırlamağa dəyər. Və bu gecikməyə baxdığınız zaman stupora səbəb ola bilər.

pg_stat_all_tables başqa bir faydalı görünüşdür. Cədvəllərdəki statistik məlumatları göstərir. Verilənlər bazasında cədvəllərimiz olduqda, onunla hansısa fəaliyyət, bəzi hərəkətlər olur, biz bu məlumatı bu görünüşdən əldə edə bilərik.

select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;

Baxa biləcəyimiz ilk şey ardıcıl cədvəl taramalarıdır. Bu keçidlərdən sonrakı rəqəmin özü mütləq pis deyil və artıq bir şey etməli olduğumuzu göstərmir.

Bununla belə, ikinci bir metrik var - seq_tup_read. Bu, ardıcıl skandan qaytarılan sətirlərin sayıdır. Əgər orta rəqəm 1, 000, 10, 000-dən çox olarsa, bu, artıq bir göstəricidir ki, siz haradasa bir indeks yaratmalısınız ki, girişlər indekslə olsun və ya belə ardıcıl skanlardan istifadə edən sorğuları optimallaşdırmaq mümkün olsun. bu olmur. olub.

Sadə bir nümunə - deyək ki, böyük OFFSET və LIMIT olan sorğu buna dəyər. Məsələn, cədvəldə 100 sətir skan edilir və bundan sonra 000 tələb olunan sətir götürülür və əvvəlki skan edilmiş sətirlər silinir. Bu da pis haldır. Və belə sorğular optimallaşdırılmalıdır. Və burada belə sadə bir SQL sorğusu var, onu görə bilərsiniz və alınan nömrələri qiymətləndirə bilərsiniz.

select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;

Cədvəl ölçülərini bu cədvəldən istifadə etməklə və əlavə funksiyalardan istifadə etməklə də əldə etmək olar pg_total_relation_size(), pg_relation_size().

Ümumiyyətlə, metakomandalar var dt и diPSQL-də istifadə edə biləcəyiniz, həmçinin cədvəl və indeks ölçülərinə baxa bilərsiniz.

Bununla belə, funksiyaların istifadəsi, hətta indeksləri nəzərə alaraq və ya indeksləri nəzərə almadan cədvəllərin ölçülərinə baxmağa kömək edir və artıq verilənlər bazasının böyüməsinə, yəni bizimlə necə böyüdüyünə əsaslanaraq bəzi təxminlər aparmağa kömək edir. nə intensivliyi və artıq ölçülərin optimallaşdırılması ilə bağlı bəzi nəticələr çıxarın.

Fəaliyyət yaz. Rekord nədir? Əməliyyata baxaq UPDATE – cədvəldə sətirlərin yenilənməsi əməliyyatı. Əslində, yeniləmə iki əməliyyatdır (və ya daha çox). Bu, yeni sıra versiyasını daxil edir və köhnə sıra versiyasını köhnəlmiş kimi qeyd edir. Daha sonra avtovakuum gələcək və xətlərin bu köhnəlmiş versiyalarını təmizləyəcək, bu yeri təkrar istifadə üçün əlçatan kimi qeyd edin.

Həmçinin, yeniləmə yalnız cədvəli yeniləməkdən ibarət deyil. Bu, hələ də indeks yeniləməsidir. Cədvəldə çoxlu indeksiniz varsa, yeniləmə ilə sorğuda yenilənmiş sahələrin iştirak etdiyi bütün indekslər də yenilənməlidir. Bu indekslərdə təmizlənməli olan köhnəlmiş sıra versiyaları da olacaq.

select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;

Dizaynına görə UPDATE ağır çəkili əməliyyatdır. Ancaq onları asanlaşdırmaq olar. Yemək hot updates. Onlar PostgreSQL 8.3 versiyasında ortaya çıxdı. Bəs bu nədir? Bu, indekslərin yenidən qurulmasına səbəb olmayan yüngül yeniləmədir. Yəni biz rekordu yenilədik, ancaq səhifədəki (cədvələ aid olan) yalnız qeyd yeniləndi və indekslər hələ də səhifədəki eyni qeydi göstərir. Bir az belə maraqlı bir iş məntiqi var, boşluq gələndə bu zəncirlər var hot yenidən qurur və hər şey indeksləri yeniləmədən işləməyə davam edir və hər şey daha az resurs israfı ilə baş verir.

Və nə vaxtsa n_tup_hot_upd böyük, çox yaxşıdır. Bu o deməkdir ki, yüngül yeniləmələr üstünlük təşkil edir və bu, resurslar baxımından bizim üçün daha ucuzdur və hər şey qaydasındadır.

ALTER TABLE table_name SET (fillfactor = 70);

Həcmi necə artırmaq olar hot updateov? istifadə edə bilərik fillfactor. O, INSERT-lərdən istifadə edərək cədvəldə səhifəni doldurarkən ayrılmış boş yerin ölçüsünü müəyyən edir. Əlavələr cədvələ getdikdə, səhifəni tamamilə doldururlar, orada boş yer qoymurlar. Sonra yeni bir səhifə vurğulanır. Məlumat yenidən doldurulur. Və bu standart davranışdır, doldurma faktoru = 100%.

Doldurma faktorunu 70%-ə təyin edə bilərik. Yəni əlavələrlə yeni səhifə ayrıldı, ancaq səhifənin yalnız 70%-i dolduruldu. Ehtiyatda isə 30% qalıb. Yeniləmə etmək lazım olduqda, bu, çox güman ki, eyni səhifədə baş verəcək və sıranın yeni versiyası eyni səhifəyə sığacaq. Və hot_update ediləcək. Bu, cədvəllərə yazmağı asanlaşdırır.

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

Avtovakuum növbəsi. Autovacuum elə bir alt sistemdir ki, PostgreSQL-də çox az statistika var. Biz yalnız pg_stat_activity-dəki cədvəllərdə hazırda nə qədər vakuumumuz olduğunu görə bilərik. Bununla belə, onun hərəkət zamanı növbədə neçə masa olduğunu başa düşmək çox çətindir.

Qeyd: _Postgres 10-dan bəri vakuum vakuumunu izləmək vəziyyəti çox yaxşılaşdı - pg_stat_progress görünüşü ortaya çıxdıvakuum, bu, avtovakuum monitorinqi məsələsini xeyli asanlaşdırır.

Bu sadələşdirilmiş sorğudan istifadə edə bilərik. Və biz vakuumun nə vaxt edilməsi lazım olduğunu görə bilərik. Bəs, vakuum necə və nə vaxt başlamalıdır? Bunlar əvvəllər haqqında danışdığım simlərin köhnə versiyalarıdır. Yeniləmə baş verdi, sıranın yeni versiyası daxil edildi. Simin köhnəlmiş versiyası ortaya çıxdı. Cədvəl pg_stat_user_tables belə bir parametr var n_dead_tup. Bu, "ölü" sıraların sayını göstərir. Ölü cərgələrin sayı müəyyən bir həddən artıq olduqda, masaya avtovakuum gələcək.

Və bu hədd necə hesablanır? Bu, cədvəldəki sətirlərin ümumi sayının çox xüsusi faizidir. Parametri var autovacuum_vacuum_scale_factor. Bu faizi müəyyən edir. Tutaq ki, 10% + 50 sətirdən ibarət əlavə baza həddi var. Bəs nə baş verir? Cədvəldəki bütün sətirlərin "10% + 50" dən daha çox ölü cərgəmiz olduqda, cədvəli avtovakuuma qoyuruq.

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

Bununla belə, bir məqam var. Parametrlər üçün əsas həddlər av_base_thresh и av_scale_factor fərdi olaraq təyin oluna bilər. Və müvafiq olaraq, hədd qlobal deyil, cədvəl üçün fərdi olacaqdır. Buna görə hesablamaq üçün orada hiylə və fəndlərdən istifadə etməlisiniz. Əgər maraqlanırsınızsa, Avitodan olan həmkarlarımızın təcrübəsinə baxa bilərsiniz (slayddakı keçid etibarsızdır və mətndə yenilənib).

üçün yazdılar munin pluginki, bunları nəzərə alır. İki çarşafda ayaq örtüyü var. Ancaq o, düzgün düşünür və kifayət qədər effektiv şəkildə bizə az olan masalar üçün çox vakuuma ehtiyac duyduğumuz yeri qiymətləndirməyə imkan verir.

Bununla bağlı nə edə bilərik? Əgər uzun növbəmiz varsa və avtovakuum öhdəsindən gələ bilmirsə, o zaman vakuum işçilərinin sayını artıra və ya sadəcə vakuumu daha aqressiv edə bilərik.daha əvvəl tetikler ki, cədvəli kiçik parçalara ayırır. Beləliklə, növbə azalacaq. - Burada əsas odur ki, disklərin yüklənməsinə nəzarət edək, çünki. Vakuum işi pulsuz deyil, baxmayaraq ki, SSD / NVMe cihazlarının meydana gəlməsi ilə problem daha az nəzərə çarpır.

pg_stat_all_indexes indekslər üzrə statistikadır. O, böyük deyil. Və biz ondan indekslərin istifadəsi haqqında məlumat ala bilərik. Və məsələn, əlavə olaraq hansı indekslərimizin olduğunu müəyyən edə bilərik.

Artıq dediyim kimi, yeniləmə yalnız cədvəllərin yenilənməsi deyil, həm də indekslərin yenilənməsidir. Müvafiq olaraq, cədvəldə çoxlu indeksimiz varsa, cədvəldəki sətirləri yeniləyərkən indekslənmiş sahələrin indeksləri də yenilənməlidir və Əgər indeks skanları olmayan istifadə olunmamış indekslərimiz varsa, onlar bizimlə balast kimi asılır. Və onlardan qurtulmaq lazımdır. Bunun üçün bizə bir sahə lazımdır idx_scan. Biz sadəcə indeks taramalarının sayına baxırıq. Nisbətən uzun statistik saxlama müddətində (ən azı 2-3 həftə) indekslərin sıfır skanları varsa, çox güman ki, bunlar pis indekslərdir, onlardan qurtulmalıyıq.

Qeyd: Axın replikasiya klasterləri vəziyyətində istifadə olunmamış indeksləri axtararkən, klasterin bütün qovşaqlarını yoxlamaq lazımdır, çünki statistika qlobal deyil və əgər indeks masterdə istifadə edilmirsə, o zaman replikalarda istifadə edilə bilər (əgər yük varsa).

İki keçid:

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

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

Bunlar istifadə olunmamış indeksləri axtarmaq üçün daha təkmil sorğu nümunələridir.

İkinci keçid olduqca maraqlı sorğudur. Bunun içində çox qeyri-trivial məntiq var. Mən onu nəzərdən keçirməyi tövsiyə edirəm.

İndekslərlə başqa nə yekunlaşdırılmalıdır?

İstifadə edilməmiş indekslər pisdir.
Onlar yer tuturlar.
Yeniləmə əməliyyatlarını yavaşlatın.
Vakuum üçün əlavə iş.

İstifadə edilməmiş indeksləri silsək, onda biz yalnız verilənlər bazasını yaxşılaşdıracağıq.

Növbəti görünüş pg_stat_activity. Bu yardım proqramının analoqudur ps, yalnız PostgreSQL-də. Əgər ps'Ohm o zaman əməliyyat sistemindəki prosesləri izləyirsən pg_stat_activity sizə PostgreSQL daxilində fəaliyyət göstərəcək.

Oradan nə götürə bilərik?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

Biz verilənlər bazasında baş verən ümumi fəaliyyəti görə bilərik. Yeni bir yerləşdirmə edə bilərik. Orada hər şey partladı, yeni bağlantılar qəbul edilmir, tətbiqdə səhvlər tökülür.

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

Biz bu kimi bir sorğu işlədə bilərik və maksimum əlaqə limitinə nisbətən bağlantıların ümumi faizini görə bilərik və kimin ən çox əlaqəmiz olduğunu görə bilərik. Və bu verilmiş halda biz həmin istifadəçini görürük cron_role 508 əlaqə açdı. Və ona bir şey oldu. Bununla məşğul olmaq və görmək lazımdır. Və tamamilə mümkündür ki, bu, bir növ anomal sayda əlaqələrdir.

Əgər OLTP yükümüz varsa, sorğular sürətli, çox sürətli olmalıdır və uzun sorğular olmamalıdır. Ancaq uzun istəklər varsa, qısa müddətdə narahat olmaq üçün heç bir şey yoxdur, amma uzun müddətdə uzun sorğular verilənlər bazasına zərər verir, cədvəl parçalanması baş verdikdə cədvəllərin şişkinlik təsirini artırır. Həm şişkinlik, həm də uzun sorğular atılmalıdır.

select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;

Nəzərə alın: belə bir sorğu ilə biz uzun sorğular və əməliyyatları müəyyən edə bilərik. funksiyasından istifadə edirik clock_timestamp() iş vaxtını müəyyən etmək. Uzun sorğular tapdıq, onları xatırlaya, yerinə yetirə bilərik explain, planlara baxın və bir şəkildə optimallaşdırın. Mövcud uzun istəkləri çəkirik və yaşayırıq.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Bad tranzaksiyalar əməliyyatda boşdur və tranzaksiyada boşdur (abort edilmiş) əməliyyatlar.

Bunun mənası nədi? Əməliyyatların bir neçə vəziyyəti var. Və bu dövlətlərdən biri hər an ala bilər. Dövlətləri müəyyən etmək üçün bir sahə var state bu baxışda. Və dövləti müəyyən etmək üçün ondan istifadə edirik.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Və yuxarıda dediyim kimi, bu iki dövlət tranzaksiyada boş və əməliyyatda boş (abort edilmiş) pisdir. Bu nədir? Tətbiq əməliyyatı açdıqda, bəzi hərəkətlər etdi və öz işinə başladı. Əməliyyat açıq qalır. O, asılır, heç nə baş vermir, əlaqə tələb edir, dəyişdirilmiş sıralarda kilidlənir və Postrges əməliyyat mühərrikinin arxitekturasına görə potensial olaraq hətta digər cədvəllərin şişkinliyini artırır. Və bu cür əməliyyatlar da vurulmalıdır, çünki ümumiyyətlə, hər halda zərərlidir.

Əgər verilənlər bazanızda onlardan 5-10-20-dən çox olduğunu görürsünüzsə, o zaman narahat olmaq və onlarla nəsə etməyə başlamaq lazımdır.

Burada hesablama vaxtı üçün də istifadə edirik clock_timestamp(). Biz əməliyyatları çəkirik, tətbiqi optimallaşdırırıq.

Yuxarıda dediyim kimi, kilidlər iki və ya daha çox əməliyyatın bir və ya bir qrup resurs uğrunda rəqabət aparmasıdır. Bunun üçün sahəmiz var waiting boolean dəyəri ilə true və ya false.

Doğrudur - bu o deməkdir ki, proses gözləyir, nəsə etmək lazımdır. Bir proses gözlədikdə, prosesi başlatan müştəri də gözləyir. Brauzerdəki müştəri oturur və gözləyir.

Diqqət: _Postgres 9.6-dan başlayaraq, sahə waiting silindi və daha iki informativ sahə ilə əvəz olundu wait_event_type и wait_event._

Bəs nə etməli? Əgər uzun müddət doğru görürsənsə, o zaman belə istəklərdən qurtulmalısan. Biz sadəcə belə əməliyyatları çəkirik. Biz tərtibatçılara nəyi optimallaşdırmaq lazım olduğunu yazırıq ki, resurslar üçün yarış olmasın. Və sonra tərtibatçılar bunun baş verməməsi üçün tətbiqi optimallaşdırırlar.

Və həddindən artıq, lakin potensial ölümcül olmayan bir hadisədir çıxılmaz vəziyyətlərin yaranması. İki tranzaksiya iki resursu yenilədi, sonra yenidən onlara, artıq əks resurslara daxil olur. Bu vəziyyətdə PostgreSQL əməliyyatın özünü götürür və vurur ki, digəri işə davam edə bilsin. Bu çıxılmaz vəziyyətdir və o, özünü başa düşmür. Buna görə də PostgreSQL həddindən artıq tədbirlər görməyə məcburdur.

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

Və burada kilidləri izləməyə imkan verən iki sorğu var. Görünüşdən istifadə edirik pg_locks, bu, ağır kilidləri izləməyə imkan verir.

Və ilk keçid sorğu mətninin özüdür. Olduqca uzundur.

İkinci keçid isə kilidlər haqqında məqalədir. Oxumaq faydalıdır, çox maraqlıdır.

Bəs biz nə görürük? İki sorğu görürük. ilə əməliyyat ALTER TABLE bloklayan əməliyyatdır. Başladı, amma bitmədi və bu əməliyyatı yerləşdirən proqram haradasa başqa işlər görür. Və ikinci sorğu yeniləmədir. İşinə davam etməzdən əvvəl dəyişdirmə cədvəlinin bitməsini gözləyir.

Kimin kimi kilidlədiyini, kimin kimi saxladığını belə öyrənə bilərik və bununla daha da məşğul ola bilərik.

Növbəti moduldur pg_stat_statements. Dediyim kimi, bu bir moduldur. Onu istifadə etmək üçün onun kitabxanasını konfiqurasiyaya yükləməlisiniz, PostgreSQL-i yenidən başladın, modulu quraşdırın (bir komanda ilə) və sonra yeni görünüşümüz olacaq.

Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;

Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;

Oradan nə götürə bilərik? Sadə şeylərdən danışsaq, sorğunun orta icra müddətini götürə bilərik. Zaman artır, bu o deməkdir ki, PostgreSQL yavaş cavab verir və nəsə etmək lazımdır.

Paylaşılan buferlərdə məlumatları dəyişən verilənlər bazasında ən aktiv yazı əməliyyatlarını görə bilərik. Orada məlumatları kimin yenilədiyi və ya sildiyinə baxın.

Və biz bu sorğular üçün müxtəlif statistikalara baxa bilərik.

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

Biz pg_stat_statements hesabatlar yaratmaq üçün istifadə olunur. Statistikanı gündə bir dəfə sıfırlayırıq. Gəlin toplayaq. Növbəti dəfə statistik məlumatları sıfırlamadan əvvəl biz hesabat hazırlayırıq. Budur hesabata keçid. Baxa bilərsiniz.

Biz nə edirik? Bütün sorğular üçün ümumi statistikanı hesablayırıq. Sonra hər bir sorğu üçün onun bu ümumi statistikaya fərdi töhfəsini hesablayırıq.

Və biz nə görə bilərik? Müəyyən bir növün bütün sorğularının ümumi icra müddətini bütün digər sorğuların fonunda görə bilərik. Ümumi şəkil ilə əlaqədar olaraq CPU və I/O istifadəsinə baxa bilərik. Və artıq bu sorğuları optimallaşdırmaq üçün. Biz bu hesabata əsaslanaraq ən yaxşı sorğuları hazırlayırıq və artıq nəyi optimallaşdırmaq barədə düşünmək üçün qida alırıq.

Bizim pərdə arxasında nə var? Hələ vaxt məhdud olduğu üçün nəzərə almadığım bir neçə təqdimat var.

Yoxdur pgstattuple həm də standart töhfələr paketindən əlavə moduldur. Qiymətləndirməyə imkan verir bloat masalar, sözdə. masanın parçalanması. Və parçalanma böyükdürsə, onu çıxarmaq, müxtəlif vasitələrdən istifadə etmək lazımdır. Və funksiya pgstattuple uzun müddət işləyir. Və daha çox masa, daha uzun işləyəcək.

Növbəti töhfədir pg_buffercache. Bu, paylaşılan buferləri yoxlamağa imkan verir: bufer səhifələrindən nə qədər intensiv və hansı cədvəllər üçün istifadə olunur. Və bu, sadəcə paylaşılan buferlərə baxmağa və orada baş verənləri qiymətləndirməyə imkan verir.

Növbəti moduldur pgfincore. Sistem çağırışı vasitəsilə aşağı səviyyəli masa əməliyyatlarını yerinə yetirməyə imkan verir mincore(), yəni cədvəli paylaşılan buferlərə yükləməyə və ya onu boşaltmağa imkan verir. Və digər şeylərlə yanaşı, əməliyyat sisteminin səhifə keşini, yəni cədvəlin səhifə önbelleğinde, paylaşılan buferlərdə nə qədər yer tutduğunu yoxlamağa imkan verir və sadəcə olaraq masanın yükünü qiymətləndirməyə imkan verir.

Növbəti moduldur pg_stat_kcache. O, həmçinin sistem çağırışından istifadə edir getrusage(). Və onu sorğu yerinə yetirilməzdən əvvəl və sonra icra edir. Əldə edilən statistikada bu, sorğumuzun diskin giriş/çıxışına, yəni fayl sistemi ilə əməliyyatlara nə qədər xərcləndiyini təxmin etməyə və prosessorun istifadəsinə baxmağa imkan verir. Bununla belə, modul gəncdir (khe-khe) və onun işləməsi üçün əvvəllər qeyd etdiyim PostgreSQL 9.4 və pg_stat_statements tələb olunur.

Statistikanı istifadə etmək bacarığı faydalıdır. Üçüncü tərəf proqram təminatına ehtiyacınız yoxdur. Baxa, görə, nəsə edə, icra edə bilərsən.
Statistikanı istifadə etmək asandır, sadə SQL-dir. Sorğu topladınız, tərtib etdiniz, göndərdiniz, baxdınız.
Statistika suallara cavab verməyə kömək edir. Suallarınız varsa, statistikaya müraciət edirsiniz - baxın, nəticə çıxarın, nəticələri təhlil edin.
Və təcrübə. Çoxlu sorğular, çoxlu məlumatlar. Siz həmişə bəzi mövcud sorğuları optimallaşdıra bilərsiniz. Sorğunun orijinaldan daha uyğun olan öz versiyasını hazırlayıb istifadə edə bilərsiniz.