Share via

Memecahkan masalah pemanfaatan IOPS tinggi untuk Azure Database for PostgreSQL - Server Fleksibel

  • Artikel

BERLAKU UNTUK: Azure Database for PostgreSQL - Server Fleksibel

Artikel ini menunjukkan kepada Anda cara dengan cepat mengidentifikasi akar penyebab pemanfaatan IOPS tinggi (operasi input/output per detik) dan menyediakan tindakan remedial untuk mengontrol pemanfaatan IOPS saat Anda menggunakan server fleksibel Azure Database for PostgreSQL.

Dalam artikel ini, Anda akan mempelajari cara:

  • Tentang panduan pemecahan masalah untuk mengidentifikasi dan mendapatkan rekomendasi untuk mengurangi akar penyebabnya.
  • Gunakan alat untuk mengidentifikasi pemanfaatan input/output (I/O) yang tinggi, seperti Metrik Azure, Penyimpanan Kueri, dan pg_stat_statements.
  • Identifikasi akar penyebabnya, seperti kueri yang berjalan lama, waktu titik pemeriksaan, proses daemon autovacuum yang mengganggu, dan pemanfaatan penyimpanan yang tinggi.
  • Atasi pemanfaatan I/O tinggi dengan menggunakan Explain Analyze, sesuaikan parameter server terkait titik pemeriksaan, dan setel daemon autovacuum.

Panduan Pemecahan Masalah

Menggunakan panduan pemecahan masalah fitur yang tersedia di portal server fleksibel Azure Database for PostgreSQL, kemungkinan akar penyebab dan rekomendasi untuk mengurangi skenario pemanfaatan IOPS yang tinggi dapat ditemukan. Cara menyiapkan panduan pemecahan masalah untuk menggunakannya, ikuti panduan pemecahan masalah penyiapan.

Alat untuk mengidentifikasi pemanfaatan I/O yang tinggi

Pertimbangkan alat berikut untuk mengidentifikasi pemanfaatan I/O yang tinggi.

Azure Metrics

Metrik Azure adalah titik awal yang baik untuk memeriksa pemanfaatan I/O untuk tanggal dan periode yang ditentukan. Metrik memberikan informasi tentang waktu di mana pemanfaatan I/O tinggi. Bandingkan grafik IOP Tulis, IOP Baca, Throughput Baca, dan Throughput Tulis untuk mengetahui waktu ketika beban kerja menyebabkan pemanfaatan I/O yang tinggi. Untuk pemantauan proaktif, Anda dapat mengonfigurasi peringatan pada metrik. Untuk panduan langkah demi langkah, lihat Metrik Azure.

Query Store

Fitur Penyimpanan Kueri secara otomatis mengambil riwayat kueri dan statistik runtime, dan menyimpannya untuk tinjauan Anda. Ini mengiris data menurut waktu untuk melihat pola penggunaan temporal. Data untuk semua pengguna, database, dan kueri disimpan dalam database bernama azure_sys di instans server fleksibel Azure Database for PostgreSQL. Untuk panduan langkah demi langkah, lihat Memantau performa dengan Penyimpanan Kueri.

Gunakan pernyataan berikut untuk melihat lima pernyataan SQL teratas yang menggunakan I/O:

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

Ekstensi pg_stat_statements

pg_stat_statements Ekstensi ini membantu mengidentifikasi kueri yang menggunakan I/O di server.

Gunakan pernyataan berikut untuk melihat lima pernyataan SQL teratas yang menggunakan I/O:

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

Catatan

Saat menggunakan penyimpanan kueri atau pg_stat_statements untuk kolom blk_read_time dan blk_write_time yang akan diisi, Anda perlu mengaktifkan parameter track_io_timingserver . Untuk informasi selengkapnya tentang track_io_timing, tinjau Parameter server.

Mengidentifikasi akar penyebab

Jika tingkat konsumsi I/O tinggi secara umum, berikut ini bisa menjadi akar penyebabnya:

Transaksi jangka panjang

Transaksi jangka panjang dapat mengonsumsi I/O, yang dapat menyebabkan pemanfaatan I/O yang tinggi.

Kueri berikut membantu mengidentifikasi koneksi yang berjalan untuk waktu terlama:

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;

Waktu titik pemeriksaan

I/O tinggi juga dapat dilihat dalam skenario di mana titik pemeriksaan terjadi terlalu sering. Salah satu cara untuk mengidentifikasi hal ini adalah dengan memeriksa file log server fleksibel Azure Database for PostgreSQL untuk teks log berikut: "LOG: titik pemeriksaan terlalu sering terjadi."

