Aracılığıyla paylaş

PostgreSQL için Azure Veritabanı'nda otomatik vakum ayarlama

Bu makalede PostgreSQL için Azure Veritabanı'na yönelik otomatik vakum özelliğine ve veritabanı şişirme ve otomatik vakum engelleyicilerini izlemek için kullanılabilen özellik sorun giderme kılavuzlarına genel bir bakış sağlanmaktadır. Ayrıca veritabanının acil durum veya genel çözümleme durumundan ne kadar uzak olduğunu da bildirir.

Uyarı

Bu makale, PostgreSQL için Azure Veritabanı esnek sunucusunda desteklenen tüm PostgreSQL sürümleri için otomatik vakum ayarlamayı kapsar. Bahsedilen bazı özellikler sürüme özgüdür (16 ve üzeri PostgreSQL sürümleri için vacuum_buffer_usage_limit ve 18 ve üzeri PostgreSQL sürümleri için autovacuum_vacuum_max_threshold).

Otomatik vakum nedir?

Autovacuum, ölü tanımlama listelerini otomatik olarak temizleyen ve istatistikleri güncelleştiren bir PostgreSQL arka plan işlemidir. İki temel bakım görevini otomatik olarak çalıştırarak veritabanı performansının korunmasına yardımcı olur:

  • VACUUM - Ölü demetleri kaldırarak ve bu alanı PostgreSQL tarafından yeniden kullanılabilir olarak işaretleyerek veritabanının dosyalarındaki alanı geri alır. Disk üzerindeki veritabanı dosyalarının fiziksel boyutunu azaltması gerekmez. İşletim sistemine alan döndürmek için, tabloyu yeniden yazan işlemleri kullanın (örneğin, VACUUM FULL veya pg_repack), özel kilitler veya bakım pencereleri gibi ek konuları vardır.
  • ÇÖZÜMLE - PostgreSQL sorgu planlayıcısının verimli yürütme planlarını seçmek için kullandığı tablo ve dizin istatistiklerini toplar.

Otomatik vakum'un düzgün çalıştığından emin olmak için autovacuum sunucu parametresini olarak ONayarlayın. Etkinleştirildiğinde PostgreSQL, bir tabloda VACUUM veya ANALYZE komutunun ne zaman çalıştırılmaya çalışeceğine otomatik olarak karar verir ve veritabanının verimli ve en iyi duruma getirildiğinden emin olur.

Otomatik vakum içleri

Autovacuum, ölü demetleri aramak için sayfaları inceleyerek okur. Hiçbir ölü tümce bulamazsa, autovacuum sayfayı atar. Otomatik vakum, ölü demetleri bulduğunda bunları kaldırır. Maliyet aşağıdaki parametreleri temel alır:

Parametre Description
vacuum_cost_page_hit Disk okuması gerektirmeyen ve zaten ortak arabelleklerde bulunan bir sayfayı okumanın maliyeti. Varsayılan değer 1'dir.
vacuum_cost_page_miss Paylaşılan arabelleklerde olmayan bir sayfayı getirme maliyeti. Varsayılan değer 10'dur.
vacuum_cost_page_dirty İçinde ölü tanımlama kümeleri bulunduğunda sayfaya yazma maliyeti. Varsayılan değer 20'dir.

Otomatik vakumun gerçekleştirdiği çalışma miktarı iki parametreye bağlıdır:

Parametre Description
autovacuum_vacuum_cost_limit Otomatik vakumun tek seferde yaptığı iş miktarı.
autovacuum_vacuum_cost_delay Parametre tarafından autovacuum_vacuum_cost_limit belirtilen maliyet sınırına ulaştıktan sonra otomatik vakumun uykuda kaldığı milisaniye sayısı.

PostgreSQL'in şu anda desteklenen tüm sürümlerinde için varsayılan değer autovacuum_vacuum_cost_limit 200'dür (aslında- 1 olarak ayarlanmıştır ve bu da bunu varsayılan olarak 200 olan normal vacuum_cost_limitdeğerinin değerine eşit hale getirir).

