On Wed, 2010-01-06 at 23:21 +0200, Atıf CEYLAN wrote: > çalışlan sistem, üzerinde apache, cache sunucu, mail sunucu ve db olan > bir makine. ve malesef şuan sadece mail sunucu için ikinci bir disk > mevcut. (diğer tüm sistem tek sata disk üzerinde.)
Tek diskle ne kadar tuning yaparsanız yapın yük altında sıkıntı yaşarsınız. > - shared_buffers 4'ten 3'e düşürdüm şuan. db büyüklüğü ile > oranladığımda ve diğer uygulamalar için ram'e ihtiyacım olduğu için > shared bufferi ve effective cache size'ı mahsus düşük tuttum. 12 GB RAM'den ne kadarını PostgreSQL için ayırdınız peki? > - bgwriter_delay yüksek tutmamın nedeni malesef disk io'mun yüksek > oluşu. diski az kullanmaya çalışıyorum bi taraftan. > - checkpoint_completion_target 0.5 evet. wal_writer_delay, checkpoint > hedelerinin yüksek tutmamın en büyük nedeni yine disk sorunum. (gerçi > checkpointları önce loga, timout sonrası yine diske yazıyor olması > düşünüldüğünde evet değeri düşük tutmalıydım.) Sanırım checkpoint, xlog ve bgwriter kavramları bir miktar karışmış. bgwriter'ın iyi çalışması checkpoint etkisini azaltır. bgwriter'ı az çalıştırmak checkpoint yükünü arttırır. Diski daha az kullanmaya çalışıyorsanız checkpoint_segments = 15, cp_timeout=15min, cp_completion_target=0.7 değerleri ile deneyebilirsiniz. Ancak tek diskte ne yaparsanız yapın performans alamazsınız. Bir yandan xlog yazarken diğer Disk demişken scheduler'ı deadline yapın derim; farkı hissedeceksiniz (dağıtım Ubuntu server ise o zaman sanırım default olarak deadline geliyor scheduler, ama Fedora ve türevlerinde upstream default olan cfq geliyor). > - default_statistics_target 1000 yaptım, cok karmaşık olmasada > querylerin iyi planlanmasını istedim, nedeni bu idi. 1000 değeri yüksek. Düşürün. Karmaşık sorgularınızın olduğu tablolarda 150'ye kadar çıkartın. Herşeyi 1 diskte tek makinada yapıyorsunuz, dert orada. > - autovacuum_naptime = 10min olmasının nedeni, tablolarımın %90'ı > genelde select gören tablolar. %5'i sık insert, %5'i sık update ve > delete görüyor. yüksek tutma nedenim bu yüzden. naptime'ı uzun tutarak sadece bloat'ı arttırırsınız. naptime zararlı birşey değil. Sadece bir autovacuum subprocess'i başlar ve autovacuum_*_factor ayarlarına bakıp ona göre işlem yapıyor. Zaten genelde SELECT varsa autovac kılını kıpırdatmayacaktır. > cluster yok, Cluster = initdb yaptığınız yer. > tek db var. Tamamdır. > bu maili yazdığım sıralarda 311 select cümleciğinin çalıştığını > gördüm. Load avarage %69 ve ram taşmış, swap'i 1.2 GB olarak > kullanıyordu. :( loglamayı açın. Diğer uygulamaları da tune edin tabii. -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-sunucu E-Posta Listesi [email protected] Liste kurallarını http://liste.linux.org.tr/kurallar.php bağlantısından okuyabilirsiniz; Bu Listede neden bulunduğunuzu bilmiyorsanız veya artık bu listeden gelen e-postaları almak istemiyorsanız aşağıdaki bağlantı adresini kullanarak 1 dakika içinde üyeliğinizi sonlandırabilirsiniz. http://liste.linux.org.tr/mailman/listinfo/linux-sunucu
