Fəlsəfi giriş
Bildiyiniz kimi, problemlərin həlli üçün yalnız iki üsul var:
- Təhlil üsulu və ya çıxma üsulu və ya ümumidən xüsusiyə.
- Sintez üsulu və ya induksiya üsulu və ya xüsusidən ümumiyə.
“Verilənlər bazası performansını yaxşılaşdırmaq” problemini həll etmək üçün bu belə görünə bilər.
Təhlil — biz problemi ayrı-ayrı hissələrə təhlil edirik və onları həll etməklə bütövlükdə verilənlər bazasının işini yaxşılaşdırmağa çalışırıq.
Təcrübədə analiz belə görünür:
- Problem yaranır (performans hadisəsi)
- Verilənlər bazasının vəziyyəti haqqında statistik məlumatların toplanması
- Darboğazları axtarır
- Problemləri darboğazlardan həll edirik
Verilənlər bazası darboğazları — infrastruktur (CPU, Yaddaş, Disklər, Şəbəkə, ƏS), parametrlər (postgresql.conf), sorğular:
İnfrastruktur: Mühəndis üçün təsir və dəyişiklik imkanları demək olar ki, sıfırdır.
Verilənlər Bazasının Parametrləri: dəyişikliklər üçün imkanlar əvvəlki vəziyyətdən bir qədər böyükdür, lakin bir qayda olaraq, xüsusilə buludlarda hələ də olduqca çətindir.
İstək verilənlər bazasına: manevr üçün yeganə yer.
Sintez — biz fərdi hissələrin performansını yaxşılaşdırırıq, nəticədə verilənlər bazası performansının yaxşılaşacağını gözləyirik.
Lirik giriş və ya bütün bunlar niyə lazımdır
Verilənlər bazası performansına nəzarət edilmirsə, performans insidentlərinin həlli prosesi nədir:
Müştəri - "bizdə hər şey pisdir, çox uzun çəkir, bizim üçün yaxşı bir şey et"
Mühəndis - "bu nə qədər pisdir?"
Müştəri – “indi belədir (bir saat əvvəl, dünən, sonuncu dəfə idi), yavaş-yavaş”
Mühəndis - "nə vaxt yaxşı idi?"
Müştəri – “bir həftə (iki həftə) əvvəl pis deyildi. "(xoşbəxtlikdir)
Müştəri - "Nə vaxt yaxşı olduğunu xatırlamıram, amma indi pisdir" (Adi cavab)
Nəticə klassik bir şəkildir:
Kim günahlandırmalı və nə etməli?
Sualın birinci hissəsi cavab vermək üçün ən asandır - DBA mühəndisi həmişə günahkardır.
İkinci hissəyə də cavab vermək çox çətin deyil - verilənlər bazası performansının monitorinqi sistemini tətbiq etməlisiniz.
İlk sual yaranır - nə izləmək lazımdır?
Yol 1. HƏR ŞEYƏ nəzarət edəcəyik
CPU yükü, disk oxuma/yazma əməliyyatlarının sayı, ayrılmış yaddaşın ölçüsü və hər hansı bir az və ya çox işləyən monitorinq sisteminin təmin edə biləcəyi başqa meqaton müxtəlif sayğaclar.
Nəticə bir dəstə qrafik, xülasə cədvəli və davamlı e-poçt bildirişləri və eyni biletləri həll edən 100% məşğul mühəndisdir, lakin bir qayda olaraq, standart ifadə ilə - “Müvəqqəti məsələ. Heç bir tədbirə ehtiyac yoxdur”. Ancaq hər kəs məşğuldur və müştəriyə hər zaman göstərmək üçün bir şey var - iş tam sürətlə gedir.
Yol 2. Yalnız lazım olanı izləyin, lazım olmayanı isə izləmək lazım deyil
Siz bir az fərqli şəkildə yalnız obyektləri və hadisələri izləyə bilərsiniz:
- Hansı DBA mühəndisi təsir edə bilər
- Bunun üçün hadisə baş verəndə və ya obyekt dəyişdikdə hərəkətlərin alqoritmi mövcuddur.
Bu fərziyyəyə və xatırlamağa əsaslanaraq "Fəlsəfi giriş"müntəzəm təkrarlanmamaq üçün"Lirik giriş və ya bütün bunlar niyə lazımdır“Optimallaşdırma və təhlil üçün fərdi sorğuların icrasına nəzarət etmək məqsədəuyğun olardı ki, bu da son nəticədə bütün verilənlər bazasının təkmilləşdirilmiş performansına gətirib çıxarmalıdır.
Lakin ümumi verilənlər bazası performansına təsir edən ağır sorğunu təkmilləşdirmək üçün əvvəlcə onu tapmalısınız.
Beləliklə, bir-biri ilə əlaqəli iki sual ortaya çıxır:
- hansı tələb çətin hesab olunur
- çətin sorğuları necə axtarmaq olar.
Aydındır ki, ağır sorğu nəticə əldə etmək üçün çoxlu OS resurslarından istifadə edən sorğudur.
İkinci suala keçək - ağır sorğuları necə axtarmaq və sonra nəzarət etmək olar?
PostgreSQL hansı sorğuların monitorinqi imkanlarına malikdir?
Oracle ilə müqayisədə imkanlar azdır, amma yenə də nəsə etmək olar.
PG_STAT_STATEMENTS
PostgreSQL-də ağır sorğuları axtarmaq və izləmək üçün standart pg_stat_statements genişləndirilməsi nəzərdə tutulub.
Genişlənməni quraşdırdıqdan sonra, monitorinq məqsədləri üçün istifadə edilməli olan hədəf verilənlər bazasında eyni adlı bir görünüş görünür.
Monitorinq sisteminin qurulması üçün hədəf pg_stat_statements sütunları:
- sorğuid Operatorun təhlil ağacından hesablanmış daxili hash kodu
- maksimum_zaman Bəyanata sərf olunan maksimum vaxt, millisaniyələrlə
Bu iki sütun üzrə statistik məlumatları toplayıb istifadə etməklə siz monitorinq sistemi qura bilərsiniz.
PostgreSQL performansını izləmək üçün pg_stat_statements necə istifadə olunur
Sorğu performansının istifadəsinə nəzarət etmək üçün:
Hədəf verilənlər bazası tərəfində - pg_stat_statements görünüşü
Yan tərəfdən server və monitorinq verilənlər bazaları - bir sıra bash skriptləri və xidmət cədvəlləri.
Mərhələ 1 - statistik məlumatların toplanması
Cron monitorinq hostunda pg_stat_statements görünüşünün məzmununu hədəf verilənlər bazasından monitorinq verilənlər bazasındakı pg_stat_history cədvəlinə köçürən skript müntəzəm olaraq işə salınır.
Bu, performans hesabatlarını yaratmaq və ölçüləri konfiqurasiya etmək üçün istifadə edilə bilən fərdi sorğu icrası tarixçəsini yaradır.
Mərhələ 2 - performans göstəricilərinin qurulması
Toplanmış məlumatlara əsasən, icrası müştəri (tətbiq) üçün ən kritik/vacib olan sorğuları seçirik. Müştəri ilə razılaşaraq, biz queryid və max_time sahələrindən istifadə edərək performans göstəricilərinin dəyərlərini təyin edirik.
Nəticə - performans monitorinqinin başlaması
- Monitorinq skripti işə salındıqda, metrikanın max_time dəyərini hədəf verilənlər bazasında pg_stat_statements görünüşündəki dəyərlə müqayisə edərək konfiqurasiya edilmiş performans göstəricilərini yoxlayır.
- Hədəf verilənlər bazasındakı dəyər metrik dəyəri keçərsə, xəbərdarlıq yaradılır (bilet sistemində insident)
Əlavə seçim 1
Sorğu planı tarixçəsi
Performans insidentlərini sonradan həll etmək üçün sorğunun icra planlarının dəyişdirilməsi tarixçəsinə sahib olmaq yaxşı fikirdir.
log_query xidmət cədvəli tarixçəni saxlamaq üçün istifadə olunur. Cədvəl yüklənmiş PostgreSQL log faylını təhlil edərkən doldurulur. Günlük faylı, pg_stat_statements görünüşündən fərqli olaraq, normallaşdırılmamış mətni deyil, icra parametrlərinin dəyərləri ilə tam mətni ehtiva etdiyi üçün, yalnız sorğuların vaxtını və müddətini deyil, həm də icra planlarını cari rejimdə saxlamaq mümkündür. vaxt.
Əlavə seçim 2
Davamlı performans təkmilləşdirmə prosesi
Ümumilikdə fərdi sorğuların monitorinqi bütövlükdə verilənlər bazasının fəaliyyətinin davamlı olaraq təkmilləşdirilməsi problemini həll etmək üçün nəzərdə tutulmur, çünki o, yalnız fərdi sorğular üçün performans problemlərini izləyir və həll edir. Bununla belə, siz metodu genişləndirə və bütün verilənlər bazaları üçün monitorinq sorğularını konfiqurasiya edə bilərsiniz.
Bunu etmək üçün əlavə performans göstəricilərini daxil etməlisiniz:
- Son günlər üçün
- Baza dövrü üçün
Skript hədəf verilənlər bazasındakı pg_stat_statements görünüşündən sorğuları seçir və birinci halda son günlər üçün və ya seçilmiş müddət (əsas), ikinci halda max_time dəyərini orta max_time dəyəri ilə müqayisə edir.
Beləliklə, hər hansı sorğu üçün performansın aşağı düşməsi halında, hesabatların əl ilə təhlili aparılmadan avtomatik olaraq xəbərdarlıq yaradılacaq.
Sintezin bununla nə əlaqəsi var?
Təsvir edilən yanaşmada, sintez metodunun təklif etdiyi kimi, sistemin ayrı-ayrı hissələrini təkmilləşdirməklə biz bütövlükdə sistemi təkmilləşdiririk.
- Verilənlər bazası tərəfindən yerinə yetirilən sorğu - mücərrəd
- Dəyişdirilmiş sorğu - antiteza
- Sistemin vəziyyətinin dəyişdirilməsi - sintez
Sistem inkişafı
- pg_stat_activity sistem görünüşü üçün tarix əlavə etməklə toplanmış statistikanın genişləndirilməsi
- Sorğularda iştirak edən fərdi cədvəllərin statistikası üçün tarixçə əlavə etməklə toplanmış statistikanın genişləndirilməsi
- AWS bulud monitorinq sistemi ilə inteqrasiya
- Və yenə də bir şey tapa bilərsiniz ...
Mənbə: www.habr.com
