Proses Mimarisi

Prosesleri 4 ana gruba ayırabiliriz.

  1. Postgres Proses (Eski ismi Postmaster)
  2. Background Proses
  3. Backend (server) Proses
  4. User/Client (istemci) Proses

Not: Stats collector prosesi, versiyon 15 ile birlikte kor sisteme dahil edilmiştir, ayrı bir
proses değildir.

Postgres Prosesi

ps -ef | grep postgres

postgres 2450 1 /usr/lib/postgresql/14/bin/postgres -D
/var/lib/postgresql/14/main -c config_file=/etc/postgresql/14/main/postgresql.conf
postgres 2451 2450 14/main: logger
postgres 2453 2450 14/main: checkpointer
postgres 2454 2450 14/main: background writer
postgres 2455 2450 14/main: walwriter
postgres 2456 2450 14/main: stats collector
postgres 2457 2450 14/main: pg_cron launcher
postgres 2458 2450 14/main: logical replication launcher

ll /usr/lib/postgresql/14/bin/postmaster
/usr/lib/postgresql/14/bin/postmaster --> postgres

Debian temelli linuxlerde postgres prosesi (RHEL tabanlı linuxlerde path farklıdır.)

Instance’ta ilk açılan ve diğer prosesleri başlatan ana (parent) prosestir. Örnekte
görüleceği üzere parent proses ID 2450’dir Diğer postgres proseslerin, parent ID’si 2450
olarak görülmektedir.

Postgres prosesi;

  • İşletim sisteminden hafızayı (memory) alır.
  • Background prosesleri başlatır.
  • Gerekli ise tamir (recovery) işlemini yapar.
  • Network’ ü dinleyerek postgresql veritabanına gelen bağlantı isteklerini karşılar
    (Listener olarak görev yapar).
  • Defaultta TCP 5432 portunu dinler, değiştirilebilir (kapatıp açmak gerekir).
  • Açılış sırasında yapılan işlemleri veya hata mesalarını log dosyasına yazar (/var/log/postgresql/postgresql-…..log).
  • Bir postgres proses bir adet cluster’ı yönetebilir. (Storage bölümünde cluster
    kavramı anlatılmıştır.)

Background (Utility) Prosesleri

pgrep -a postgres
2450 /usr/lib/postgresql/14/bin/postgres -D /var/lib/
postgresql/14/main -c config_file=/etc/postgresql/14/main/
postgresql.conf
2451 postgres: 14/main: logger
2453 postgres: 14/main: checkpointer
2454 postgres: 14/main: background writer
2455 postgres: 14/main: walwriter
2456 postgres: 14/main: stats collector
2457 postgres: 14/main: pg_cron launcher
2458 postgres: 14/main: logical replication launcher

pstree -p 2450
postgres(2450)─┬─postgres(2451)
├─postgres(2453)
├─postgres(2454)
├─postgres(2455)
├─postgres(2456)
├─postgres(2457)
└─postgres(2458)

Parent (ana) postgres prosesinin ID’sini pstree ile incelediğimizde background ve backend/server prosesler görülmektedir.
Instance’ın çalışabilmesi için gerekli olan proseslerdir.
Instance açıldığında başlatılırlar.
Bazıları aktif edilen özellikle birlikte çalışmaya başlar.
BG Writer, Logger, Checkpointer, WAL writer, Autovacuum launcher, Archiver, Stats collector, WAL sender/receiver vb.

Backgorund Writer Proses

Shared Buffer‘daki alan yetersiz kaldığında az kullanılan dirty buffer alanlarını diske
yazarak bu alanları tekrar kullanıma açar.
Asenkron yazar. Yazmadığı zamanlarda (idle) sleep modda bekler, kendini kapatmaz.
Ne kadar süre uyku (sleep) modunda kalacağı bgwriter_delay parametresi ile ayarlanabilir.
Default değeri olan her 200ms’ te bir çalışır.
bgwriter_lru_maxpages; Her çalıştırışta max kaç bloğun (pages) yazılacağını belirler.
bgwriter_lru_multiplier; İhtiyaç duyulan clean buffer miktarına ulaşmak için kullanılır.
(multiplier değeri 2 iken 50 blok clean buffer alanı gerekirse 100 blok dirty shared
buffer alanı diske yazdırılarak clean buffer olarak işaretlenir)

Dirty Buffer : Hafızadaki yeni ya da işlem görmüş veri bloklarıdır.
Clean Buffer : Kullanıma müsait hafıza alanı.

Checkpoint Proses

