Gəlin real bir hekayə ilə başlayaq. Təsəvvür elə ki, böyük bir onlayn mağaza platformasında developer kimi işləyirsən. Hər şey super işləyir, bir detal istisna olmaqla: aylıq satışlar hesabatı o qədər yavaş yüklənir ki, istifadəçilər hesabat bitənə qədər bir sifariş də verə bilirlər. Sən əsəbisən, menecerin əsəbidir, PostgreSQL serveri çaydan kimi qaynayır və hər şey bir az apokalipsisə bənzəyir. İndi təsəvvür elə ki, bir hərəkətlə səbəbi tapıb düzəldə bilərdin.
Sorğuların performans analizini PostgreSQL-in sağlamlıq yoxlanışı kimi düşün. Bu, “dar boğazları” (ağrılı nöqtələri) tapmağa və onları düzəltməyə kömək edir ki, istifadəçi təcrübəsi yaxşılaşsın və sistem resurslarına qənaət olunsun.
Sorğular PostgreSQL-də necə işləyir?
Sən belə sadə bir sorğu yazanda:
SELECT * FROM products WHERE price > 100;
PostgreSQL dərhal məlumatları çıxarmağa başlamır. Əvvəlcə sorğunu analiz edir, onu necə daha yaxşı icra edəcəyini düşünür və yalnız sonra işə başlayır.
Sorğuların icra mərhələləri:
- Parsing. PostgreSQL sorğunu sintaksis səhvlərinə yoxlayır və onu aralıq təqdimata çevirir.
- Optimization. Sorğu optimizatoru bir neçə icra variantını qiymətləndirir və ən “ucuzunu” (vaxt və resurs baxımından) seçir.
- Execution. Server seçilmiş plana uyğun hərəkət edir və məlumatları çıxarır.
“Dar boğaz” nədir?
“Dar boğaz” – sorğunun hər şeyi ləngidən hissəsidir. Bu, gözlənilmədən ən çox vaxt və ya resurs yeyən əməliyyat ola bilər. Məsələn, PostgreSQL sürətli index lookup əvəzinə tam cədvəl scanı (Seq Scan) edirsə, sorğu yavaşlayır. Və ya məlumatlar gözləniləndən çoxdursa, server sort, join, filter üçün çox vaxt sərf edir.
Belə məqamlar dar boğaz adlanır – məhz onları tapıb optimallaşdırmaq lazımdır.
Sorğu performansını analiz etmək üçün alətlər
PostgreSQL-də sorğulardakı problemləri tapmağa kömək edən bir neçə güclü alət var:
- EXPLAIN və EXPLAIN ANALYZE. Bu komandalar PostgreSQL-in sorğunu necə icra edəcəyini göstərir və ya hətta onu icra edib real performans ölçülərini verir.
EXPLAIN: sorğunun icra planını göstərir, amma real icra etmir.EXPLAIN ANALYZE: sorğunu icra edir və real icra planını faktiki vaxt metrikləri ilə göstərir.
EXPLAIN istifadəsinə nümunə:
EXPLAIN SELECT * FROM products WHERE price > 100;
Nəticə:
Seq Scan on products (cost=0.00..35.50 rows=5 width=72)
Filter: (price > 100)
Burada göstərilir ki, sorğu “Seq Scan” – tam cədvəl scanı edir, bu da böyük cədvəllər üçün effektiv deyil.
- pg_stat_statements. Bu əlavə extension-dur, icra olunan sorğuları izləyir. O göstərir:
- Serverdə hansı sorğular icra olunur.
- Hər sorğuya nə qədər vaxt sərf olunur.
- Sorğu neçə sətri qaytarır və nə qədər resurs istifadə edir.
pg_stat_statements aktivləşdirmək üçün:
- Extension-u aktivləşdir:
CREATE EXTENSION pg_stat_statements;
- PostgreSQL konfiqurasiyasını qur:
postgresql.conffaylında əlavə et:
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = all
- PostgreSQL-i restart et.
İndi sorğuları analiz edə bilərsən:
SELECT * FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;
Bu, ən “ağır” 5 sorğunu ümumi icra vaxtına görə azalan sırada göstərəcək.
- Yavaş sorğuların loglaşdırılması. PostgreSQL-i elə qura bilərsən ki, çox uzun çəkən sorğuları (məsələn, 1 saniyədən çox) log-fayla yazsın.
Bunun üçün postgresql.conf-da belə yaz:
log_min_duration_statement = 1000 # Vaxt millisekundla (1 saniyə)
İndi yavaş sorğular PostgreSQL loglarına yazılacaq.
Performans analizində əsas metriklər
Sorğuların performansını analiz edəndə bu əsas metriklərə fikir ver:
- İcra vaxtı. Sorğunun icrasına sərf olunan əsas vaxt göstəricisi. Nə qədər tez, o qədər yaxşı.
- Sətir sayı. Sorğun gözlədiyindən çox sətir qaytarırsa və ya scan edirsə, bu problem ola bilər.
- İndekslərdən istifadə. Sorğu index istifadə etməlidir, amma əvəzinə ardıcıl scan (
Seq Scan) edirsə, bu optimizasiya siqnalıdır. - Buffer və disk əməliyyatları. Disklə aktiv işləyən sorğular, yaddaşdan istifadə edənlərə nisbətən daha yavaşdır.
Bu biliklər praktikada necə tətbiq olunur?
Nümunə 1: Yavaş sorğu
100-dən baha olan bütün məhsulları seçmək üçün sorğu yazırsan:
SELECT * FROM products WHERE price > 100;
Görürsən ki, sorğu çox yavaş işləyir.
EXPLAIN istifadə edirsən və görürsən:
Seq Scan on products (cost=0.00..35.50 rows=5 width=72)
Filter: (price > 100)
Problem: sorğu tam cədvəl scanı edir, çünki price sütunu üçün index yoxdur.
Həll:
Index yarat:
CREATE INDEX idx_price ON products(price);
İndi sorğu Index Scan istifadə edir:
Index Scan using idx_price on products (cost=0.15..8.25 rows=5 width=72)
Index Cond: (price > 100)
Nümunə 2: pg_stat_statements ilə yavaş sorğuları tapmaq
Bu komanda ilə:
SELECT query, total_time, calls
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 1;
Çox vaxt aparan bir sorğunu tapırsan. EXPLAIN ANALYZE ilə açırsan, düzəldirsən və o, daha sürətli olur.
EXPLAIN, pg_stat_statements və digər alətləri istifadə etməyə başlayanda sorğuların daha sürətli işləyəcək, PostgreSQL serverin isə saat kimi işləyəcək. Növbəti leksiyada EXPLAIN parametrlərinin – cost, rows və width – detallarına baxacağıq və sorğu icra planlarını açıq kitab kimi oxumağa başlayacağıq.
GO TO FULL VERSION