Yeni veritabanı yöneticileri için "veritabanı performansı" kavramını anlamak, uygulamadan daha zor gelebilir. Çünkü performans sorunları ile ilgili çalışırken birçok karmaşık değişken ile karşılaşılması kaçınılmazdır. Belkide veritabanı yöneticisinin duymak istemediği veya duyduğunda korkuya ve endişeye kapıldığı an, "veritabanında sunucusunda bir yavaşlama var" cümlesini duyduğu andır. Çünkü bu duruma neden olan problem, birçok sebep veya birçok olasılıktan biri olacaktır.

 

Bu yazımda PostgreSQL veritabanı sunucusu üzerinde kullanılan ve performansı izlemeyi sağlayan, PostgreSQL'e özel birkaç veritabanı komutu hakkında bilgi vermeye çalışacağım.

Genelde performans problemlerinin çoğu kötü yazılmış sorgulardan oluşmaktadır. Bu gibi durumlarda, kötü yazılmış sorgu kodunu bulmada veritabanı programcısına yardım görevi, veritabanı yöneticisine düşmektedir.

Sql cümleciklerini yazıp, enter tuşuna bastıktan sonra, veritabanı sunucusu üzerinde ne gibi işlemler yapıldığını pek bilmeyiz. Ama performans artırımı gibi bir konuda yoğunlaşmışsak bunları bilmek zorundayız. Yazılan sql cümleciğini oluşturan bileşenlerin her birinin ne kadar zaman gerektirdiğini öğrenmeliyiz ki sorunları tespit edebilelim.

"Query explain plan" sorguların yolunu kendi bileşenleri ile göstererek, her bileşenin tahmini tamamlanma süresini gösteren en iyi sorgu analiz aracıdır. Veritabanı programcısı, query plan sonucunda gelen bileşenleri analiz ederek gecikmeye sebep olan bileşeni tespit edebilir, çıkan planın analizi sonucu sql cümleciği üzerinde bazı düzenlemeler yapılarak performans artırılabilir.

 

"EXPLAIN sql" komutu, veritabanın verileri çekerken sorguyu nasıl değerlendirdiğinin röntgenini çekmemizi sağlar. "EXPLAIN sql" komutu SELECT ile başlayan sql cümleciğinin önünde kullanıldığında, veritabanının bu sorgu için tahmini istatistiklerini verecektir.

Örnek:
EXPLAIN SELECT *

                  FROM tb_musteri

 

QUERY PLAN
Seq Scan on tb_musteri (cost=100000000.00..100225153.16 rows=2027727 width=563)

EXPLAIN komutunun çıktısı, 3 adet istatistik verisini gösterir.
• SQL komutunun sonuç döndürmesi için gerekli olan tahmini maliyet.
• Sonuç kümesinin barındıracağı tahmini satır sayısı.
• Sonuç kümesinin barındırdığı kayıtların içinde ki bir satırda bulunabilecek tahmini en fazla karakter sayısı.

 

Tahmini maliyetler iki tanedir. Birincisi, sonuç kümesinin ilk kaydının tahmini ne kadar birim maliyet ile döneceğini, ikincisi ise tahmini sürede veritabanının tüm sonuç kümesini ne kadar birim maliyet ile döndüreceğini göstermektedir. Maliyet olarak ifade edilen parametreler milisaniye gibi gerçek bir zaman dilimini ifade etmezler. İşlemci zamanı veya veritabanı yönetim sisteminin kendi içerisinde belirlediği tahmini iş yükü maliyet bilgileridir.

Tahmini sürelerin yanı sıra, sorgunun alacağı gerçek süreyi görmek için "EXPLAIN" den sonra "ANALYZE" parametresi kullanılmalıdır.

Örnek:
EXPLAIN ANALYZ SELECT *

                                  FROM tb_musteri

Seq Scan on tb_musteri (cost=100000000.00..100225805.04 rows=2034188 width=563) (actual time=0.016..1777.472 rows=2034367 loops=1)
Total runtime: 2847.701 ms

