Felsefi giriş
Bildiğiniz gibi sorunları çözmenin yalnızca iki yöntemi vardır:
- Analiz yöntemi veya çıkarım yöntemi veya genelden özele.
- Sentez yöntemi veya indüksiyon yöntemi veya özelden genele.
“Veritabanı performansını iyileştirme” sorununu çözmek için şöyle görünebilir.
analizi — sorunu ayrı parçalara ayırıyoruz ve bunları çözerek veritabanının bir bütün olarak performansını artırmaya çalışıyoruz.
Pratikte analiz şuna benzer:
- Bir sorun oluştuğunda (performans olayı)
- Veritabanının durumu hakkında istatistiksel bilgi toplama
- Darboğazları arıyorum
- Darboğazlardan kaynaklanan sorunları çözüyoruz
Veritabanı darboğazları — altyapı (CPU, Bellek, Diskler, Ağ, İşletim Sistemi), ayarlar (postgresql.conf), sorgular:
Altyapı: Bir mühendisin etkilenme ve değişme olasılığı neredeyse sıfırdır.
Veritabanı Ayarları: Değişiklik olasılıkları önceki duruma göre biraz daha fazladır, ancak kural olarak, özellikle bulutlarda bunlar hala oldukça zordur.
istekler veritabanına: sadece manevra alanı.
sentez — Sonuç olarak veritabanı performansının artacağını umarak tek tek parçaların performansını iyileştiririz.
Lirik giriş veya tüm bunların neden gerekli olduğu
Veritabanı performansı izlenmiyorsa performans olaylarını çözme süreci nedir:
Müşteri - “Bizde her şey kötü, çok uzun sürüyor, bizim için iyi bir şeyler yapın”
Mühendis - “bu ne kadar kötü?”
Müşteri – “şimdi de böyle (bir saat önce, dün, en son öyleydi), yavaş yavaş”
Mühendis - “ne zaman iyiydi?”
Müşteri – “Bir hafta (iki hafta) önce fena değildi. "(O şanslı)
Müşteri - “Ne zaman iyi olduğunu hatırlamıyorum ama şimdi kötü” (Normal cevap)
Sonuç klasik bir resimdir:
Kim suçlanacak ve ne yapmalı?
Sorunun ilk kısmı yanıtlanması en kolay olanıdır; suçlu her zaman DBA mühendisidir.
İkinci bölümün yanıtlanması da çok zor değil; bir veritabanı performans izleme sistemi uygulamanız gerekiyor.
İlk soru ortaya çıkıyor - ne izlenecek?
Yol 1. HER ŞEYİ izleyeceğiz
CPU yükü, disk okuma/yazma işlemlerinin sayısı, ayrılan belleğin boyutu ve az ya da çok çalışan herhangi bir izleme sisteminin sağlayabileceği başka bir megaton farklı sayaç.
Sonuç, bir dizi grafik, özet tablo ve sürekli e-posta bildirimleri ve bir grup aynı bildirimi çözmekle %100 meşgul mühendis, ancak kural olarak standart ifadeyle - "Geçici sorun. Herhangi bir eyleme gerek yok." Ancak herkes meşgul ve her zaman müşteriye gösterecek bir şey vardır; iş tüm hızıyla devam ediyor.
2. Yol: Yalnızca ihtiyaç duyulanı izleyin, ihtiyaç duyulmayan şeyin izlenmesine gerek yoktur
Biraz farklı olarak yalnızca varlıkları ve olayları izleyebilirsiniz:
- Hangi DBA Mühendisi Etkileyebilir?
- Bir olay meydana geldiğinde veya bir varlık değiştiğinde bir eylem algoritması vardır.
Bu varsayıma dayanarak ve hatırlayarak "Felsefi giriş"düzenli tekrarlardan kaçınmak için"Lirik giriş veya tüm bunların neden gerekli olduğu"Optimizasyon ve analiz için bireysel sorguların performansının izlenmesi tavsiye edilebilir, bu da sonuçta tüm veritabanının performansının artmasına yol açacaktır.
Ancak genel veritabanı performansını etkileyen ağır bir sorguyu iyileştirmek için önce onu bulmalısınız.
Dolayısıyla birbiriyle ilişkili iki soru ortaya çıkıyor:
- hangi isteğin zor olduğu kabul edilir
- zor sorgular nasıl aranır?
Açıkçası, ağır bir sorgu, sonucu elde etmek için çok sayıda işletim sistemi kaynağı kullanan bir sorgudur.
İkinci soruya geçelim: Ağır sorgular nasıl aranır ve izlenir?
PostgreSQL'in sorgu izleme yetenekleri nelerdir?
Oracle ile karşılaştırıldığında çok az olasılık var ama yine de bir şeyler yapılabilir.
PG_STAT_STATEMENTS
PostgreSQL'de yoğun sorguları aramak ve izlemek için standart pg_stat_statements uzantısı tasarlanmıştır.
Uzantıyı yükledikten sonra, hedef veritabanında izleme amacıyla kullanılması gereken aynı isimli bir görünüm belirir.
Bir izleme sistemi oluşturmak için pg_stat_statements sütunlarını hedefleyin:
- sorgu kimliği Operatörün ayrıştırma ağacından hesaplanan dahili karma kod
- maksimum_zaman Bir ekstrede harcanan maksimum süre (milisaniye cinsinden)
Bu iki sütundaki istatistikleri toplayıp kullanarak bir izleme sistemi oluşturabilirsiniz.
PostgreSQL performansını izlemek için pg_stat_statements nasıl kullanılır?
Sorgu performansını izlemek için şunu kullanın:
Hedef veritabanı tarafında - pg_stat_statements görünümü
Yandan sunucu ve veritabanlarının izlenmesi - bir dizi bash betiği ve hizmet tablosu.
Aşama 1 - istatistiksel verilerin toplanması
Cron izleme ana bilgisayarında, pg_stat_statements görünümünün içeriğini hedef veritabanından izleme veritabanındaki pg_stat_history tablosuna kopyalayan bir komut dosyası düzenli olarak başlatılır.
Bu, performans raporları oluşturmak ve ölçümleri yapılandırmak için kullanılabilecek bireysel sorgu yürütmelerinin geçmişini oluşturur.
2. Aşama - performans ölçümlerini ayarlama
Toplanan verilere dayanarak, yürütülmesi istemci (uygulama) için en kritik/önemli olan sorguları seçiyoruz. Müşteri ile anlaşarak performans metriklerinin değerlerini queryid ve max_time alanlarını kullanarak belirliyoruz.
Sonuç - performans izlemenin başlangıcı
- İzleme komut dosyası çalıştırıldığında, metriğin max_time değerini hedef veritabanındaki pg_stat_statements görünümündeki değerle karşılaştırarak yapılandırılmış performans ölçümlerini kontrol eder.
- Hedef veritabanındaki değer metrik değeri aşarsa uyarı oluşturulur (bilet sisteminde bir olay)
Ek seçenek 1
Sorgu planı geçmişi
Performans olaylarını daha sonra çözmeye yardımcı olmak için sorgu yürütme planlarını değiştirme geçmişine sahip olmak iyi bir fikirdir.
Log_query servis tablosu geçmişi saklamak için kullanılır. Tablo, yüklenen PostgreSQL günlük dosyası analiz edilirken doldurulur. Günlük dosyası, pg_stat_statements görünümünün aksine, normalleştirilmiş metni değil, yürütme parametrelerinin değerlerini içeren tam metni içerdiğinden, yalnızca isteklerin zamanını ve süresini değil, aynı zamanda yürütme planlarını mevcut durumda depolamak da mümkündür. zaman.
Ek seçenek 2
Sürekli performans iyileştirme süreci
Genel olarak bireysel sorguların izlenmesi, veritabanının performansının bir bütün olarak sürekli olarak iyileştirilmesi sorununu çözmeyi amaçlamaz, çünkü yalnızca bireysel sorgulara ilişkin performans sorunlarını izler ve çözer. Ancak yöntemi genişletebilir ve tüm veritabanları için izleme sorgularını yapılandırabilirsiniz.
Bunu yapmak için ek performans ölçümleri girmeniz gerekir:
- Son günlerde
- Temel dönem için
Komut dosyası, hedef veritabanındaki pg_stat_statements görünümünden sorguları seçer ve max_time değerini, ilk durumda son günler için veya ikinci durumda seçilen zaman dilimi (temel çizgi) için ortalama max_time değeriyle karşılaştırır.
Böylece herhangi bir talebin performansının düşmesi durumunda, raporların manuel analizine gerek kalmadan otomatik olarak uyarı oluşturulacak.
Sentezin bununla ne alakası var?
Açıklanan yaklaşımda, sentez yönteminin önerdiği gibi, sistemin tek tek parçalarını iyileştirerek sistemi bir bütün olarak iyileştiriyoruz.
- Bir veritabanı tarafından yürütülen sorgu – özet
- Değiştirilmiş istek - antitez
- Sistemin durumunu değiştirme - sentez
Sistem Geliştirme
- pg_stat_activity sistem görünümü için geçmiş eklenerek toplanan istatistiklerin uzantıları
- Sorgulara katılan ayrı ayrı tabloların istatistikleri için geçmiş ekleyerek toplanan istatistikleri genişletme
- AWS bulut izleme sistemiyle entegrasyon
- Ama yine de bir şeyler bulabilirsin...
Kaynak: habr.com
