Aracılığıyla paylaş

PostgreSQL için Azure Veritabanı - Esnek Sunucu için yüksek IOPS kullanımı sorunlarını giderme

  • Makale

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

Bu makalede, yüksek IOPS (saniye başına giriş/çıkış işlemleri) kullanımının kök nedenini hızlı bir şekilde nasıl belirleyip PostgreSQL için Azure Veritabanı esnek sunucu kullanırken IOPS kullanımını denetlemek için düzeltme eylemlerinin nasıl sağlandığından yararlanırsınız.

Bu makalede şunları öğreneceksiniz:

  • Kök nedenleri belirlemek ve azaltmak için öneriler almak için sorun giderme kılavuzları hakkında.
  • Azure Ölçümleri, Sorgu Deposu ve pg_stat_statements gibi yüksek giriş/çıkış (G/Ç) kullanımını belirlemek için araçları kullanın.
  • Uzun süre çalışan sorgular, denetim noktası zamanlamaları, kesintiye neden olan otomatik vakum daemon işlemi ve yüksek depolama kullanımı gibi kök nedenleri belirleyin.
  • Açıklama Analizi'ni kullanarak yüksek G/Ç kullanımını çözün, denetim noktasıyla ilgili sunucu parametrelerini ayarlayın ve autovacuum daemon'unu ayarlayın.

Sorun giderme kılavuzları

PostgreSQL için Azure Veritabanı esnek sunucu portalında bulunan özellik sorun giderme kılavuzlarını kullanarak olası kök neden ve yüksek IOPS kullanım senaryolarını azaltmaya yönelik öneriler bulunabilir. Bunları kullanmak için sorun giderme kılavuzlarını ayarlama lütfen kurulum sorun giderme kılavuzlarını izleyin.

Yüksek G/Ç kullanımını belirleme araçları

Yüksek G/Ç kullanımını belirlemek için aşağıdaki araçları göz önünde bulundurun.

Azure Ölçümleri

Azure Ölçümleri, tanımlı bir tarih ve dönem için G/Ç kullanımını denetlemek için iyi bir başlangıç noktasıdır. Ölçümler, G/Ç kullanımının yüksek olduğu süre hakkında bilgi verir. İş yükünün yüksek G/Ç kullanımına neden olduğu zamanları bulmak için Yazma IOP'leri, Okuma IOP'leri, Okuma Aktarım Hızı ve Yazma Aktarım Hızı grafiklerini karşılaştırın. Proaktif izleme için ölçümler üzerinde uyarılar yapılandırabilirsiniz. Adım adım yönergeler için bkz . Azure Ölçümleri.

Sorgu Deposu

Sorgu Deposu özelliği sorguların ve çalışma zamanı istatistiklerinin geçmişini otomatik olarak yakalar ve bunları gözden geçirmeniz için saklar. Zamansal kullanım desenlerini görmek için verileri zamana göre dilimler. Tüm kullanıcılar, veritabanları ve sorgular için veriler, PostgreSQL için Azure Veritabanı esnek sunucu örneğinde azure_sys adlı bir veritabanında depolanır. Adım adım yönergeler için bkz . Sorgu Deposu ile performansı izleme.

G/Ç kullanan ilk beş SQL deyimini görüntülemek için aşağıdaki deyimi kullanın:

select * from query_store.qs_view qv where is_system_query is FALSE
order by blk_read_time + blk_write_time  desc limit 5;

pg_stat_statements uzantısı

Uzantı, pg_stat_statements sunucuda G/Ç kullanan sorguları tanımlamaya yardımcı olur.

G/Ç kullanan ilk beş SQL deyimini görüntülemek için aşağıdaki deyimi kullanın:

SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY blk_read_time + blk_write_time desc
LIMIT 5;

Not

blk_read_time ve blk_write_time doldurulacak sütunlar için sorgu deposu veya pg_stat_statements kullanırken sunucu parametresini track_io_timingetkinleştirmeniz gerekir. hakkında track_io_timingdaha fazla bilgi için Sunucu parametreleri'ne bakın.

Kök nedenleri tanımlama

G/Ç tüketim düzeyleri genel olarak yüksekse, kök nedenler şunlar olabilir:

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

Uzun süre çalışan işlemler G/Ç kullanabilir ve bu da yüksek G/Ç kullanımına yol açabilir.

Aşağıdaki sorgu, en uzun süre çalışan bağlantıları tanımlamaya yardımcı olur:

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

Denetim noktası zamanlamaları

Yüksek G/Ç, denetim noktasının çok sık gerçekleştiği senaryolarda da görülebilir. Bunu tanımlamanın bir yolu, esnek PostgreSQL için Azure Veritabanı sunucu günlük dosyasını şu günlük metni için denetlemektir: "LOG: denetim noktaları çok sık oluşuyor."

