Postgresql12 Linux Kurulumu & Postgresql.conf Ayarları

Taner Hacıoğlu Blog - Sn.Devrim Gündüz postgresql 12 kurulumunu anlatıyor

Devrim Gündüz Postgresql 12 Kurulum Videosu ve Notları

 


* 13-15min pg_wal i ayrı bir diske taşıyın. Çünkü performans önemli.
* 15-16min docker uygulamalar için iyidir, VT için değil. Productionda kullanmayın.
* 16m EXTFS kullanın diskte (redhat7-8).
* 16-18min veritabanı ..../data/base içinde = neden :) database bu kadar basit
* 18m postgresql.conf a bir girelim. # ile başlayan yorum satırı okunmaz
* conf dosyamızda listen_addresses = '*' yapıyoruz. Çünkü localhost kalırsa hem uygulama hemde db aynı sunucuda demektir ki bu genelde pek mümkün değil.
* * ile bu makine üstündeki ip adreslerini dinliyoruz. Dışarıya erişim açmıyor. Sadece interface i açıyor. Yani güvenlik sorunu yaratmaz.
* 21m restart ile reload arasındaki fark nedir ? Bazı parametrelerin yanında açıklama vardır. Burada change request restart yazmakta olup ilgili değişiklik restart ile etkinleşir.
* Zaten default port 5432 isterseniz port değerinden değiştirebilirsiniz. Birden fazla instance kurulacaksa farklı portlar set edilmelidir.
* 22min Soru: Bir makinada aynı portu dinleyen iki tane postgresql çalıştırmak mümkün. peki nasıl ?
* max_connections : Sunucunun kaldırabileceği bağlantı adetine göre belirlenmelidir. Ortalama donanımlarda 600-700 bağlantı sağlanabiliyor.
* 24min superuser_reserved_connections = 3 olası bir sorunda veritabanına bağlanıp sorunu çzömek için postgres userına ayrılan bağlantı sayısı
* Yani uygulamalardan ostgres userı ile sisteme bağlanılıyorsa rezerv sayı dolacaktır. Bu yüzden applere ayrı userlar ayrılmalıdır.
* tcp_keepalives --idle, interval, count, timeout =0 olsa dahi işletim sistemi defaultu neyse o kabul edilir.
* 28min shared_buffers çok kritik bir parametre... Tüm sorgular buradan çalışır(select, insert vs). Ramin %25i veya %50si gibi pgtune tavsiyeleri çok hatalıdır. Bu yanlışa uymayınız. Çünkü postgres'in ram kullandığı tek parametre burası değildir.
* 32min 1 Nisan Çarşamba günü enterprisedb de yapılan webinar (Devrim Gündüz tarafından) incelenirse... Sunucu üstünde kaynak kod kullanmanın riskleri anlaşılabilir. 
* 33min Shared_buffers başlangıç mümkünse 8GB başlayın. Okumanız fazlaysa 16GB artırın az ise düşürün. Tabi ki sunucuda 32-64GB ram olmalı bunun için
* 35min huge_pages bu parametre için linux sisteminde bir şeylerin aktif edilmesi gerekiyor. Sonra anlatıcam.
* max_prepared_transaction uygulama tarafında kullanılıyorsa açılmalı ve max_connections ile eşit tutulmalıdır. Aksi durumda açmayınız, performans düşecektir. App önemli !!
* 36min work_mem parametresi order by, group by, distinct, merge join gibi hash işlemleri için önemlidir. work_mem'in yeterli olup olmadığını anlamak için disk üstünde yaratılan 
log_temp_files'ları incelemek gerekir. WORK_MEM parametre değerini aşan sortlar disk üstünde yapılır. Explain Analyze ile kontrol sağlanabilir.
* maintenance_work_mem = 1 GB üstünde çalışmaz çünkü postgres kodu bunu kullanıyor.
* autovacuum_work_mem = -1 ise maintenance_work_mem kadar yer kullanır. Farklı değer vermek istenirse verilebilir.
* 40min temp_file_limit bu work_mem yetmediği durumda verilecek olan sayıdır. Sınırsız olunca sistem hack edilmesi için ortam sağlar. DBA tarafından belirlenmelidir.
* 41min vacuum_cost_delay, page_hit,page_miss,page_dirty,cost_limit Vakum multi version concurrency control MVCC satırlarının temizlenmesini sağlar. Update, Delete çok olan DBlerde vakum IO işlemlerini yavaşlatabilir.
* 44min max_files_per_process  query process başına ilgili query processin dokunabileceği file sayısı
* 45min bgwriter_delay genellikle 100 verilir. 10un katları şeklinde set edilmelidir. 10,20,30,100,1000 gibi
* bgwriter_lru_maxpages = 100 laptop ayarıdır. 3-4 yıllık yeni popstgres versiyonlarında 10.000 tercih edilerek daha fazla temizleme yapması sağlanmalıdır. Dirty bufferi siler güzel ve kritik bir performans seçeneğidir.
* bgwriter_lru_multiplier  bgwriter yetersiz kalınca query backend işlemlerinin kaç ile çarpılacağını belirtir. 4 idealdir. 1 anlamsızdır. Buna göre yetersiz durumlarda 4 kat fazla temizleme işlemi devreye girecektir.
* 48min effective_io_concurrency performans için kritiktir. Kaç adet IDE disk varsa Raid hariç, Raid 1 için 8 disk o zaman 4 disk demektir. Linux için geçerli parametredir. Genellikle 100 kullanılır prefetch etmesi için. 
* 49min max_parallel_processes ve workers paralel yürütülebilen işlemler için geçerlidir. Örneğin pg11de CREATE INDEX paralel yürütülebilir. max_parallel_maintenance_workers =2 gibi set edilebilir. gather çok kritik ilçe seçim kurulundaki sandıklar birleştirilir ve il seçim kuruluna gönderilir.
80 çekirdekli CPU için 60 verilmez. Çünkü her işlem paralel yapılamaz , postgre bazı durumlarda da yapmayacaktır. 40 cpu için 16 değeri iyidir.
* 51min fsync on olmalıdır. Datayı senkronize etmeyi sağlar. Tıpkı flash diskin direkt pcden çekildiğinde verilerin yazılmamış olması gibi sorunu engeller. Datanın yazıldığını garanti eder.
* 52min full_page_writes elektrik kesintisi gibi durumlarda fpw sayesinde wall içinden doğru kaydı alacak. Bu bir checkpoint yöntemi... Bu yüzden veri kaybı postgresqlde rastlanmaz. Fiziksel diskte sorun olmadığı sürece işe yarar.
* 54min  wal_compression fpw (full page write) lerin sıkıştırılıp sıkıştırılmayacağını belirtir. Çok fazla yazma işlemi varsa açılmalıdır.
* wal_buffers = -1 shared buffer içinde bir alan var bunu wal için kullanabiliriz. 16,32,64MB verilebilir. Yazma işlemi ne kadar yoğunsa artırılabilir.
* 56min checkpoint_timeout DW gibi okuma işlemi yapılan DB ise 1 gün set edilebilir. Normalde 15min yeterlidir.
* max_wal_size 16GB performans stabilitesi için tavsiye edilir. Disk alanınız müsait ise.
* checkpoint_completion_target = 0.7 iyidir. 15min x 0.7 zamanında yazma işlemini bitirecektir. Bu sayı düşerse IO yükselir süre kısalmıştır fakat sisteme yük getirir. Zamana yaymak için 0.7-0.9 verilebilir böylece daha yavaş ve düşük IO ile yazar.
* 57min seq_page_cost sıralı okuma maliyeti 1 birim, random için 4 birim. 1 e 1.5 ssd için iyidir.
* 60min effective_cache_size önemlidir. Sisteme ait cachedir. Ram'in %50si kadar verilebilir. Veritabanının ne kadarı cache edilebilir bunu sağlar.
* 69min insert into t1 (Select generate_series(1,1000000));
* 60-69min performans için huge_pages açmak performans için avantaj getirmektedir.
* 70min pg_buffer_cache extention aracı
* 74min pg_activity aracı
* 75min ALTER SYSTEM SET work_mem TO '8MB'; select pg_reload_conf(); show work_mem;
* SELECT * FROM pg_settings WHERE name = 'work_mem';
* 76min work_mem'in önemi anlatılıyor. EXPLAIN (ANALYZE ON, BUFFERS ON) select * from t1 ORDER BY c1; work_mem yetmediği için sorgu (query plan) sonucunda external merge yani en yavaş merge işlemi yapıldı.
* work_mem yeniden 1GB a set edilince quick sort yapıldı. Gayet başarılı 
* 80min lock konusuna değiniliyor.