"actual time" bize yukarıda ki sorgunun PostgreSQL tarafından ne kadar sürede işleneceğini göstermektedir. Yine de, actual time ile gösterilen süre, sorgunun aldığı gerçek süre değildir. Sorgunun alacağı net süre çıktının ikinci satırında yer alan "Total runtime" ifadesi ile gösterilmesine rağmen, “explanin analyze” sorgu sürelerini vermesi için çalıştırılmıştır. Ancak output olarak sonuçların ekrana bastırılmamış olması da dikkate alınmalıdır.

Özetle bu veriler kesin olarak gerçek sorgu zamanlarını vermemekle beraber, bir sorgunun diğer sorgulara göre veya bir kaç parçadan oluşan sql sorgusunun hangi bölümünün ne kadar süre alacağını kıyaslamak için kullanılabilir.

Örnek:
EXPLAIN ANALYZE SELECT  *

                                     FROM tb_musteri

                             ORDER BY ana_adi

 

Sort (cost=100885914.48..100890999.95 rows=2034188 width=563)
Sort Key: ana_adi
Seq Scan on tb_musteri (cost=100000000.00..100225805.04 rows=2034188 width=563)
Total runtime: 64294.170 ms

ORDER BY şartı ile veritabanına, 2 aşamada cevap dönme zorunluluğu getirilmektedir. Yukarıda bulunan örnek sorgu, aşağıdan yukarı doğru analiz edilmelidir. Veritabanı ilk olarak son parçayı işlemiş ve daha sonra birinci parçayı işlemiştir. Sorgunun zaman alan kısmı, tablo üzerinde kayıtları tarayan parça değil, sırlamanın yapıldığı parçadır.

100225805.04 ile 100890999.95 veritabanı maliyetini karşılaştırdığımızda sıralama işleminin daha fazla maliyetli olduğunu görebiliriz. İşte yukarıda da bahsettiğimiz ve bu örnekte de görüldüğü gibi maliyet değerleri farklı bileşenlerin maliyetlerini karşılaştırmada yardımcı olmaktadırlar. Gerçek zaman birimi ifadeleri değildirler.

Örnek:
EXPLAIN ANALYZE SELECT *

                                    FROM tb_musteri

                            ORDER BY id

 

Index Scan using tb_musteriler_pkey on tb_musteri (cost=0.00..378772.93 rows=2035185 width=562) (actual time=0.069..4644.785 rows=2035775 loops=1)
Total runtime: 6152.725 ms

Sorgu planında da görüldüğü gibi index li bir kolon kullanıldığında performans farkı ortaya çıkmaktadır. İndex i olmayan bir kolon ile sıralama işlemi yapıldığında 64294.170 milisaniye, index i olan bir kolona göre sıralama işlemi yapıldığında ise 6152.725 milisaniye sürmektedir.

Örnek:
ANALYZE tb_musteri

ANALYZE komutunun tek başına kullanılmasıyla EXPLAIN komutu ile kullanılması farklıdır. ANALYZE komutu, tek başına kullanıldığında tüm veritabanı nesnelerini gözden geçirerek, istatistik bilgilerini günceller. Bu komutu tablo ismi ile sadece tablo sahibi kullanabilir. Tablo ismi ile kullanıldığında da, ismi verilen tablo ile ilgili tüm sorgu planlarını reset lenir.

 

Örnek:
ANALYZE VERBOSE tb_musteri

 

INFO: analyzing "ktv.tb_musteri"
INFO: "tb_musteri": scanned 60000 of 63070 pages, containing 1938427 live rows and 2499 dead rows; 60000 rows in sample, 2037610 estimated total rows
Query returned successfully with no result in 11985 ms.

Yukarıdaki output ta olduğu gibi VERBOSE parametresi, tablo hakkında bazı bilgileri almak için kullanılmaktadır. 1938427 kayıt, DELETE veya UPDATE işlemine uğramamış, ancak 2499 kayıt, DELETE veya UPDATE işlemlerinden birine uğramıştır. Bu durumda VACUUM yapılarak veri saklama alanımızda kullanılamayan 2499 kaydın kapladığı alan tekrar kullanılabilir hale getirilebilir.

Eğer üzerinde çok fazla delete veya update yapılan bir veritabanınız varsa, düzenli olarak tabloların durumlarını ANALYZE ile takip etmek ve ardından gerekli ise VACUUM yapmak faydalı olacaktır.

 İletişim : Bu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır