Aracılığıyla paylaş

PostgreSQL için Azure Veritabanı - Esnek Sunucuda otomatik vakum ayarlama

  • Makale

ŞUNLAR IÇIN GEÇERLIDIR: PostgreSQL için Azure Veritabanı - Esnek Sunucu

Bu makalede, PostgreSQL için Azure Veritabanı esnek sunucu için otomatik vakum özelliğine genel bir bakış ve veritabanı şişkinliği, otomatik vakum engelleyicilerini izlemek için kullanılabilen özellik sorun giderme kılavuzları sunulmaktadır. Ayrıca veritabanının acil durum veya sarmalama durumundan ne kadar uzak olduğuna ilişkin bilgiler de sağlar.

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 disk alanını boşaltın.
  • ÇÖZÜMLE - PostgreSQL İyileştiricisi'nin sorgular için en iyi yürütme yollarını seçmesine yardımcı olmak için istatistikleri toplar.

Otomatik vakum'un düzgün çalıştığından emin olmak için autovacuum sunucu parametresi her zaman ON olarak ayarlanmalıdır. 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 arayan sayfaları okur ve hiçbiri bulunmazsa, otomatik vakum sayfayı atar. Otomatik vakum, ölü demetleri bulduğunda bunları kaldırır. Maliyet aşağıdakilere bağlıdır:

Parametre Açıklama
vacuum_cost_page_hit Zaten paylaşılan arabelleklerde bulunan ve disk okuması gerektirmeyen bir sayfayı okuma maliyeti. Varsayılan değer 1 olarak ayarlanır.
vacuum_cost_page_miss Paylaşılan arabelleklerde olmayan bir sayfayı getirme maliyeti. Varsayılan değer 10 olarak ayarlanır.
vacuum_cost_page_dirty İçinde ölü tanımlama kümeleri bulunduğunda sayfaya yazma maliyeti. Varsayılan değer 20 olarak ayarlanır.

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

Parametre Açıklama
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ı.

Postgres'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; bu da normal vacuum_cost_limitdeğerinin değerine eşit olmasını sağlar ve varsayılan olarak 200'dür).

autovacuum_vacuum_cost_delayolarak, Postgres sürüm 11'de varsayılan olarak 20 milisaniyeye, Postgres sürüm 12 ve üzeri sürümlerde ise varsayılan olarak 2 milisaniyedir.

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

Bu, bir saniyelik otomatik vakumda aşağıdakileri yapabileceğiniz 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

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ı belirlemeye yardımcı olur:

Parametre Açıklama
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.

PostgreSQL otomatik vakumu ne zaman tetikler?

Ölü tanımlama grubu sayısı iki faktöre bağımlı olan belirli bir sayıyı aştığında otomatik vakum eylemi ( ÇÖZÜMLE veya VAKUM) tetikler: tablodaki satırların toplam sayısı ve sabit bir eşik. ÇÖZÜMLE, varsayılan olarak tablonun %10'una ek olarak 50 satır değiştiğinde tetikler, VACUUM ise tablonun %20'sine ek olarak 50 satır değiştiğinde tetikler. VACUUM eşiği, ÇÖZÜMLE eşiğinin iki katı olduğundan, ÇÖZÜMLE işlemi VACUUM'tan daha erken tetiklenir. PG sürümleri >için =13; Varsayılan olarak ÇÖZÜMLE , tablonun %20'sine ek olarak 1000 satır eklendiğinde tetikler.

Her eylemin tam denklemleri şunlardır:

  • Otomatik analiz = 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 (PG sürümleri >için = 13)
  • Autovacuum = autovacuum_vacuum_scale_factor * tanımlama demetleri + autovacuum_vacuum_threshold

Örneğin, 100 satırlı bir tablomuz varsa. Aşağıdaki denklem daha sonra analiz ve vakum tetiklendiğinde ilgili bilgileri sağlar:

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

Tabloda 60 satır değiştirildikten sonra tetikleyicileri analiz edin ve bir tabloda 70 satır değiştirildiğinde Vakum tetikleyicileri tetikler.

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

Tabloya 1.020 satır eklendikten sonra tetikleyicileri analiz etme

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

Parametre Açıklama
autovacuum_analyze_scale_factor Tabloda ANALYZE'yi tetikleyen ekleme/güncelleştirme/silme işlemleri yüzdesi.
autovacuum_analyze_threshold Tabloyu ÇÖZÜMLEMEk için eklenen/güncelleştirilen/silinen en az demet sayısını belirtir.
autovacuum_vacuum_insert_scale_factor Tabloda ANLYZE'yi tetikleyen eklemelerin yüzdesi.
autovacuum_vacuum_insert_threshold Bir tabloyu ÇÖZÜMLE'ye eklenen en az tanımlama grubu sayısını belirtir.
autovacuum_vacuum_scale_factor Tabloda VACUUM'yi tetikleyen güncelleştirmelerin/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;

Not

Sorgu, otomatik vakum işleminin "alter table" DDL komutu kullanılarak tablo başına yapılandırılabilmesini dikkate almaz.

Yaygın otomatik vakum sorunları

Otomatik vakum işlemiyle ilgili olası 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. autovacuum_vacuum_cost_delay ve autovacuum_vacuum_cost_limit işlemde kullanılan iki sunucu parametresidir.

Varsayılan olarak – autovacuum_vacuum_cost_limit 1 olarak ayarlanır, yani otomatik vakum maliyet sınırı parametresiyle vacuum_cost_limitaynı değerdir ve varsayılan değer 200'dür. vacuum_cost_limit el ile vakum maliyetidir.

olarak ayarlanırsa autovacuum_vacuum_cost_limit -1, autovacuum parametresini vacuum_cost_limit kullanır, ancak kendisi o tarihten autovacuum_vacuum_cost_limit -1 büyük olarak ayarlanırsa autovacuum_vacuum_cost_limit parametre dikkate alınır.

Otomatik vakum ayak uydurmuyorsa aşağıdaki parametreler değiştirilebilir:

Parametre Açıklama
autovacuum_vacuum_cost_limit Varsayılan: 200. Maliyet sınırı artırılabilir. Değişiklik yapmadan önce ve sonra veritabanındaki CPU ve G/Ç kullanımı izlenmelidir.
autovacuum_vacuum_cost_delay Postgres Sürüm 11 - Varsayılan: 20 ms. parametresi olarak 2-10 msazaltılabilir.
Postgres Sürüm 12 ve üzeri - Varsayılan: 2 ms.

Not

  • Değer autovacuum_vacuum_cost_limit , çalışan otomatik vakum çalışanları arasında orantılı olarak dağıtılır, böylece 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ü tanımlama grubu birikimine göre bir tabloda vakumu tetikleyebilecek 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

Sürekli çalışan otomatik vakum, sunucudaki CPU ve GÇ kullanımını etkileyebilir. Olası nedenlerden bazıları şunlardır:

maintenance_work_mem

Autovacuum daemon varsayılan olarak anlamı autovacuum_work_mem parametresiyle aynı değere maintenance_work_mem-1 sahip olacak şekilde ayarlanmış olan kullanırautovacuum_work_mem. Bu belgede autovacuum daemon'una ayarlandığı -1 ve maintenance_work_mem kullanıldığı varsayılırautovacuum_work_mem.

Düşüksemaintenance_work_mem, esnek PostgreSQL için Azure Veritabanı sunucuda 2 GB'a kadar artırılabilir. 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ümede daha fazla veritabanı varsa artırmak autovacuum_naptime iyi bir fikirdir. Aynı zamanda, parametreleri artırıp autovacuum_cost_limit azaltarak ve varsayılan değer olan 3'ten 4 veya 5'e çıkarılarak autovacuum_cost_delay autovacuum_max_workers otomatik vakum işlemi daha agresif hale getirilebilir.

Yetersiz bellek hataları

Aşırı agresif maintenance_work_mem değerler düzenli aralıklarla sistemde yetersiz bellek hatalarına neden olabilir. Parametrede herhangi bir değişiklik maintenance_work_mem yapılmadan önce sunucuda kullanılabilir RAM'in anlaşılması önemlidir.

Otomatik vakum çok kesintiye neden oluyor

Otomatik vakum daha fazla kaynak tüketiyorsa aşağıdaki eylemler gerçekleştirilebilir:

Otomatik vakum parametreleri

, , autovacuum_vacuum_cost_limitautovacuum_max_workersparametrelerini autovacuum_vacuum_cost_delaydeğ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üksekse artırın autovacuum_vacuum_cost_delay ve azaltın autovacuum_vacuum_cost_limit .
  • Varsayılan değer olan autovacuum_max_workers 3'ten yüksek ayarlanmışsa sayısını 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 sayıda otomatik vakum çalışanı olması önerilmez.