için varsayılan değer autovacuum_vacuum_cost_delay , PostgreSQL sürüm 12 ve sonraki sürümlerinde 2 milisaniyedir (sürüm 11'de 20 milisaniyeydi).

Arabellek kullanım sınırı (PostgreSQL 16+)

PostgreSQL sürüm 16'dan başlayarak, VACUUM, ANALYZE ve autovacuum işlemleri sırasında bellek kullanımını denetlemek için parametresini kullanabilirsiniz vacuum_buffer_usage_limit .

Parametre Description
vacuum_buffer_usage_limit VACUUM, ANALYZE ve otomatik vakum işlemleri için arabellek havuzu boyutunu ayarlar. Bu parametre, bu işlemlerin kullanabileceği paylaşılan arabellek önbelleği miktarını sınırlayarak aşırı bellek kaynağı kullanmalarını önler.

Bu parametre, VACUUM ve autovacuum'un paylaşılan arabelleklerden çok fazla yararlı sayfa çıkarmasını önlemeye yardımcı olur ve bu da bakım işlemleri sırasında genel veritabanı performansını iyileştirebilir. Varsayılan değer genellikle temelinde shared_buffersayarlanır ve vakum performansını normal veritabanı işlemlerinin gereksinimleriyle dengelemek için bunu yapılandırabilirsiniz.

Otomatik vakum için maksimum eşik (PostgreSQL 18+)

PostgreSQL sürüm 18'den itibaren, autovacuum_vacuum_max_threshold parametresini, otomatik vakumu tetikleyen tuple güncellemeleri veya silme işlemleri sayısı için bir üst sınır ayarlamak amacıyla kullanabilirsiniz.

Parametre Description
autovacuum_vacuum_max_threshold Vakumdan önce maksimum tuple güncelleme veya silme sayısını belirler. olarak -1ayarlandığında, maksimum eşik devre dışı bırakılır. Çok büyük tablolarda otomatik vakum tetikleme üzerinde hassas ayarlı denetim için bu parametreyi kullanın.

Bu parametre, varsayılan ölçek faktörü tabanlı tetikleme mekanizması nedeniyle autovacuum'un çalışmadan önce çok uzun süre beklemesine yol açabilecek büyük tablolar için özellikle kullanışlıdır.

Autovacuum her saniye 50 kez (50*20 ms=1000 ms) uyanır. Her uyandığında autovacuum 200 sayfa okur.

Bu, bir saniye içinde otomatik vakum işleminin yapabilecekleri anlamına gelir:

  • Paylaşılan arabelleklerde ölü demetleri olan tüm sayfalar bulunursa yaklaşık 80 MB/Sn [ (200 sayfa/vacuum_cost_page_hit) * sayfa başına 50 * 8 KB]
  • Boş demetleri olan tüm sayfalar diskten okunursa ~ 8 MB/Sn [ (200 sayfa/vacuum_cost_page_miss) * 50 * sayfa başına 8 KB] .
  • ~4 MB/Sn [ (200 sayfa/vacuum_cost_page_dirty) * 50 * sayfa başına 8 KB] otomatik vakum 4 MB/sn'ye kadar yazabilir.

Otomatik vakumu izleme

PostgreSQL için Azure Veritabanı, otomatik vakumu izlemek için aşağıdaki ölçümleri sağlar.

Otomatik vakum ölçümleri, PostgreSQL için Azure Veritabanı esnek sunucusunun otomatik vakum performansını izlemek ve ayarlamak için kullanılabilir. Her ölçüm 30 dakikalık bir aralıkta yayılır ve 93 güne kadar bekletme süresine sahiptir. Belirli ölçümler için uyarılar oluşturabilir ve ölçüm verilerini boyut kullanarak DatabaseName bölebilir ve filtreleyebilirsiniz.

Otomatik vakum ölçümlerini etkinleştirme

  • Otomatik vakum ölçümleri varsayılan olarak devre dışı bırakılır.
  • Bu ölçümleri etkinleştirmek için sunucu parametresini metrics.autovacuum_diagnostics olarak ONayarlayın.
  • Bu parametre dinamik olduğundan örnek yeniden başlatması gerekmez.

Otomatik vakum ölçümleri listesi

Ekran adı Metri̇k Kimlik Birim Description Boyut Varsayılan etkin
Karşı Kullanıcı Tablolarını Analiz Et analyze_count_user_tables Sayı Bu veritabanında yalnızca kullanıcı tarafından yönetilen tabloların el ile çözümlenme sayısı. DatabaseName Hayı
Sayaç Kullanıcı Tablolarını Otomatik Olarak Analiz Etme autoanalyze_count_user_tables Sayı Bu veritabanında autovacuum daemon tarafından analiz edilen yalnız kullanıcıya ait tabloların sayısı. DatabaseName Hayı
AutoVacuum Sayacı Kullanıcı Tabloları autovacuum_count_user_tables Sayı Bu veritabanında autovacuum daemon tarafından vakumlanan yalnızca kullanıcıya özel tabloların sayısı. DatabaseName Hayı
Şişme Yüzdesi (Önizleme) bloat_percent Percent Yalnızca kullanıcı tabloları için tahmini şişme yüzdesi. DatabaseName Hayı
Tahmini Ölü Satır Kullanıcı Tabloları n_dead_tup_user_tables Sayı Bu veritabanındaki yalnızca kullanıcı tabloları için tahmini ölü satır sayısı. DatabaseName Hayı
Kullanıcı Tabloları için Tahmini Aktif Satır Sayısı n_live_tup_user_tables Sayı Bu veritabanındaki yalnızca kullanıcı tabloları için tahmini etkin satır sayısı. DatabaseName Hayı
Tahmini Değişiklikler Kullanıcı Tabloları n_mod_since_analyze_user_tables Sayı Yalnızca kullanıcı tabloları en son analiz edildikten sonra değiştirilen tahmini satır sayısı. DatabaseName Hayı
Çözümlenen Kullanıcı Tabloları tables_analyzed_user_tables Sayı Bu veritabanında analiz edilen yalnızca kullanıcı tarafından yönetilen tabloların sayısı. DatabaseName Hayı
Kullanıcı Tabloları Otomatik Olarak Analiz Edildi tables_autoanalyzed_user_tables Sayı Bu veritabanındaki autovacuum daemon tarafından analiz edilen yalnızca kullanıcı tarafından oluşturulan tabloların sayısı. DatabaseName Hayı
Otomatik Olarak Boşaltılan Kullanıcı Tabloları tables_autovacuumed_user_tables Sayı Bu veritabanında autovacuum daemon tarafından vakumlanan kullanıcıya özel tabloların sayısı. DatabaseName Hayı
Kullanıcı Tabloları Sayacı tables_counter_user_tables Sayı Kullanıcıya özel tabloların bu veritabanındaki sayısı. DatabaseName Hayı
Vakumlanmış Kullanıcı Tabloları tables_vacuumed_user_tables Sayı Bu veritabanında vakumlanmış kullanıcıya ait tabloların sayısı. DatabaseName Hayı
Vakum Sayacı Kullanıcı Tabloları vacuum_count_user_tables Sayı Bu veritabanında yalnızca kullanıcı tarafından kullanılan tabloların el ile vakumlanma sayısı (sayılmıyor VACUUM FULL). DatabaseName Hayı

Otomatik vakum ölçümlerini kullanma konusunda dikkat edilmesi gerekenler

  • DatabaseName boyutunu kullanan otomatik vakum ölçümlerinin 30 veritabanı sınırı vardır.
  • Esnek Tıkanabilir SKU'da, DatabaseName boyutunu kullanan ölçümler için 10 veritabanı sınırı vardır.
  • Veritabanı için oluşturma sırasını yansıtan OID sütununa DatabaseName boyut sınırı uygulanır.

Daha fazla bilgi için bkz. Otomatik Vakum Ölçümleri.

Otomatik vakumu izlemek için aşağıdaki sorguları kullanın:

select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;

Aşağıdaki sütunlar, autovacuum'un tablo etkinliğini yakalayıp yakalamadığını belirlemenize yardımcı olur:

Parametre Description
dead_pct Canlı demetlerle karşılaştırıldığında ölü demetlerin yüzdesi.
last_autovacuum Tablonun en son otomatik vakumlandığı tarih.
last_autoanalyze Tablonun otomatik olarak en son çözümlendiği tarih.

Otomatik vakum tetikleniyor

Ölü tupl sayısı belirli bir sayıyı aştığında otomatik vakum eylemi (ANALYZE veya VACUUM) tetiklenir. Bu sayı iki faktöre bağlıdır: tablodaki satırların toplam sayısı ve sabit bir eşik. Tablonun %10'u artı 50 satır değişikliği gerçekleştiğinde ÇÖZÜMLE ve tablonun %20'si artı 50 satır değişikliği olduğunda VACUUM varsayılan olarak tetiklenir. VAKUM eşiği, ÇÖZÜMLE eşiğinin iki katı olduğundan, ÇÖZÜMLE işlemi VACUUM'tan önce tetikler.

PostgreSQL sürüm 13 ve üzeri için, tablonun 20% artı 1.000 satır ekleme işlemi gerçekleştiğinde ANALIZ tetikleyicileri varsayılan olarak tetikler.

Her eylemin tam denklemleri şunlardır:

  • Autoanalyze = autovacuum_analyze_scale_factor * tanımlama kümeleri + autovacuum_analyze_threshold veya autovacuum_vacuum_insert_scale_factor * tanımlama kümeleri + autovacuum_vacuum_insert_threshold (PostgreSQL sürüm 13 ve üzeri için)
  • Autovacuum = autovacuum_vacuum_scale_factor * tanımlama demetleri + autovacuum_vacuum_threshold

Örneğin, 100 satırı olan bir tablonuz varsa analiz ve vakum eylemlerinin tetiklendiğinde aşağıdaki denklemler gösterilir:

Güncelleştirmeler ve silmeler için: Autoanalyze = 0.1 * 100 + 50 = 60Autovacuum = 0.2 * 100 + 50 = 70

Bir tabloda 60 satır değiştirildikten sonra ANALYZE tetiklenir ve 70 satır değiştirildiğinde VACUUM tetiklenir.

Eklemeler için: Autoanalyze = 0.2 * 100 + 1000 = 1020

Tabloya 1.020 satır eklendikten sonra ANALİZ ET tetiklenir.

Denklemde kullanılan parametrelerin açıklaması aşağıdadır:

Parametre Description
autovacuum_analyze_scale_factor Tabloda ÇÖZÜMLE'yi tetikleyen eklemelerin, güncelleştirmelerin ve silmelerin yüzdesi.
autovacuum_analyze_threshold Tablonun analiz edilmesi için eklenen, güncellenen veya silinen en az demet sayısı.
autovacuum_vacuum_insert_scale_factor Tabloda ANALİZ işlemini tetikleyen eklemelerin yüzdesi.
autovacuum_vacuum_insert_threshold Bir tabloyu ANALİZ ETMEK için yerleştirilen en az demet sayısı.
autovacuum_vacuum_scale_factor Tabloda VACUUM'yi tetikleyen güncelleştirmelerin ve silmelerin yüzdesi.

Veritabanındaki tabloları listelemek ve otomatik vakum işlemine uygun tabloları tanımlamak için aşağıdaki sorguyu kullanın:

 SELECT *
      ,n_dead_tup > av_threshold AS av_needed
      ,CASE
        WHEN reltuples > 0
          THEN round(100.0 * n_dead_tup / (reltuples))
        ELSE 0
        END AS pct_dead
    FROM (
      SELECT N.nspname
        ,C.relname
        ,pg_stat_get_tuples_inserted(C.oid) AS n_tup_ins
        ,pg_stat_get_tuples_updated(C.oid) AS n_tup_upd
        ,pg_stat_get_tuples_deleted(C.oid) AS n_tup_del
        ,pg_stat_get_live_tuples(C.oid) AS n_live_tup
        ,pg_stat_get_dead_tuples(C.oid) AS n_dead_tup
        ,C.reltuples AS reltuples
        ,round(current_setting('autovacuum_vacuum_threshold')::INTEGER + current_setting('autovacuum_vacuum_scale_factor')::NUMERIC * C.reltuples) AS av_threshold
        ,date_trunc('minute', greatest(pg_stat_get_last_vacuum_time(C.oid), pg_stat_get_last_autovacuum_time(C.oid))) AS last_vacuum
        ,date_trunc('minute', greatest(pg_stat_get_last_analyze_time(C.oid), pg_stat_get_last_autoanalyze_time(C.oid))) AS last_analyze
      FROM pg_class C
      LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
      WHERE C.relkind IN (
          'r'
          ,'t'
          )
        AND N.nspname NOT IN (
          'pg_catalog'
          ,'information_schema'
          )
        AND N.nspname !~ '^pg_toast'
      ) AS av
    ORDER BY av_needed DESC ,n_dead_tup DESC;

Uyarı

Sorgu, "alter table" DDL komutunu kullanarak tablo başına temelinde otomatik vakum yapılandırabileceğinizi dikkate almaz.

Yaygın otomatik vakum sorunları

Otomatik vakum işlemiyle ilgili yaygın sorunların listesini gözden geçirin.

Meşgul sunucuya ayak uydurmuyor

Otomatik vakum işlemi her G/Ç işleminin maliyetini tahmin eder, gerçekleştirdiği her işlem için bir toplam biriktirir ve maliyetin üst sınırına ulaşıldıktan sonra duraklatılır. İşlem iki sunucu parametresi kullanır: autovacuum_vacuum_cost_delay ve autovacuum_vacuum_cost_limit.

Varsayılan olarak - autovacuum_vacuum_cost_limit 1 olarak ayarlanır, yani otomatik vakum maliyet sınırı parametresiyle vacuum_cost_limit aynı değeri kullanır. için vacuum_cost_limit varsayılan değer 200'dür. vacuum_cost_limit el ile vakum maliyetini temsil eder.

-1 olarak ayarlarsanız autovacuum_vacuum_cost_limit , autovacuum parametresini vacuum_cost_limit kullanır. -1'den büyük bir değere ayarlarsanız autovacuum_vacuum_cost_limit , otomatik vakum parametresini autovacuum_vacuum_cost_limit kullanır.

Otomatik vakum ayak uydurmuyorsa aşağıdaki parametreleri değiştirmeyi göz önünde bulundurun:

Parametre Description
autovacuum_vacuum_cost_limit Varsayılan: 200. Maliyet sınırını artırabilirsiniz. Değişiklik yapmadan önce ve sonra veritabanında CPU ve G/Ç kullanımını izleyin.
autovacuum_vacuum_cost_delay PostgreSQL Sürüm 12 ve üzeri - Varsayılan: 2 ms. Daha agresif otomatik vakum için bu değeri azaltabilirsiniz.
vacuum_buffer_usage_limit PostgreSQL Sürüm 16 ve üzeri - VACUUM ve otomatik vakum işlemleri için arabellek havuzu boyutunu ayarlar. Bu parametrenin ayarlanması, vakum işlemleri sırasında ne kadar paylaşılan arabellek önbelleği kullanıldığını denetleyerek otomatik vakum performansını genel sistem performansıyla dengelemeye yardımcı olabilir.

Uyarı

  • Değer autovacuum_vacuum_cost_limit , çalışan otomatik vakum çalışanları arasında orantılı olarak dağıtılır. Birden fazla çalışan varsa, her çalışan için sınırların toplamı parametrenin autovacuum_vacuum_cost_limit değerini aşmaz.
  • autovacuum_vacuum_scale_factor , ölü tuple birikimine göre bir tablo üzerinde vakumu tetikleyebilen başka bir parametredir. Varsayılan: 0.2, İzin verilen aralık: 0.05 - 0.1. Ölçek faktörü iş yüküne özgüdür ve tablolardaki veri miktarına bağlı olarak ayarlanmalıdır. Değeri değiştirmeden önce iş yükünü ve tek tek tablo birimlerini araştırın.

Otomatik vakum sürekli çalışıyor

Otomatik vakum sürekli çalışıyorsa, sunucudaki CPU ve G/Ç kullanımını etkileyebilir. Bazı olası nedenler şunlardır:

maintenance_work_mem

Autovacuum daemon, varsayılan olarak autovacuum_work_mem ayarlanmış olan -1 öğesini kullanır. Bu varsayılan ayar, autovacuum_work_mem'ın maintenance_work_mem parametresiyle aynı değeri kullandığı anlamına gelir. Bu makalede autovacuum_work_mem'ın -1 olarak ayarlandığı ve autovacuum daemon'un maintenance_work_mem kullandığı varsayılır.

Eğer maintenance_work_mem düşükse, bunu PostgreSQL için Azure Veritabanı esnek sunucu örneğinde 2 GB'a kadar artırabilirsiniz. Genel bir kural, her 1 GB RAM için 50 MB maintenance_work_mem ayırmaktır.

Çok sayıda veritabanı

Autovacuum her veritabanında her autovacuum_naptime saniye bir çalışan başlatmaya çalışır.

Örneğin, bir sunucunun 60 veritabanı varsa ve autovacuum_naptime 60 saniye olarak ayarlandıysa, otomatik vakum çalışanı her saniye başlar [autovacuum_naptime/Veritabanı sayısı].

Kümedeki veritabanı sayısı fazlaysa, autovacuum_naptime değerini artırın. Otomatik vakum işlemini daha agresif hale getirmek için aynı zamanda autovacuum_cost_limit parametresini artırıp autovacuum_cost_delay parametresini azaltın. Varsayılan değer olan 3'ten 4'e veya 5'e de artırabilirsiniz autovacuum_max_workers .

Yetersiz bellek hataları

Aşırı agresif maintenance_work_mem değerler düzenli aralıklarla sistemde yetersiz bellek hatalarına neden olabilir. Parametresini değiştirmeden önce sunucudaki kullanılabilir RAM'i maintenance_work_mem anlayın.

Otomatik vakum çok kesintiye neden oluyor

Otomatik vakum çok fazla kaynak kullanıyorsa aşağıdaki eylemleri deneyin:

Otomatik vakum parametreleri

, autovacuum_vacuum_cost_delayve autovacuum_vacuum_cost_limitparametrelerini autovacuum_max_workersdeğerlendirin. Otomatik vakum parametrelerinin yanlış ayarlanması, otomatik vakum işleminin çok kesintiye neden olduğu senaryolara yol açabilir.

Otomatik vakum çok kesintiye neden oluyorsa aşağıdaki eylemleri göz önünde bulundurun:

  • Varsayılan değer olan 200'den yüksek ayarlarsanız artırın autovacuum_vacuum_cost_delay ve azaltın autovacuum_vacuum_cost_limit .
  • autovacuum_max_workers sayısını, varsayılan ayar olan 3'ten daha yüksek bir değere ayarladıysanız azaltın.

Çok fazla otomatik vakum çalışanı

Otomatik vakum işçilerinin sayısının artırılması vakum hızını artırmaz. Çok fazla sayıda otomatik vakum işçisi kullanmayın.

Otomatik vakum çalışanlarının sayısının artırılması daha fazla bellek tüketimine neden olur. değerine maintenance_work_membağlı olarak performans düşüşlerine neden olabilir.

Her otomatik vakum çalışan işlemi toplamın autovacuum_cost_limityalnızca (1/autovacuum_max_workers) değerini alır, bu nedenle çok fazla sayıda çalışanın olması her birinin yavaş olmasına neden olur.

çalışan sayısını artırırsanız, vakum işlemini daha hızlı hale getirmek için artırın autovacuum_vacuum_cost_limit ve/veya azaltın autovacuum_vacuum_cost_delay .

Ancak, parametreyi tablo düzeyinde autovacuum_vacuum_cost_delay veya parametrelerde autovacuum_vacuum_cost_limit ayarlarsanız, bu tablolarda çalışan işçiler dengeleme algoritmasında [autovacuum_cost_limit/autovacuum_max_workers] dikkate alınmaz.

Otomatik vakum işlem kimliği (TXID) sarmalama koruması

Veritabanı işlem kimliği sarmalama korumasıyla çalıştığında aşağıdaki hataya benzer bir hata iletisi görürsünüz:

Database isn't accepting commands to avoid wraparound data loss in database 'xx'
Stop the postmaster and vacuum that database in single-user mode.

Uyarı

Bu hata iletisi uzun süredir devam eden bir gözetimdir. Genellikle tek kullanıcı moduna geçmeniz gerekmez. Bunun yerine, gerekli VACUUM komutlarını çalıştırabilir ve VACUUM işleminin hızlı çalışması için ayarlama yapabilirsiniz. Herhangi bir veri işleme dili (DML) çalıştıramazsınız ancak VACUUM'u yine de çalıştırabilirsiniz.

Sarmalama sorunu, veritabanı vakumlanmadığında veya otomatik vakum işlemi çok fazla ölü kayıt kaldırmadığında oluşur.

Bu sorunun olası nedenleri şunlardır:

Ağır iş yükü

Ağır bir iş yükü kısa bir süre içinde çok fazla sayıda ölü tuple'a neden olur ve bu da autovacuum'un yetişmesini zorlaştırır. Sistemdeki ölü tanımlama kümeleri, sorgu performansının düşmesine ve sarmalama durumuna yol açan bir süre boyunca bir araya geliyor. Bu durumun ortaya çıkması için bir neden, otomatik vakum parametrelerinin yeterince ayarlanmaması ve meşgul bir sunucuya ayak uyduramaması olabilir.

Uzun süre çalışan işlemler

Sistemdeki uzun süredir çalışan işlemler, otomatik vakumun ölü tupleri kaldırmasına izin vermez. Vakum işlemine engel olurlar. Uzun süre çalışan işlemlerin kaldırılması, otomatik vakum çalıştırıldığında silinmek üzere ölü demetleri boşaltıyor.

Uzun süre çalışan işlemler aşağıdaki sorgu kullanılarak algılanabilir:

    SELECT pid, age(backend_xid) AS age_in_xids,
    now () - xact_start AS xact_age,
    now () - query_start AS query_age,
    state,
    query
    FROM pg_stat_activity
    WHERE state != 'idle'
    ORDER BY 2 DESC
    LIMIT 10;

Hazırlanmış deyimler

Taahhüt edilmemiş önceden hazırlanmış deyimler varsa, otomatik vakumun ölü tuple'ları kaldırmasını engeller. Aşağıdaki sorgu, kaydedilmemiş hazırlanmış deyimlerin bulunmasına yardımcı olur:

    SELECT gid, prepared, owner, database, transaction
    FROM pg_prepared_xacts
    ORDER BY age(transaction) DESC;

Bu deyimleri işlemek veya COMMIT geri almak için PREPARED veya PREPARED kullanınROLLBACK.

Kullanılmayan çoğaltma yuvaları

Kullanılmayan çoğaltma yuvaları, otomatik vakum işleminin ölü tanımlama demetleri talep etmesini engeller. Aşağıdaki sorgu kullanılmayan çoğaltma yuvalarını tanımlamaya yardımcı olur:

    SELECT slot_name, slot_type, database, xmin
    FROM pg_replication_slots
    ORDER BY age(xmin) DESC;

Kullanılmayan çoğaltma yuvalarını silmek için kullanın pg_drop_replication_slot() .

Veritabanı işlem kimliği sarmalama korumasıyla çalıştığında, daha önce belirtildiği gibi engelleyicileri denetleyin ve otomatik vakum işleminin devam etmesi ve tamamlanması için engelleyicileri el ile kaldırın. Otomatik vakum hızını 0 olarak ayarlayıp autovacuum_cost_delay değerini 200'den büyük bir değere yükselterek de artırabilirsiniz autovacuum_cost_limit . Ancak, bu parametrelerde yapılan değişiklikler mevcut otomatik vakum çalışanları için geçerli değildir. Parametre değişikliklerini uygulamak için veritabanını yeniden başlatın veya mevcut çalışanları el ile öldürün.

Tabloya özgü gereksinimler

Tek tek tablolar için otomatik vakum parametreleri ayarlayabilirsiniz. Bu ayarlar özellikle küçük ve büyük tablolar için önemlidir. Örneğin, yalnızca 100 satır içeren küçük bir tablo için otomatik vakum, 70 satır değiştiğinde (daha önce hesaplandığında) VACUUM işlemini tetikler. Bu tabloyu sık sık güncelleştirdiyseniz, günde yüzlerce otomatik vakum işlemi görebilirsiniz. Bu işlemler, otomatik vakumun değişiklik yüzdesinin o kadar önemli olmadığı diğer tabloları korumasını engeller. Alternatif olarak, bir milyar satır içeren bir tablonun otomatik vakum işlemlerini tetikleyebilmesi için 200 milyon satırı değiştirmesi gerekir. Otomatik vakum parametrelerinin uygun şekilde ayarlanması bu tür senaryoları önler.

Her tablonun otomatik vakum ayarlarını ayarlamak için aşağıdaki örneklerde gösterildiği gibi sunucu parametrelerini değiştirin:

    ALTER TABLE <table name> SET (autovacuum_analyze_scale_factor = xx);
    ALTER TABLE <table name> SET (autovacuum_analyze_threshold = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_scale_factor = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_threshold = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_cost_delay = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_cost_limit = xx);
    -- For PostgreSQL 16 and later:
    ALTER TABLE <table name> SET (vacuum_buffer_usage_limit = 'xx MB');

Yalnızca ekleme iş yükleri

PostgreSQL sürüm 13 ve önceki sürümlerinde, yalnızca ekleme iş yüküne sahip tablolarda ölü tanım kümeleri ve geri alınması gereken boş alan olmadığı için otomatik vakum çalışmaz. Ancak, yeni veriler olduğundan otomatik analiz yalnızca ekleme iş yükleri için çalışır. Bu davranışın dezavantajları şunlardır:

  • Tabloların görünürlük haritası güncelleştirilmez ve bu nedenle özellikle Yalnızca Dizin Taramalarının bulunduğu durumlarda sorgu performansı zaman içinde acı çekmeye başlar.
  • Veritabanı işlem kimliği sarmalama korumasıyla çalıştırılabilir.
  • İpucu bitleri ayarlanmadı.

Solutions

PostgreSQL sürüm 13 ve öncesi

pg_cron uzantısını kullanarak, tabloda periyodik vakum analizi zamanlamak için bir cron işi ayarlayabilirsiniz. Cron işinin sıklığı iş yüküne bağlıdır.

Yönergeler için bkz. PostgreSQL için Azure Veritabanı'nda pg_cron kullanmayla ilgili önemli noktalar.

PostgreSQL 13 ve sonraki sürümleri

Otomatik vakum, yalnızca ekleme iş yüküne sahip tablolarda çalışır. İki sunucu parametresi, autovacuum_vacuum_insert_threshold ve autovacuum_vacuum_insert_scale_factor, yalnızca ekleme tablolarında otomatik vakumun ne zaman tetiklenebileceğini kontrol etmeye yardımcı olur.

Sorun giderme kılavuzları

PostgreSQL için Azure Veritabanı esnek sunucusu, portalda veritabanındaki veya tek şema düzeyindeki şişkinliği izlemenize ve otomatik vakum işlemine yönelik olası engelleyicileri belirlemenize yardımcı olan sorun giderme kılavuzları sağlar.

İki sorun giderme kılavuzu mevcuttur:

  • Autovacuum takibi - Veritabanı veya tek tek şema düzeyinde şişkinliği izlemek için bu kılavuzu kullanın.
  • Otomatik vakum engelleyicileri ve sarmalama - Bu kılavuz olası otomatik vakum engelleyicilerini belirlemenize yardımcı olur ve sunucudaki veritabanlarının sarmalama veya acil durumlara ne kadar uzak olduğu hakkında bilgi sağlar.

Sorun giderme kılavuzları olası sorunları azaltmak için önerileri de paylaşır. Sorun giderme kılavuzlarını ayarlama ve kullanma hakkında bilgi için sorun giderme kılavuzlarını ayarlama bölümüne bakın.

Otomatik vakum işlemini sonlandırma: pg_signal_autovacuum_worker rolü

Otomatik vakum, veritabanında verimli depolama ve performans bakımına yardımcı olduğundan önemli bir arka plan işlemidir. Normal otomatik vakum işleminde, deadlock_timeout sonrasında kendisini iptal eder. Bir kullanıcı, bir tabloda DDL deyimi yürütürse, kullanıcı belirlenen deadlock_timeout süreye kadar beklemek zorunda kalabilir. Autovacuum, farklı bağlantı istekleri tarafından istenen tabloda okuma veya yazma işlemlerinin yürütülmesine izin vermez ve işlemdeki gecikme süresine eklenir.

PostgreSQL'den, devam eden bir otomatik vakum görevini sonlandırmak için kullanamayan üyelerin izin verdiği yeni bir rol pg_signal_autovacuum_worker kullanıma sunulmuştur. Yeni rol, kullanıcıların otomatik vakum işlemine güvenli ve denetimli erişim elde etmelerine yardımcı olur. Süper kullanıcı olmayanlar, pg_signal_autovacuum_worker rolü verildikten sonra, pg_terminate_backend komutunu kullanarak autovacuum işlemini iptal edebilir. Rol pg_signal_autovacuum_worker , PostgreSQL sürüm 15 ve sonraki sürümlerde PostgreSQL için Azure Veritabanı'nda kullanılabilir.

Nadir senaryolarda, sarmalamayı önleyen otomatik vakumda olduğu gibi, çalışanlar, işlem kimliği tükenmesini önlemekte kritik rol oynadıkları için sonlandırıldıktan hemen sonra yeniden başlatılabilir. Yinelenen çakışmaları en aza indirmek için şu adımları izleyin:

  • Sonlandırmadan önce DDL işlemini sıraya alın.

    • Oturum 1: DDL ifadesini hazırlayıp çalıştırın.

    • Oturum 2: Otomatik vakum işlemini sonlandırın.

      Önemli

      Bu iki adım arka arkaya yürütülmelidir. DDL deyimi çok uzun süre engellenmiş durumda kalırsa, kilitleri tutabilir ve sunucudaki diğer DML işlemlerini engelleyebilir.

  • Otomatik vakumu sonlandırın ve DDL'yi yürütin: DDL'nin hemen çalıştırılması gerekiyorsa:

    • pg_terminate_backend() kullanarak otomatik vakum işlemini sonlandırın.
    • Sonlandırmadan hemen sonra DDL komutunu çalıştırın.

Yinelenen çakışmaları önleme adımları:

  1. Kullanıcıya rol verme

    GRANT pg_signal_autovacuum_worker TO app_user;
    1. Otomatik vakum işlem kimliğini belirleme
    SELECT pid, query FROM pg_stat_activity WHERE query LIKE '%autovacuum%' and pid!=pg_backend_pid();

  2. Otomatik vakumu sonlandır

    SELECT pg_terminate_backend(<pid>);

  3. DDL deyimini hemen yürüt

    ALTER TABLE my_table ADD COLUMN new_col TEXT;

Uyarı

Devam eden otomatik vakum işlemlerini sonlandırmanızı önermiyoruz çünkü bunu yapmak tablo ve veritabanı şişkinliğiyle sonuçlanabilir ve bu da performans regresyonlarına yol açabilir. Ancak, otomatik vakum işlemiyle çakışan bir DDL deyiminin zamanlanmış yürütülmesini içeren iş açısından kritik bir gereksinim olduğunda, süper kullanıcı olmayanlar pg_signal_autovacuum_worker rolü kullanarak autovacuum işlemini denetimli ve güvenli bir şekilde sonlandırabilir.

Azure Danışmanı önerileri

Azure Danışmanı önerileri, bir sunucunun yüksek blob oranına sahip olup olmadığını veya sunucunun bir işlem sarmalama senaryosuna yaklaştığını proaktif olarak belirler. Öneriler için Azure Danışmanı uyarıları da oluşturabilirsiniz.

Öneriler şunlardır:

  • Yüksek şişkinlik oranı: Yüksek bir şişkinlik oranı, sunucu performansını çeşitli şekillerde etkileyebilir. Önemli bir sorun, PostgreSQL Altyapısı İyileştiricisi'nin en iyi yürütme planını seçmekte zorlanabilir ve bu da sorgu performansının düşmesine neden olabilir. Bu nedenle, bir sunucudaki şişkinlik yüzdesi bu tür performans sorunlarını önlemek için belirli bir eşiğe ulaştığında bir öneri tetiklenir.

  • İşlem sarmalama: Bu senaryo, bir sunucunun karşılaşabileceği en ciddi sorunlardan biridir. Sunucunuz bu duruma geldikten sonra daha fazla işlem kabul etmeyi durdurarak sunucunun salt okunur olmasına neden olabilir. Bu nedenle, sunucu 1 milyar işlem eşiğini aştığında bir öneri tetiklenir.

İlgili içerik

  • Last updated on