From: Devrim GUNDUZ (devrim@gunduz.org)
Date: Tue 25 Oct 2005 - 22:02:40 EEST
Merhaba,
On Tue, 25 Oct 2005, Ethem Bilgin wrote:
> Bir internet sitesinde takribi 40.000 uye ile ugrasiyorum sistemin
> buyumesi ihtimalini goz onune alarak veri tabanını postgresql sectim ama
> performansindan hic memnun degilim.
>
> 10 15 gunde 4 GB lık bir dosya oluşturuyor ve sistem nerede ise
> calismaz hale geliyor ve yavasliyor. Her gece ayrica cron gorevi ile
> "VACUUM ANALYZE" calistiriyorum. Butun veritabanlarinin SQL dokumu 51MB
> tutuyor. Postgresql'e geri yukledigimde 550-600MB civari yer tutuyor.
PostgreSQL'de VACUUM çok önemli bir bileşendir. 8.0 sürümünde buna
gereksinim biraz azaltıldı. 8.1 sürümünde ise autovacuum deamon sunucu
içine entegre edildi ve artık arka planda süreklü olarak VACUUM çalışacak.
Hatta şöyle söyleyeyim: 8.0'da buffer management kodu geliştirildi. Ancak
8.0.2 sürümünde bu kod değiştirildi (IBM'in bir lisans sorunu nedeniyle)
ve bundan sonra başarım %20 gibi arttı. 8.1'de bu kod daha da geliştirildi
ve özellikle yeni gelen bitmap indexler nedeniyle testlerde %40'a varan
hız artışı ortaya çıktı. 8.1'in Kasım ayında duyurulması planlanıyor bu
arada.
Gelelim bütün veritabanlarının "SQL dökümü " ile verinin yüklenmesinden
sonra PostgreSQL dizininde oluşan farklılığın nedenine.
http://www.postgresql.org/docs/faqs.FAQ_turkish.html#4.6
Burada da anlatıldığı gibi sizin SQL tümcelerinizin veritabanı büyüklüğü
ile direk bir ilgisi yok. Kullandığınız ver tipler ile ilgili birşey bu ve
gayet doğal bir konu.
Eğer verileriniz sık sık "UPDATE" ve "DELETE" görüyorsa, o zaman VACUUM
kaçınılmaz olur. Bu MVCC'nin gerektirdiği bir özellik. MVCC olmasaydı
veriniz kararlı bir şekilde tutulmazdı.
VACUUM'a duyulan gereksinimi azaltabilirsiniz; bunu aşağıda
postgresql.conf dosyanızla ilgili yorum yaparken anlatacağım.
> Araştırınca reindex komutu ile sistemin baya kendine geldiğini gördüm
> bunu çalıştırınca dosya 700 mb lar mertebesine geldi. Her gece VACUUM
> ANALYZE'dan sonra REINDEX'i de Cron da bir gorev olarak olusturdum.
REINDEX'e gereksinim duymanız çok normal değil. Eğer yukarıda yazdığınızı
gerçekten yapıyorsanız; yani veriyi duöp edip sonra yeniden yüklüyorsanız
o zaman REINDEX'e gerek var, evet. Ama onun dışında VACUUM ANALYZE zaten
bu işi yapar. Yani yaptığınız işlemde bir sorun var.
> Reindexi crona yazdım ama mutlaka daha baska metodlar da vardır. Bu
> sistemi optimumda tutmam ve performansını arttirabilmem icin baska neler
> yapmamı onerirsiniz.
http://www.gunduz.org/download.php?dlid=91
adresinde bir belgem vardı bunun için. Buraya bakın isterseiz bir.
Ancak asıl önerilerim aşağıda:
> Sistem: Red Hat RHEL3
>
> DB: rhdb (postgresql) 7.4.10
Üstte yazdığım gibi 8.0.4'e geçmenizi öneriririm tez zamanda.
http://www.postgresql.org/ftp/binary/v8.0.4/linux/rpms/redhat/rhel-es-3.0/
adresinde de RPM'leri var. Ancak dump-reload gerekeceğini lütfen
unutmayın.
> Postgresql.conf dan ayarlananlar
>
> max_connections = 256
>
> shared_buffers = 512
shared_buffer *çok* düşük! Her bir shared_buffer'ın 8 KB olduğunu
anımsarsak 4 MB'lık bir sb değeri sizin için hiç birşey ifade etmez.
8000-10000 gibi birşeyi düşünmelisiniz.
> sort_mem = 65535
Bu değerin yüksek olması sorun çıkartabilir; çünkü bu değer *bağlantı
başına* kullanılır. Bu da yoğun sistemlerde sorun çıkartır. Bu değeri
düşürün. Eğer yüksek değerlerde sort_mem'e (yeni sürümlerde work_mem oldu
bu bu arada) gereksinmeniz varsa ilgili sorgunun önüne "SET sort_mem=..."
yazmanız daha uygun olur.
> vacuum_mem = 32168
Bu değeri biraz daha (64M) yükseltebilirsiniz.
(Yeni sürümde maintenance_work_mem oldu bu).0
> checkpoint_segments = 10
Bu değer normal. Ama isterseniz 1-2 daha arttırabilirsiniz.
> effective_cache_size = 60000
Her biri 8K olduğu için 480 MB oluyor bu. Bunu belleğin 2/3'üne
ayarlanması önerilir. Yani bu değer normal (64000'e de çıkartabilirsiniz)
> Sistemde 32GB SCSI disk mevcut.
İşte bir sorun da burada. Ne yazık ki bu hata sık yapılıyor. Yoğun bir
veritabanınız var ise bari 2 disk kullanın. İşletim sistemi+WAL dosyaları
1. diske, veritabanı da 2. diske. Daha fazla diskiniz varsa indexleri de
oraya atabilirsiniz örneğin.
Saygılar,
--
Devrim GUNDUZ
Kivi Bilişim Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
_______________________________________________
Linux-sunucu mailing list
Linux-sunucu@liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-sunucu