Otomatik vakum çalışanlarının sayısının artırılması daha fazla bellek tüketimine neden olur ve değerine maintenance_work_mem bağ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.

eğer işçi sayısı artarsa, autovacuum_vacuum_cost_limit vakum işlemini hızlandırmak için de artırılmalı ve/veya autovacuum_vacuum_cost_delay azaltılmalıdır.

Ancak, parametreyi tablo düzeyinde veya autovacuum_vacuum_cost_limit parametrelerde autovacuum_vacuum_cost_delay ayarlarsak, bu tablolarda çalışan çalışanlar dengeleme algoritmasında [autovacuum_cost_limit/autovacuum_max_workers] dikkate alınmaktan muaf tutulur.

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özlemlenebilir:

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

Not

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ıramasanız da VACUUM'yi çalıştırabilirsiniz.

Sarmalama sorunu, veritabanı vakumlanmadığında veya otomatik vakumla kaldırılmayan çok fazla sayıda ölü tanımlama grubu olduğunda oluşur. Bu sorunun nedenleri:

Ağır iş yükü

İş yükü, kısa bir süre içinde çok fazla sayıda ölü tanımlama grubuna neden olabilir ve bu da otomatik vakumu yakalamayı 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üre çalışan işlemler, otomatik vakum çalışırken ölü tanımlama listelerinin kaldırılması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

İşlenmeyen hazırlanmış deyimler varsa, bunlar ölü tanımlama listelerinin kaldırılması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 geri almak için COMMIT PREPARED veya ROLLBACK PREPARED kullanın.

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 ayarlanabilir. Ö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 tablo sık sık güncelleştiriliyorsa, otomatik vakumun değişiklik yüzdesinin o kadar önemli olmayan diğer tabloları korumasını önleyerek günde yüzlerce otomatik vakum işlemi görebilirsiniz. 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.

Tablo başına otomatik vakum ayarını ayarlamak için sunucu parametrelerini aşağıdaki örneklerle 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);

Yalnızca ekleme iş yükleri

PostgreSQL <= 13 sürümlerinde, ölü tanımlama kümeleri ve geri alınması gereken boş alan olmadığından otomatik vakum yalnızca ekleme iş yüküne sahip tablolarda çalışmaz. Ancak, yeni veriler olduğundan otomatik analiz yalnızca ekleme iş yükleri için çalışır. Bunun 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ı.

Çözümler

Postgres sürümleri <= 13

pg_cron uzantısı kullanılarak, tabloda düzenli bir vakum analizi zamanlamak için bir cron işi ayarlanabilir. Cron işinin sıklığı iş yüküne bağlıdır.

pg_cron kullanarak adım adım yönergeler için Uzantılar'ı gözden geçirin.

Postgres 13 ve üzeri sürümler

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

Sorun giderme kılavuzları

PostgreSQL için Azure Veritabanı esnek sunucu portalında bulunan özellik sorun giderme kılavuzlarını kullanarak veritabanı veya tek tek şema düzeyinde şişkinliği izlemek ve otomatik vakum işlemine yönelik olası engelleyicileri belirlemek mümkündür. İlk olarak iki sorun giderme kılavuzu mevcuttur. Bu kılavuzlardan biri, veritabanı veya tek tek şema düzeyinde bloat'ı izlemek için kullanılabilen otomatik vakum izlemedir. İkinci sorun giderme kılavuzu, olası otomatik vakum engelleyicilerini tanımlamaya yardımcı olan otomatik vakum engelleyicileri ve sarmalamadır. Ayrıca sunucudaki veritabanlarının sarmalama veya acil durum durumlarından ne kadar uzak olduğu hakkında bilgi sağlar. Sorun giderme kılavuzları olası sorunları azaltmak için önerileri de paylaşır. Bunları kullanmak için sorun giderme kılavuzlarını ayarlama sorun giderme kılavuzlarını izleyin.

Azure Danışmanı Önerileri

Azure Danışmanı önerileri, bir sunucunun yüksek şişkinlik oranına sahip olup olmadığını veya sunucunun işlem sarmalama senaryosuna yaklaşıp yaklaşmadığını belirlemenin proaktif bir yoludur. Ayrıca, Azure portalını kullanarak Yeni önerilerde Azure Danışmanı uyarıları oluşturma'yı kullanarak öneriler için uyarılar ayarlayabilirsiniz

Ö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 Kaydırma çevresinde: 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, sunucunun 1 milyar işlem eşiğini aştığını gördüğümüzde bir öneri tetikleniyor.

İlgili içerik