CPU - Amazon Aurora
Versi mesin yang didukungKonteksKemungkinan penyebab peningkatan peristiwa tungguTindakan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

CPU

Peristiwa ini terjadi saat thread aktif di CPU atau sedang menunggu CPU.

Versi mesin yang didukung

Informasi peristiwa tunggu ini relevan untuk Aurora PostgreSQL versi 9.6 dan yang lebih tinggi.

Konteks

Central Processing Unit (CPU) adalah komponen komputer yang menjalankan petunjuk. Misalnya, petunjuk CPU melakukan operasi aritmetika dan bertukar data dalam memori. Jika kueri meningkatkan jumlah petunjuk yang dilakukannya melalui mesin basis data, waktu yang dihabiskan untuk menjalankan kueri akan meningkat. Penjadwalan CPU memberikan waktu CPU untuk suatu proses. Penjadwalan diatur oleh kernel sistem operasi.

Bagaimana cara mengetahui kapan peristiwa tunggu ini terjadi?

Peristiwa tunggu CPU ini menunjukkan bahwa proses backend aktif di CPU atau sedang menunggu CPU. Anda mengetahuinya terjadi saat kueri menunjukkan informasi berikut:

  • Kolom pg_stat_activity.state memiliki nilai active.

  • Kolom wait_event_type dan wait_event di pg_stat_activity adalah null.

Untuk melihat proses backend yang menggunakan atau menunggu CPU, jalankan kueri berikut.

SELECT * 
FROM   pg_stat_activity
WHERE  state = 'active'
AND    wait_event_type IS NULL
AND    wait_event IS NULL;

DBLoadMetrik CPU

Metrik Wawasan Performa untuk CPU adalah DBLoadCPU. Nilai untuk DBLoadCPU dapat berbeda dari nilai untuk CloudWatch metrik AmazonCPUUtilization. Metrik terakhir dikumpulkan dari HyperVisor untuk instance database.

Metrik os.cpuUtilization

Metrik sistem operasi Wawasan Performa memberikan informasi terperinci tentang pemanfaatan CPU. Misalnya, Anda dapat menampilkan metrik berikut:

  • os.cpuUtilization.nice.avg

  • os.cpuUtilization.total.avg

  • os.cpuUtilization.wait.avg

  • os.cpuUtilization.idle.avg

Wawasan Performa melaporkan penggunaan CPU oleh mesin basis data sebagai os.cpuUtilization.nice.avg.

Kemungkinan penyebab penjadwalan CPU

Dari perspektif sistem operasi, CPU aktif saat tidak menjalankan thread idle. CPU aktif saat melakukan komputasi, tetapi juga aktif ketika menunggu di memori I/O. This type of I/O mendominasi beban kerja database yang khas.

Proses cenderung menunggu untuk dijadwalkan pada CPU saat kondisi berikut terpenuhi:

  • CloudWatch CPUUtilizationMetrik mendekati 100 persen.

  • Beban rata-rata lebih besar dari jumlah vCPUs, menunjukkan beban berat. Anda dapat menemukan metrik loadAverageMinute di bagian metrik OS dalam Wawasan Performa.

Kemungkinan penyebab peningkatan peristiwa tunggu

Saat peristiwa tunggu CPU terjadi lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:

Kemungkinan penyebab lonjakan mendadak

Penyebab lonjakan mendadak yang paling memungkinkan adalah sebagai berikut:

  • Aplikasi Anda membuka terlalu banyak koneksi bersamaan ke basis data. Skenario ini dikenal sebagai "connection storm".

  • Beban kerja aplikasi Anda berubah dengan salah satu cara berikut:

    • Kueri baru

    • Peningkatan ukuran set data

    • Pemeliharaan atau pembuatan indeks

    • Fungsi baru

    • Operator baru

    • Peningkatan eksekusi kueri paralel

  • Rencana eksekusi kueri Anda telah berubah. Dalam beberapa kasus, perubahan dapat menyebabkan peningkatan buffer. Misalnya, kueri sekarang menggunakan pemindaian berurutan saat sebelumnya menggunakan indeks. Dalam hal ini, kueri membutuhkan lebih banyak CPU untuk mencapai tujuan yang sama.

Kemungkinan penyebab frekuensi tinggi jangka panjang

Berikut adalah penyebab paling memungkinkan dari peristiwa yang berulang dalam jangka waktu lama:

  • Terlalu banyak proses backend yang berjalan secara konkuren pada CPU. Proses-proses ini dapat berupa pekerja paralel.

  • Kueri beperforma suboptimal karena membutuhkan buffer dalam jumlah besar.

Corner cases

Jika tidak ada kemungkinan penyebab yang merupakan penyebab sebenarnya, situasi berikut mungkin terjadi:

  • CPU menukar proses masuk dan keluar.

  • Peralihan konteks CPU telah meningkat.

  • Kode Aurora PostgreSQL tidak memiliki peristiwa tunggu.

Tindakan

Jika peristiwa tunggu CPU mendominasi aktivitas basis data, hal tersebut tidak selalu menunjukkan adanya masalah performa. Tanggapi peristiwa ini hanya saat performa menurun.

Selidiki apakah basis data menyebabkan peningkatan CPU

Periksa metrik os.cpuUtilization.nice.avg dalam Wawasan Performa. Jika nilai ini jauh lebih kecil daripada penggunaan CPU, proses non-basis data adalah kontributor utama ke CPU.