Checkpoint noktaları recovery işleminin nereden başlayacağını (transaction sequence)
adresler.
Checkpoint zamanı tüm dirty buffer’daki veri blokları diske yazılır ve checkpoint’e
ait özel kayıtlar, log (replorigin) dosyasına yazılır (Öncesinde veritabanında yapılan
değişikliklerin metadata bilgisi WAL/REDO dosyalarına yazılmış olur).
Aynı zamanda WAL dosyasına, diske kayıt edilen transaction bilgileri girilir. Ve shared buffer’ daki bloklar clean olarak işaretlenir ki yeniden kullanılabilsin.

Örneğin elektrik/donanım arızası vb. nedenlerden sunucunun fiziksel olarak kapanması
veritabanın tutarsız hale gelmesine neden olur. Böyle bir durumda veritabanı açılırken
recovery başlatır.
Recovery prosesi en son yapılan checkpoint bilgisini alır ve diskte yazılamamış
transactionları, WAL dosyalarından, yeniden çalıştırararak veri dosyalarını (datafile)
tutarlı hale getirip instance’ı açar.
Checkpoint gerçekleştiğinde tüm dirty buffer’ daki veri bloklarını diske yazdırmak
istemesi I/O yüküne neden olacaktır. Bu yüzden checkpoint prosesi sınırlandırılmıştır ;
I/O, checkpoint start noktasından başlar ve bir sonraki checkpoint’ten önce tamamlar.

Checkpointer prosesi sık sık checkpoint işlemini gerçekleştirir.
Checkpoint işleminin hangi sıklıkla yapılacağı checkpoint_timeout parametresi
ile belirlerlenir. Default değer 5 dakikadır. Yani checkpointer 5 dakikada bir checkpoint
işlemini başlatır ya da max_wal_size değerinde, hangisine önce erişilirse.
Önceki checkpointten itibaren WAL yazılmadı ise yani transaction olmadı ise
checkpoint_timeout süresi geçse de checkpoint gerçekleştirilmez.
checkpoint_timeout ve/veya max_wal_size değerleri düşürülürse sık
checkpoint işlemi gerçekleşir ama bununla birlikte recovery süresi kısalır. Sık checkpoint
de maliyetli olacağı için dengede tutulması gerekir. Veritabanının kullanım amacına ve
yüküne göre ayarlanması gerekir.
checkpoint_warning parametresi ayarlanarak istenen aralıktan daha sık
checkpoint olduğunda log dosyalarına yazması sağlanabilir.

WAL Writer Proses

Verideki değişiklikler diske asenkron yazılır (eşzamanlı yazılmaz).
Değişiklik yapılan veri blokları shared buffer’da tutulur.
Değişikliğin metadata kayıtları da WAL buffer’da tutulur.
Commit geldiğinde WAL buffer’daki REDO kayıtları WAL segments’e yazılır.

wal_level : WAL dosyalarının hangi kayıtları içereceğini tanımlar.
Default değer replica’dır. Bu değer WAL archiving, hot standby (readonly) için yeterlidir.
minimal’da crash ve immadiate shutdown durumlarında gerekli olan bilgiler
haricindeki tüm logları siler. Baseback için uygun değildir. Veritabanını basebackup
restore ve recover işlemleri için gerekli bilgileri içermez. Base backup için replica ya da
logical olmalıdır.
logical’ da replica’ ya ek olarak logical standby için gerekli olan decoding bilgilerini
de içerir.

wal_writer_delay : Hangi sıklıkla wal buffer’ın flush edilip içeriğinin diske
yazılacağını belirler.

wal_keep_size : pg_wal dizininde en az bulundurulması gereken WAL
boyutunu belirler. Eğer standby sunucularınız herhangi bir nedenden dolayı geride
kalırsa pg_wal daki WAL dosyalar ile kendini günceller.
min_wal_size : WAL dosyalarının disk kullanımı buradaki boyuttan küçük kaldığı
sürece, check point işlemlerinde eski WAL dosyalarını silmek yerine, üzerine yazılarak
yeniden kullanılır. Böylece burada belirtilen disk alanı rezerve edilmiş olur. Default
değer 80 MB’dır.
max_wal_size : Otomatik checkpoint sürecinde büyümesine izin verilen boyuttur.
Soft limittir, ağır yük altında iken archive_command hata alıp arşivleme
yapamadığında veya wal_keep_size’a yüksek değer verildiğinde burada belirtilen
boyutu geçebilir.

WAL Archiver Proses

