Düzenli VAKUM ANALİZİ 9.1 altında hala tavsiye ediliyor mu?


38

Ubuntu'da PostgreSQL 9.1 kullanıyorum. VACUUM ANALYZEHala programlanmış mı , yoksa tüm ihtiyaçlara cevap verebilecek kadar otomatik boşluk var mı?

Cevap "duruma bağlı" ise, o zaman:

  • Büyük bir veritabanına sahibim (30 GiB sıkıştırılmış boşaltma boyutu, 200 GiB veri dizini)
  • Veritabanına ETL yapıyorum, haftada 3 milyon satıra yaklaşıyor
  • En sık değişiklik yapılan tabloların tümü bir ana tablodan miras alınır, ana tabloda veri yoktur (veriler haftaya bölünür)
  • Saatlik toplamaları ve oradan günlük, haftalık ve aylık raporlar oluşturuyorum

Soruyorum çünkü programlanmış VACUUM ANALYZEraporlarımı etkiliyor. 5 saatten fazla çalışıyor ve bu hafta iki kez öldürmek zorunda kaldım, çünkü düzenli veritabanı ithalatını etkiliyordu. check_postgresveritabanında önemli bir şişkinlik rapor etmediğinden, bu gerçekten bir sorun değildir.

Dokümanlardan, autovacuum, işlem kimliği sarma işlemine de dikkat etmelidir. Soru şu: hala bir ihtiyacım var VACUUM ANALYZEmı?


Eh, 'hayır' derdim, ama bu cevabı hazırlamak (örneğin, autovacuum parametrelerini ayarlamak) bir kopya DB üzerinde bazı deneylere ihtiyaç duyacaktır.
dezso

Yanıtlar:


32

VACUUM, geçici olmayan tablolarda yalnızca güncellenmiş veya silinmiş satırlarda gereklidir. Açıkçası çok fazla INSERT yapıyorsunuz, ancak çok fazla GÜNCELLEME veya SİLME yaptığınız açıklamasından da belli değil.

Bu işlemler ile takip edilebilir pg_stat_all_tables, özellikle, görünüm n_tup_updve n_tup_delsütunlar. Ayrıca, konuya daha da fazla n_dead_tup, tablo başına, ne kadar satırın temizlenmesi gerektiğini söyleyen bir sütun vardır. (bkz . İstatistik toplama ile ilgili fonksiyonlar ve görüşler için dokümandaki istatistikleri izleme ).

Durumunuzdaki olası bir strateji, planlanan VACUUM'u bastırmak, bu görüşe bakmak ve hangi tabloların n_dead_tupönemli bir şekilde arttığını kontrol etmektir. Ardından agresif VACUUM'u yalnızca bu tablolara uygulayın. Satırları hiç silinmeyen ya da güncellenmeyen büyük masalar varsa ve agresif VACUUM sadece daha küçük masalarda gerçekten gerekliyse, bu bir kazanç olacaktır.

Ancak, optimize edicinin her zaman yeni istatistiklere sahip olması için ANALYZE yazılımını çalıştırmaya devam edin.


4
Autovacuum ayrıca ANALYZE ile de ilgileniyor. Toplu GÜNCELLEME / INSERT / DELETE arasında ve hemen büyük sorguları takip ederek manuel bir ANALİZ yapmak iyi bir fikirdir. Olsa da, iyi tavsiye için + 1.
Erwin Brandstetter

İşaretçinin n_dead_tup ve arkadaşlarına teşekkür ederiz. Binlerce sırayı sık sık (saat başı) yok ettiğim ve yeniden yarattığım toplama tablolarım var. Değerleri kontrol edip uygun bir şekilde programlayacağım. Cevap her zaman "gözlemle, düşün, hareket et" olur :)
François Beausoleil

25

autovacuumSorunuzda ilgilenmeyecek bir şey görmüyorum . Yazma faaliyetlerinizin modeline büyük ölçüde bağlıdır . Haftada 3 milyon yeni satırdan bahsediyorsunuz , ancak INSERT(veya COPY) genellikle masa ve indeks şişirmez. ( autovacuumyalnızca sütun istatistiklerine , görünürlük haritasına ve bazı küçük işlere dikkat etmeniz yeterlidir). UPDATEve DELETEözellikle rastgele satırları hedeflerken, tablonun ve endeks şişmesinin baskın nedenidir. Sorunuzda bunların hiçbirini görmüyorum.

autovacuumUzun bir yol kat etti ve Postgres 9.1 veya daha sonraki sürümlerinde harika bir iş çıkarıyor. autovacuumAyarlara bir göz atardım . Vakum iş yükünüzü etkileme eğilimindeyse, ayrıca "Maliyete Dayalı Vakum Gecikmesine" bakın . Manuel vakumlama nadir bir istisna olmalıdır.

Çok fazla rastgele seçeneğiniz UPDATEvarsa, FILLFACTORSICAK güncellemelerine hemen izin vermek ve ihtiyacını azaltmak için 100'den düşük bir değere ayarlamak isteyebilirsiniz VACUUM. SICAK güncellemeler hakkında daha fazlası:

Ayrıca, geçici tabloların manuel VACUUMve gerekli olduğunu unutmayın ANALYZE. El kitabındanCREATE TABLE alıntı yapıyorum :

Autovacuum cin erişemiyor ve bu nedenle vakum veya geçici tablolar analiz edilemez. Bu sebepten, uygun SQL SQL komutları ile uygun vakum ve analiz işlemleri yapılmalıdır. Örneğin, geçici bir tablo karmaşık sorgularda kullanılacaksa ANALYZE, doldurulduktan sonra geçici tabloda çalışmak akıllıca olacaktır .


6

Otomatik özellikleri kullanmanın veritabanını geniş çalıştırmak yerine en iyisi olduğunu kabul ederken, çoğu durumda tablo başına ayarlama gereklidir.

Vakumu bağlamak ve analiz etmek için postgres tasarım seçimine pek katılmıyorum, çok sayıda ekleme / güncelleme yapan ancak çok az silme işleminin asla analiz edilmediği ve kötü performans göstermeye başladıkları birkaç örnek gördüm.

Çözüm, yoğun olarak kullanılan ve büyük sorgulara maruz kalan masalara girip, bu masaların otomatik analiz ayarlarını, bir veya her gün analiz edildikleri bir noktaya indirmektir.

Otomatik vakum sekmesindeki gui'deki tablo başına ayarlara ulaşabilir ve burada vakumdan bağımsız olarak ayarlayabileceğiniz ayarları analiz edebilirsiniz.

Ayarlar yeniden yapılanmalar tablosunda sonlanır ve sorgu ile görülebilir

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

ve agresif bir analizin örnek bir değeri olabilir

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Tablolarınızın en son ne zaman otomatik analiz sorgusu aldığını görmek için

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;

2
Bunu yapmazsanız ANALYZE, PostgreSQL istatistiklerin değiştiğini nasıl bilecek? Ve bunun ANALYZEuzun zaman alacağını nasıl belirleyebilirsin ? Aynı zamanda, yukarıda bahsettiğiniz GUI'yi açıkça belirtmese de, bu belirli masa başı ayarlarında haklısınız.
dezso,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.