Zaman damgasıyla düzenli anlık görüntülerinin pg_stat_bgwriter kaydedildiği bir yaklaşım kullanarak da araştırabilirsiniz. Kaydedilen anlık görüntüleri kullanarak ortalama denetim noktası aralığını, istenen denetim noktası sayısını ve zamanlanmış denetim noktası sayısını hesaplayabilirsiniz.

Kesintiye neden olan otomatik vakum daemon işlemi

Otomatik vakumu izlemek için aşağıdaki sorguyu çalıştırın:

SELECT schemaname, relname, n_dead_tup, n_live_tup, autovacuum_count, last_vacuum, last_autovacuum, last_autoanalyze, autovacuum_count, autoanalyze_count FROM pg_stat_all_tables WHERE n_live_tup > 0;

Sorgu, veritabanındaki tabloların ne sıklıkta vakumlandığını denetlemek için kullanılır.

  • last_autovacuum: Tabloda en son otomatik vakum çalıştırıldığında tarih ve saat.
  • autovacuum_count: Tablonun vakumlama sayısı.
  • autoanalyze_count: Tablonun çözümlenme sayısı.

Yüksek G/Ç kullanımı sorununu çözme

Yüksek G/Ç kullanımını çözmek için aşağıdaki üç yöntemden birini kullanabilirsiniz.

Komutu EXPLAIN ANALYZE

Yüksek G/Ç kullanan sorguyu tanımladıktan sonra sorguyu daha fazla araştırmak ve ayarlamak için kullanın EXPLAIN ANALYZE . Komut hakkında EXPLAIN ANALYZE daha fazla bilgi için EXPLAIN planını gözden geçirin.

Uzun süre çalışan işlemleri sonlandırma

Uzun süre çalışan bir işlemi öldürme seçeneği olarak düşünebilirsiniz.

Oturumun işlem kimliğini (PID) sonlandırmak için aşağıdaki sorguyu kullanarak PID'yi algılamanız gerekir:

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

Ayrıca, (kullanıcı adı) veya datname (veritabanı adı) gibi usename diğer özelliklere göre de filtreleyebilirsiniz.

Oturumun PID'sini aldıktan sonra aşağıdaki sorguyu kullanarak oturumu sonlandırabilirsiniz:

SELECT pg_terminate_backend(pid);

Sunucu parametrelerini ayarlama

Denetim noktasının çok sık gerçekleştiğini gözlemlerseniz, çoğu denetim noktası istenen yerine zaman temelli olana kadar sunucu parametresini artırın max_wal_size . Sonuç olarak, yüzde 90 veya daha fazla zaman tabanlı olmalı ve iki denetim noktası arasındaki aralık sunucuda ayarlanan değere checkpoint_timeout yakın olmalıdır.

  • max_wal_size: Yoğun iş saatleri bir değere ulaşmak için iyi bir max_wal_size zamandır. Bir değere ulaşmak için aşağıdakileri yapın:

    1. Geçerli WAL LSN'yi almak için aşağıdaki sorguyu çalıştırın ve sonucu not edin:

      select pg_current_wal_lsn();

    2. Birkaç checkpoint_timeout saniye bekleyin. Geçerli WAL LSN'yi almak için aşağıdaki sorguyu çalıştırın ve sonucu not edin:

      select pg_current_wal_lsn();

    3. Gigabayt (GB) cinsinden farkı denetlemek için iki sonucu kullanan aşağıdaki sorguyu çalıştırın:

      select round (pg_wal_lsn_diff ('LSN value when run second time', 'LSN value when run first time')/1024/1024/1024,2) WAL_CHANGE_GB;

  • checkpoint_completion_target: Değeri 0,9 olarak ayarlamak iyi bir uygulama olabilir. Örneğin, 5 dakikalık 0,9 checkpoint_timeout değeri, denetim noktasını tamamlama hedefinin 270 saniye (0,9*300 saniye) olduğunu gösterir. 0,9 değeri oldukça tutarlı bir G/Ç yükü sağlar. değerinin checkpoint_completion_target agresif bir değeri, sunucuda G/Ç yükünün artmasına neden olabilir.

  • checkpoint_timeout: Değeri sunucuda ayarlanan varsayılan değerden artırabilirsiniz checkpoint_timeout . Değeri artırırken, değerini artırmanın kilitlenme kurtarma süresini de artıracağını göz önünde bulundurabilirsiniz.

Kesintileri azaltmak için otomatik vakum ayarlama

Otomatik vakum'un çok fazla kesintiye neden olduğu senaryolarda izleme ve ayarlama hakkında daha fazla bilgi için Bkz . Otomatik vakum ayarlama.

Depolamayı artırın

Depolamayı artırmak, sunucuya daha fazla IOPS eklerken yardımcı olur. Depolama ve ilişkili IOPS hakkında daha fazla bilgi için İşlem ve depolama seçenekleri'ni gözden geçirin.

İlgili içerik