Tentukan apakah jumlah koneksi meningkat

Periksa DatabaseConnections metrik di Amazon CloudWatch. Tindakan Anda bergantung pada apakah jumlahnya meningkat atau menurun selama periode peningkatan peristiwa tunggu CPU.

Koneksi meningkat

Jika jumlah koneksi naik, bandingkan jumlah proses backend yang mengkonsumsi CPU dengan jumlah v. CPUs Skenario berikut dimungkinkan:

  • Jumlah proses backend yang mengkonsumsi CPU kurang dari jumlah v. CPUs

    Dalam hal ini, jumlah koneksi tidak menjadi masalah. Namun, Anda masih dapat mencoba mengurangi pemanfaatan CPU.

  • Jumlah proses backend yang mengkonsumsi CPU lebih besar dari jumlah v. CPUs

    Jika demikian, pertimbangkan opsi berikut:

    • Kurangi jumlah proses backend yang terhubung ke basis data Anda. Misalnya, terapkan solusi pooling koneksi seperti Proksi RDS. Untuk mempelajari selengkapnya, lihat Proksi Amazon RDS untuk Aurora.

    • Tingkatkan ukuran instans Anda untuk mendapatkan jumlah v yang lebih tinggiCPUs.

    • Jika berlaku, arahkan ulang beberapa beban kerja hanya-baca ke simpul pembaca.

Koneksi tidak meningkat

Periksa metrik blks_hit dalam Wawasan Performa. Cari korelasi antara peningkatan blks_hit dan penggunaan CPU. Skenario berikut mungkin terjadi:

  • Penggunaan CPU dan blks_hit berkorelasi.

    Dalam hal ini, temukan pernyataan SQL teratas yang terkait dengan penggunaan CPU, lalu cari perubahan rencana. Anda dapat menggunakan salah satu teknik berikut:

    • Jelaskan rencana secara manual, lalu bandingkan dengan rencana eksekusi yang diperkirakan.

    • Cari peningkatan hit blok per detik dan hit blok lokal per detik. Di bagian SQL Teratas pada dasbor Wawasan Performa, pilih Preferensi.

  • Penggunaan CPU dan blks_hit tidak berkorelasi.

    Jika demikian, ketahui apakah salah satu hal berikut terjadi:

    • Aplikasi dengan cepat terhubung ke dan terputus dari basis data.

      Jalankan diagnosis perilaku ini dengan mengaktifkan log_connections dan log_disconnections, lalu menganalisis log PostgreSQL. Pertimbangkan untuk menggunakan penganalisis log pgbadger. Untuk informasi selengkapnya, lihat https://github.com/darold/pgbadger.

    • OS kelebihan beban.

      Dalam hal ini, Wawasan Performa menunjukkan bahwa proses backend menggunakan CPU untuk waktu yang lebih lama dari biasanya. Cari bukti di metrik Performance Insights atau os.cpuUtilization metrik. CloudWatch CPUUtilization Jika sistem operasi kelebihan beban, lihat metrik Pemantauan yang Ditingkatkan untuk mendiagnosis lebih lanjut. Secara khusus, lihat daftar proses dan persentase CPU yang dikonsumsi oleh setiap proses.

    • Pernyataan SQL teratas mengonsumsi terlalu banyak CPU.

      Periksa pernyataan yang terkait dengan penggunaan CPU untuk melihat apakah pernyataan tersebut dapat menggunakan lebih sedikit CPU. Jalankan perintah EXPLAIN, lalu fokus pada simpul rencana yang memiliki dampak terbesar. Pertimbangkan untuk menggunakan pemvisualisasi rencana eksekusi PostgreSQL. Untuk mencoba alat ini, lihat http://explain.dalibo.com/.

Tanggapi perubahan beban kerja

Jika beban kerja Anda telah berubah, cari jenis perubahan berikut:

Kueri baru

Periksa apakah kueri baru memang diharapkan. Jika demikian, pastikan bahwa rencana eksekusinya dan jumlah eksekusi per detik memang diharapkan.

Peningkatan ukuran set data

Ketahui apakah pemartisian, jika belum diterapkan, dapat membantu. Strategi ini dapat mengurangi jumlah halaman yang perlu diambil kueri.

Pemeliharaan atau pembuatan indeks

Periksa apakah jadwal pemeliharaan memang diharapkan. Praktik terbaiknya adalah menjadwalkan aktivitas pemeliharaan di luar aktivitas puncak.

Fungsi baru

Periksa apakah fungsi-fungsi ini berfungsi seperti yang diharapkan selama pengujian. Secara khusus, periksa apakah jumlah eksekusi per detik memang diharapkan.

Operator baru

Periksa apakah operator baru berfungsi seperti yang diharapkan selama pengujian.

Peningkatan dalam menjalankan kueri paralel

Ketahui apakah salah satu situasi berikut telah terjadi:

  • Relasi atau indeks yang terkait tiba-tiba bertambah ukurannya sehingga sangat berbeda dari min_parallel_table_scan_size atau min_parallel_index_scan_size.

  • Perubahan terkini telah dilakukan pada parallel_setup_cost atau parallel_tuple_cost.

  • Perubahan terkini telah dilakukan pada max_parallel_workers atau max_parallel_workers_per_gather.