Merhabalar arkadaşlar,
Serinin 2.yazısı ile karşınızdayız. Dikey büyüme,
Önceki yazımdan da hatırlayacağınız üzere genel olarak ERP kavramı yaygınlaşmış büyük firmaların tercih ettiği bir yapı olarak karşımıza çıkmaktadır. Genel manada kaynakların artırımı şeklinde olmakla karşımıza çıkmaktadır.;
Örnek Senaryo; xxx erp sistemi kullanıyorsunuz ve ortalaam 100 kullanıcınız var ve bunların anlık aktif kullanıcı sayısı 30-40 arasında ki bu da 10.00-11.30 saatleri arasında aktif olmaktadır. Veri büyüklüğünüz ortalama veri tabanı olarak 600-900 GB olarak tahminen sistemde yer almaktadır.
Ara Bilg; Bu zamana kadar istisnalar olacağını başla söylemek koşulu ile Fabrika ERP sistemlerinin en yoğun olarak kullanıldığı saat aralığı 10.00-11.30 arasındadır.
PostgreSql geleneksel veri tabanı yönetim sistemleri içerisindedir. Her kullanıcı için bir istemci kuyruğu oluşturarak işlemleri alt gruplama yöntemi ile çalıştırmaktadır. Bu demek oluyor ki sizin ne kadar kaynağınız varsa process/işlemler bölünerek cpu üzerindeki kaynaklara orantılı şekilde paylaşıtırılarak işlemler yapılmaktadır.
— Sisten katmanı
ALTER SYSTEM SET max_connections = 100;
–veri tabanı katmanı
ALTER DATABASE database CONNECTION LIMIT 100;
–kullanıcı katmanı
ALTER ROLE user CONNECTION LIMIT 10;
şeklinde örnek kodlamalar ile sistemin gereksimine göre ayarlanmaktadır. Bu ayarları yaparken deneyimlerin ön plana çıktığını bilmeniz gerekmektedir. Yoksa gereksiz CPU kullanımı ve dar boğazlar oluşturulmasına neden olunabilir.
Ufak Bir ince ayar gerekli olan kısım:
Postgresql sisteminde acuuming, replication, subscriptions bu işlemler için bir takım ayarlar vardır. Bunların temizlenmesi ve ayarların doğru yapılması gerekmektedir. conft tablosunda varsayılan olarak 8 gelen değerin 16 ‘ya çıkartılması sistem için önemli olabilir.(yukarıdaki senaryo bağlamında)
max_worker_processes = 16
Hal böyle olunca bu işlem sonrasında sistemdeki paralel çalışan işlem sayısı artmakta ve geçikmelerin min.yaşanması sağlanmaktadır.
Özellikle 9.6 versiyonundan sonra gelen özellik ile çağrılan sorguların paralel halde işlem yapılması daha stabil olmuş ve alt işlem grupları parçalarına bölünerek yapılmaktadır.
max_parallel_workers = 4;max_parallel_workers = 8; ifadeleri ile 4 yada 8 paralel sorgu çalıştırlablecek ayarlamalar yapılmaktadır.
max_parallel_workers_per_gather = 8 Gather node sayısı olarak çalışma node bilgisini göstermektedir.
Ayrıca;
Ara bilgi; Postgresql üzerinde GIN-BTREE indexleme yapısı vardır. bunların çalışma mantığı ve verimli çalışma konumları farklı olmak üzere varsayılan btree index yapısı özellikle v11 sonrasında gelen bir özellik ile indexlemenin paralelleştirilmesi durumu vardır.
max_parallel_maintenance_workers = 8
Ayrıca bu işlemlerin paralel çalışması yukarıda verdiğim paralel çalışma ayarı ile ilişki olduğunu da unutmamak gerekmektedir.
WAL Sıkıştırma işlemleri; daha sonra uzun uzadıya bilgisi verilmesi gereken bir konu olmak üzere ayarlarını
wal_compression = on şeklinde düzenlenmesi gerekmektedir.
BELLEK YÖNETİMİ
Sorgu işlemleri temelde disk tüketim argümanı olarak karşımıza çıkmaktadır. Yapılan sorgunun boyutuna göre nekadar tüketilceği tahmini olarak sistem tarafından hesaplanarak işlemler yapılmaktadır. Yukarıdaki işlemlere göre cahce size i 64gb olması uygun olacaktır. genel olarak %10 civarında bir oran ile çalışma yapılmaktadır. Buradaki genellemeler yaşadığımız deneyimler sonrasında oluşmaktadır. Bu şekilde bir standart olmadığının da farkında olmanızı isteriz.
effective_cache_size = 64GB
shared_buffers = 32GB
Bu ayarlama ile işlemci geri plan işleri için kullanılacak boyut olarak karşımıza çıkmaktadır.
temp_buffers = 100MB
work_mem = 16MB
temp buffer alanı temp db üretilen sorgulamalar için kullanılarken 4mb varsayılan olarak ayarlanmış work_mem;özel geri plan süreçleri için kullanılmaktadır.(having gibi agr.table işlemleri,fullfil,sorf.join ) operatorleri için kullanılmaktadır.
Ayrıca network tarafında sature olunmaması için loadbalance ile yedekli çalışmak gerekemtedir.
Sistem ayarlarının varsayılan olarak eğer mümkünde linux çekirdek sistemlerden ve mümkünse ZFS sistemi üzerinde çalıştırmanız hızlı okuma ve yazma sonuçları ile karşınıza gelmektedir. Eğer mümkün değilse ki win.sunucu üzerinde ortalama 1 haftada kaynak tüketimin çok yoğun olduğunu ve temizleme işlemlerin gerekliliği karşınıza çıkacaktır.
