Postgres istatistik toplayıcı işlemi tarafından çok fazla G / Ç oluşturuldu

10

XenServer'ı yerel postgres veritabanlarına sahip birkaç sanal makine ile kullanıyorum. Tüm uygulamalar kullanılmadığında ve veritabanları boşta olsa bile, her vm sabit depolama ağı trafiğine neden olur ve bu da iscsi depolama aygıtının performansını düşürür.

Çalıştırdıktan sonra iotopben postgres istatistik kollektör işlemi süreci sürekli yaklaşık 2 MByte hızında diske yazma belirtmişlerdir / s.

Daha sonra düzenleyerek istatistik toplamayı devre dışı bıraktım /etc/postgresql/8.4/main/postgresql.conf:

#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------

# - Query/Index Statistics Collector -

track_activities = off
track_counts = off
...

olarak önerilen http://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htm .

Bu sürekli yazmayı ortadan kaldırmıştır, ancak istatistik izlemeyi kapatmak için dezavantajlar var mı?

Yoksa disk / ağ trafiğinden kaçınmak için pg_stat_tmp dizinini bir ramdiske yerleştirmeli miyim?

Sistem postgres 8.4 ve yaklaşık 50 tablo ile yaklaşık 20 veritabanı ile güncel bir Debian 6.0.7 (sıkmak), toplam dökümü dosya boyutu 100 MByte daha azdır.

— nn4l
kaynak

7

PostgreSQL'in yükseltilmesi bir seçenek olmadığından, önemli bir performans artışı sağlayan bir tmpfs dosya sistemine pg_stat_tmp dizinini yerleştirmeyi denedim. Şimdi bunu birkaç ay boyunca gözle görülür bir dezavantaj olmadan birkaç düzine sistemde çalıştırıyorum.

Bunu yapmak için, pg_stat_tmp dosyasını / etc / fstab dosyanıza tmpfs ile bağlamanız yeterlidir:

# <file system> <mount point>                                <type>  <options>  <dump>  <pass>
tmpfs           /var/lib/postgresql/8.4/main/pg_stat_tmp     tmpfs   defaults,noatime,mode=1777,uid=postgres,gid=postgres,nosuid,nodev 0 0

— nn4l
kaynak

Bunu Postgresql 9.1 için yaptım. Sunucularımdan biri gün boyunca sürekli olarak 1 MB / sn yazdı. Bu neredeyse hiçbir şeye düşmesini sağladı. BTW belgeleri tarafından onaylandı : "... Bunu RAM tabanlı bir dosya sistemine yönlendirmek fiziksel I / O gereksinimlerini azaltacak ve performansın

— yükselmesine

0

PostgreSQL'i yükseltin. Mutlak minimumda, en son 8.4 sürümüne sahip olduğunuzdan emin olun; eğer bu sorunu çözmezse ve pratik ise muhtemelen 9.2'ye yükseltmelisiniz. İstatistik toplayıcı çevresindeki en azından bazı sorunlar 8.4'ten beri ele alınmıştır ve yaklaşık bir yıl içinde kullanım ömrünün sonuna ulaşacaktır . Pgsql-general mail list arşivlerinde arama yaparak daha fazla bilgi bulabilirsiniz .

Her zamanki gibi olsa Sen, 8.4 ile 9.2 çok fazla sorun yükseltme olmamalıdır gerekir her 0,0 bırakma Inbetween (9.0, 9.1 ve 9.2) için sürüm notları yükseltme bölümünü okuyun. Özellikle dikkat edin standard_conforming_stringsve bytea_output.

— Craig Ringer
kaynak

0

Burada da aynı problem. Ben de engelli track_*vb.

Yan etki, autovacuumbu toplanan verileri ateşlemek için kullanmasıdır.

Bu yüzden her gece programlamaya dikkat ediyorum a vacuumdb.

Diğer bir çözüm, autovacuum_naptimesistemin dinlenmesine yetecek kadar yükseğe yerleştirilmesidir.

— Gelma
kaynak