WAL archiver prosesi, backup ve standby sunucuları güncel tutmak için WAL dosyalarını
arşivler. Defaultta kapalı gelir. Opsiyoneldir. archive_mode parametresi ile aktif
edilir. İki modu vardır; on ve always.
Normal operasyonda fark yoktur. Ama always seçilirse recovery ve standby modda iken
de arşivlemeye devam eder.
wal_level wal dosyalarına yazılacak detayı ayarlar.
Minimal değeri, arşivleme için yeterli değildir bu yüzden aktif edilemez.
archive_command = 'rsync -av %p /RA/archive/'
Pgbackrest vb. yedekleme araçları kullanılan ortamlarda farklı değerler alır.
Örnek:
archive_command = 'pgbackrest --stanza=mx_stanza archive-push %p'

NOT:
1-Online backup ve standby sunucular, kritik veritabanları için elzem olduğundan WAL
arşivleme, aktif edilmesi neredeyse zorunluluktur.
2-Diğer veritabanlarını da göz önünde bulundurarak, dump, restore batch vb. yoğun
WAL üreten işlem öncesinde arşivlemeyi durdurmak performans için faydalı olacaktır.
(archive_mode off, wal_level = minimal ve max_wal_senders =0). İşlem sonrasında tekrar başlatılır.

Logger Proses

Veritabanındaki olayları güncel log dosyasına yazan prosestir.
Logging collector defaultta kapalıdır (off) ve kapalı iken sadece stderr mesajlarını
sistemin default log dizinine yönlendirilir.
(/var/log/postgresql/postgresql-14-main.log)
logging_collector = on ile aktif edildiğinde (restart gerekir), logger prosesi
açılır ve log dosyalarını log_directory=log parametresinde belirtilen dizine
yazmaya başlar.

Örneğin : /var/lib/postgresql/14/main/log/postgresql-09-23.log
Tam path de verilebilir (postgres kullanıcısının yazma hakkı olması gerekir).
Eğer path verilmezse /var/log/postgresql içerisine yazar.

Autovacuum Launcher Proses

Opsiyonel bir prosestir. Defaultta aktif gelir (autovacuum=on).
Autovacuum workers prosesleri veri dosyalarındaki (datafiles) atıl alanları yeniden
kullanıma açarker. Autovacuum launcher ise bu autovacuum worker proseslerini
çalıştırır.

Vacuum

Bir tablodaki bir satır silindiği zaman;
Postgresql bu satırları hemen veri dosyasından (data file) silmez.
Bu satırlar silinmiş (deleted) olarak işaretlenir.
Aynı şekilde bir satır güncellendiğinde de (update) kabaca bir silme (delete) ve bir
ekleme (insert) işlemine karşılık gelir.
Satırın güncellenmeden (update) önceki hali halen veri dosyasında (data file) yer
almaya devam eder. Sonuç olarak veri dosyalarında (data file) kullanılamayan atıl
alanlar oluşur. Bu atıl alanlara dead record adı verilir.
Vacuum prosesi dead record’ları tekrar kullanılabilir (reusable) olarak işaretler.
Vacuum işlemi tabloyu kitlemez.
Vacuum komutu manuel çalıştırılabilir.

Vacuum Full

Vacuum prosesinin kullanılabilir (reusable) olarak işaretlediği kayıtları siler, tabloyu
yeniden organize eder ve atıl alanları sisteme yeniden kazandırır.
Vacuum full, boş bir veri dosyası (data file) oluşturur.
Dead record olmayan satırları/kayıtları (record) yeni veri dosyasına (datafile) kopyalayıp
orijinal dosyayı boşaltır.
Dikkat; vacuum full, işlemi tabloyu exclusive modda kilitler. Transaction’ın az olduğu zamanlar tercih edilmeli. Gerekiyorsa kesinti alınmalı.
Tablonun bir kopyasını oluşturacağı için diskte yeterli alan olması gerekir.

Vacuum analyze

Tabloların kayıt sayılarını okuyup sorgu planlayıcısı (query planner) için istatistik
oluşturur.
Autovacuum launcher prosesi de bu vacuum komutlarını otomatize eder.

Stats Collector Proses

