Başlamadan önce aşağıdaki yazıya bir göz atmakta fayda olabilir. Burada bakacağımız mimari performans açısında olacaktır.
Postgresql Client Server mimarisinde çalışmaktadır.
Server Prosesler;
- Process Manager
- Query Processor
- Utilities
- Storage Manager
Process Manager
Daemon Process
PostgreSQL başlatıldığında ilk açılan proses /usr/local/pgsql/bin/postgres dir. Bu prosess açılışta kurtarılması greken herhangi bir işlem olup olmadığına bakar, shared memory alanını düzenler. Ve aşağıdaki prosesleri içerir
- bgwritter,
- checkpointer,
- autovacum
- launcher,
- logwritter,
- stats collector process vs..
Deamon process client isteklerini dinler, gelen istekleri alır ve database connection işlemini başlatır.
Backend Processes
Backend Prosesler, Deamon prosesin gönderdiği istekleri alır kimlik doğrulama işlemlerinin ardından istekleri başlatır. Eğer max connection limit ayarlanmamışsa gelen tüm işlemler için bu işlem parallede yürütülür.
Bir client database bağlandıktan sonra istekleri (Select/update/insert/delete, alter, vs…) işleme Bir client database bağlandıktan sonra istekleri (Select/update/insert/delete, alter, vs…) işleme alınır fakat bu işlemleri yapmak isteyen binlerce kullanıcı olabilir, bu durumda işlemler biraz daha karışık bir hal alacaktır. Burada işlemlerin birbirini bekletmesi (lock,contantion) olayları ve memory yetmezliği gibi durumlar söz konusu olmaya başlayacaktır. Burada Performans tuning işlemleri devreye girecektir. Peki Performans iyileştirmeleri için bu işlemlerin genel yapısına bir bakalım;
Bir sorgunun işlenme şekli aşağıda verilmiştir.
- Connection gerçekleşir
- Parser gelen istek için bir syntax kontrolü yapar ve query tree (sorfu ağaç) oluşturur.
- Rewrite, parserdan gelen query tree
- Planner Sorgu ağacından en etkin şekilde yürütülebilecek plan tree (plan ağacı) oluşturur.
- Executor plan tree ye göre sorguyu işletir.
Utility Process
Varsayılan olarak checkpoint prosesi, WAL dosyalarının yazılması, Autovacuum launcher prosesleri, istatistik toplama prosesleri ile archive ve stream replica prosesleri vardır.
background writer process
background writer bir algoritma ile dirty buffer datasını diske yazmaktan sorumludur, checkpointer ise tüm dirty buffer datalarını yazar, buradaki algoritma en son hangi bloklara erişildi, shared buffer kullanım oranları gibi bilgileri kullanarak bufferdaki boş belleklerin bir an önce kullanıma hazır hale getirilmesidir.
Checkpoint
Bir kullanıcı bir data üzerinde değişiklik yaptığında (DML işlemi), bu işlem ilk olarak bufferda gerçekleşir hemen diske yazılmaz, bu değişiklik yaılan buffer bölümü dirty buffer olarak işaretlenir ve dirty bufferlar ise checkpoint işlemi ile diske yazılır. Checkpoint tüm dirty bufferları diske yazar ve bu buffer alanını temiz (clean) oalrak işaretler.
Burada 32 GB Shared buffer alanı olan bir sunucumuz olduğunu varsayalım. Bu yükün önemli bir ksımı yazmalardan oluşuyorsa, bu alanın bir çok kısmı hızlı bir şekilde dirty olarak işaretlenecektir. Burada checkpoint_segment için küçük bir değer set edilmiş ise, çok sık checkpointy olmasına neden olacaktır, yine benzer şekilde checkpoint_timeout düşük bir değere set edilirse sık checkpoint yüksek disk erişimine ve performasn kaybına neden olacaktır, fakat bu değerler yüksek tutulduğunda ise diğer sorguların performansı olumsuz etkilenecektir bu değerler için optimum bir seviye ayarlanması gerekmektedir.
WAL Writer
Bir data üzerinde bir değişiklik yapıldığında, yeni bir data yazımı yapılırken veya silineceği zaman (DML işlemleri) postgres bu değişiklikleri hemen anında gidip datafile dosyalarına hemen yazmaz, öncelikle bu işlemler bufferda geçekleştirlir ayrıca bu işlemler wal buffer belleğine de yazılır, değişiklikler onaylandığında (flushed, commit) WAL segmentlerine yazılırlar.
Wal ile ilgili bazı parametreler göz atarsak, örnek olarak fsync ise yapılan her işlemi diske yazmayı zorunlu kılar, bunu kapatmak özellikle bulk işlemlerde performansı muazzam arttıracaktır, ancak ani kesintileride (Elektrik kesintisi vs.) Tutarlılık (Consistency) problemine yol açabilir. max_wil_size parametresini küçük bir değere set etmek falza DML olan sistemlerde performasn sorununa yol açarken, büyük bir değere set etmek ise recovery süresini artıracaktır.
Autovacuum Launcher Process
Varsayılan olarak açık gelsede opsiyonel bir prosestir. Vacuum işlemi tablolar içersisnde daha önce kullanılmış fakat şu an kullanılmayan alanları kullanılabilir alan olarak işaretler, ayrıca bunun manuel olarak yapılan kmonutuda vardır. Vacuum işlemi tabloya herhangi bir lock koymaz. Ancak vacuum Full işlemi vacuum işleminden farklıdır, tablodaki daha önce kullanılmış alanları yeniden düzenler (shrink) ve bu işlem tablo üzerinde lock oluşturur.
Stats collector
stats collector process tablolarda, indexlerde gerçekleşen sorguları,bunların boyutlarını, parametrelerini ve değişimleri toplar.
Archiever
basitçe archiver process pg_xlog konumundan dosyaları archive konumuna kopyalama işlemini yürütür.
Logging Collector
Bu proses opsiyoneldir defaultta kapalı olarak gelir, database mesajlarını istenen seviyede database logfile larına yazmakla görevlidir. loglama seviyesini seçebiliriz.
log_min_duration_statement = 0
log seviyesi defaultta kapalı olarak gelir ve yukarıdali log_min_duration_statement= -1 dir. eğer “0” a set edilirse tüm veritabanı ifadeleri süreleriyle bir likte loglanır. Nu yaklaşım analiz açısından kullanılabilir ancak aktif bir sistemde log dosyaları hızla büyüyecektir. eğer log seviyesini “0” da tutacaksak bu logları farklı bir konuma taşımak gerekir.
Bir yanıt yazın