Anda juga dapat menyelidiki dengan menggunakan pendekatan di mana rekam jepret pg_stat_bgwriter berkala dengan stempel waktu disimpan. Dengan menggunakan rekam jepret yang disimpan, Anda dapat menghitung interval titik pemeriksaan rata-rata, jumlah titik pemeriksaan yang diminta, dan jumlah titik pemeriksaan yang ditentukan.

Proses daemon autovacuum yang mengganggu

Jalankan kueri berikut untuk memantau autovacuum:

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;

Kueri digunakan untuk memeriksa seberapa sering tabel dalam database dikosongkan.

  • last_autovacuum: Tanggal dan waktu ketika autovacuum terakhir berjalan pada tabel.
  • autovacuum_count: Frekuensi tabel dikosongkan.
  • autoanalyze_count: Frekuensi tabel dianalisis.

Mengatasi penggunaan I/O yang tinggi

Untuk mengatasi pemanfaatan I/O yang tinggi, Anda dapat menggunakan salah satu dari tiga metode berikut.

Perintah EXPLAIN ANALYZE

Setelah Anda mengidentifikasi kueri yang menggunakan I/O tinggi, gunakan EXPLAIN ANALYZE untuk menyelidiki kueri lebih lanjut dan menyetelnya. Untuk informasi selengkapnya tentang EXPLAIN ANALYZE perintah , tinjau paket EXPLAIN.

Menghentikan transaksi yang berjalan lama

Anda dapat mempertimbangkan untuk membunuh transaksi jangka panjang sebagai pilihan.

Untuk mengakhiri ID proses sesi (PID), Anda perlu mendeteksi PID dengan menggunakan kueri berikut:

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;

Anda juga bisa memfilter menurut properti lain, seperti usename (nama pengguna) atau datname (nama database).

Setelah Anda memiliki PID sesi, Anda dapat mengakhirinya dengan menggunakan kueri berikut:

SELECT pg_terminate_backend(pid);

Menyetel parameter server

Jika Anda mengamati bahwa titik pemeriksaan terjadi terlalu sering, tingkatkan max_wal_size parameter server hingga sebagian besar titik pemeriksaan didorong waktu, alih-alih diminta. Akhirnya, 90 persen atau lebih harus berbasis waktu, dan interval antara dua titik pemeriksaan harus dekat dengan checkpoint_timeout nilai yang diatur pada server.

  • max_wal_size: Jam kerja puncak adalah waktu yang tepat untuk tiba dengan max_wal_size nilai . Untuk sampai pada nilai, lakukan hal berikut:

    1. Jalankan kueri berikut untuk mendapatkan WAL LSN saat ini, lalu catat hasilnya:

      select pg_current_wal_lsn();

    2. Tunggu beberapa checkpoint_timeout detik. Jalankan kueri berikut untuk mendapatkan WAL LSN saat ini, lalu catat hasilnya:

      select pg_current_wal_lsn();

    3. Jalankan kueri berikut, yang menggunakan dua hasil, untuk memeriksa perbedaannya, dalam gigabyte (GB):

      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: Praktik yang baik adalah mengatur nilai menjadi 0,9. Sebagai contoh, nilai 0,9 selama checkpoint_timeout 5 menit menunjukkan bahwa target untuk menyelesaikan titik pemeriksaan adalah 270 detik (0,9* 300 detik). Nilai 0,9 memberikan beban I/O yang cukup konsisten. Nilai checkpoint_completion_target agresif dapat mengakibatkan peningkatan beban I/O pada server.

  • checkpoint_timeout: Anda dapat meningkatkan checkpoint_timeout nilai dari nilai default yang diatur di server. Saat Anda meningkatkan nilai, pertimbangkan bahwa meningkatkannya juga akan meningkatkan waktu untuk pemulihan crash.

Menyetel autovacuum untuk mengurangi gangguan

Untuk informasi selengkapnya tentang pemantauan dan penyetelan dalam skenario di mana autovacuum terlalu mengganggu, tinjau Penyetelan autovacuum.

Tambah penyimpanan

Meningkatkan penyimpanan membantu saat Anda menambahkan lebih banyak IOPS ke server. Untuk informasi selengkapnya tentang penyimpanan dan IOPS terkait, tinjau Opsi komputasi dan penyimpanan.

Konten terkait