Opsiyonel bir prosestir, defaultta aktif gelir.
Veritabanındaki aktivite bilgilerini toplayan ve bunları raporlayan bir alt sistemdir.
Tablo ve indexlere erişim sayılarını hem disk bloğu hem de satır seviyesinde toplayabilir.
Her tablonun satır sayısını, analiz ve vacuum işlemlerini takip edebilir.
Kullanıcı tanımlı fonksiyonların (user-defined functions) çağırılma/çalıştırılma sayılarını
ve bunların ne kadar zaman aldığını takip edebilir.
Postgresql, veritabanında anlık olarak gerçekleşen tüm aktivitleri raporlayabilir.
Örneğin ; Server prosesleri tarafından çalıştırılan komutlar, bağlantılar (connection),
oturumlar (session). Bu özellik collector prosesinden bağımsızdır.
Bu istatistikler stats_temp_directory parametresinde adreslenen dizinde
tutulur. Ağır yük altında çalışan veritabanlarında bu dizin ram-base disk/SSD gibi hızlı
disklerde tutulması performansı artıracaktır. Instance tutarlı kapatıldığında, istatistikleri
kalıcı bir kopyası $PGDATA/pg_stat_tmp dizinine kopyalanır. Böylece kapatıp
açmalarda istatistikler kaybedilmez.
Instance tutarsız kapanırsa (immediate shutdown, server crash) açılırken recovery
ile yapılacağından istatistikler kaybedilir. Aynı şekilde point-in recovery işleminde de
kaybedilir (Versiyon 15 ile birlikte kor sisteme entegre edilmiştir, artık ayrı proses olarak
çalışmaz).

#İstatistikleri aktif/deaktif etme ;
alter system set track_counts='on';

#Oturum (session) / server proseslerin çalıştırdıkları
komutların istatistikleri
alter system set track_activities='on/off';

#Kullanıcı tanımlı (user defiined functions)
alter system set track_functions = 'none, pl, all';

# I/O monitoring
alter system set track_io_timing= 'on/off';

#Default değerlere geri dönmek için;
alter system reset track_activities;
alter system reset track_counts;
alter system reset track_functions;
alter system reset track_io_timing;

İstatistik toplamak veritabanına ek yük getirecektir. Detaylı analiz gerektiğinde ek
istatistikler aktif edilip sonrasında kapatılabilir.
track_counts : Veritabanındaki aktivite istatistiklerini ve index ve tablolarla ilgili
istatistiklerin toplanıp toplanmayacağını belirler. Defaultta açıktır çünkü autovacuum bu
bilgilere ihtiyaç duyar.
track_activities : Server proses tarafından o an çalıştırılan komutları monitor
edebilmeyi sağlar. Defaultta aktiftir. Superuser değişiklik yapabilir. Buradaki raporları
superuser ve oturumun (session) sahibi sorgulayabilir. Güvenlik açığı oluşturmaz.
track_functions : Kullanıcı tanımlı fonksiyonlerın (User-defined functions) takip
edilmesini aktif eder.
track_io_timing : Blok okuma yazma işlemlerini monitor etmeyi aktif eder.

İstatistiklerin Sorgulanması

postgres=# \d pg_stat
pg_stat_activity              pg_statistic
pg_stat_all_indexes           pg_statistic_ext
pg_stat_all_tables            pg_statistic_ext_data
pg_stat_archiver              pg_statistic_ext_data_stxoid_index
pg_stat_bgwriter              pg_statistic_ext_name_index
pg_stat_database              pg_statistic_ext_oid_index
pg_stat_database_conflicts    pg_statistic_ext_relid_index
pg_stat_gssapi                pg_statistic_relid_att_inh_index
pg_statio_all_indexes         pg_stat_progress_analyze
....

Dynamic statistics view lerdan toplanan istatistikler sorgulanabilir.
psql ile bağlanıp "\pg_stat" yazıp, iki kez tab a bastığımızda yukarıdaki liste gelecektir.
Not: Bu istatistik bilgileri inceleyerek üzerinde I/O işlemi çok olan tabloları veya
üzerinde bulundukları table space’leri hızlı disklere taşıyarak performans artışı
sağlanabilir.

WAL Sender/Receiver

Aktif/Pasif cluster mimarilerde replikasyonu gerçekleştiren proseslerdir. WAL receiver
prosesi slave (secondary/standby) sunucuda (nod) çalışır, TCP/IP üzerinden master
(primary) sunucuya (nod) bağlanır.
Master nodda da WAL sender prosesi bulunur. WAL sender WAL dosyalarını slave noda
göndermekten sorumludur. WAL receiver da bu WAL dosyalarını almaktan sorumludur.

Backend (Server) Proses

Her oturuma (session) bir backend/server proses karşılık gelir.
Kullanıcıların isteklerini (select, insert, update vb.) postgresql tarafında
yürüten prosesdir.
Her oturum kendi kullanımı için Per Backend Memory alanını sistemden alır.
Maximum backend/server proses sayısı max_connections parametresi ile limitlidir.
Default değer 100’dür.

Client/User (İstemci) Proses

Veritabanı sunucusu üzerinden ya da network üzerinde bağlantı yapılan program ya da
araçtır.
Örnek; Pgadmin, psql web uygulaması, java uygulaması vb.

Kategori seçin...