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

CPU (Central Processing Unit) adalah komponen komputer yang menjalankan instruksi. Misalnya, instruksi CPU melakukan operasi aritmetika dan bertukar data dalam memori. Jika kueri meningkatkan jumlah instruksi 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;

Metrik DBLoadCPU

Metrik Wawasan Performa untuk CPU adalah DBLoadCPU. Nilai untuk DBLoadCPU dapat berbeda dengan nilai untuk metrik Amazon CloudWatch CPUUtilization. Metrik CloudWatch dikumpulkan dari HyperVisor untuk instans basis data.

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 menjalankan komputasi dan saat menunggu pada memori I/O. Jenis I/O ini mendominasi beban kerja basis data pada umumnya.

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

  • Metrik CPUUtilization CloudWatch mendekati 100%.

  • Beban rata-rata lebih besar dari jumlah vCPU, yang 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 "storm koneksi".

  • Beban kerja aplikasi 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 kasus tertentu, 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 bersamaan pada CPU. Proses-proses ini dapat menjadi pekerja paralel.

  • Kueri berperforma suboptimal karena membutuhkan buffer dalam jumlah besar.

Corner case

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.

Menyelidiki 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.

Mengetahui apakah jumlah koneksi meningkat

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

Koneksi meningkat

Jika jumlah koneksi meningkat, bandingkan jumlah proses backend yang mengonsumsi CPU terhadap jumlah vCPU. Skenario berikut mungkin terjadi:

  • Jumlah proses backend yang mengonsumsi CPU lebih kecil dari jumlah vCPU.

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

  • Jumlah proses backend yang mengonsumsi CPU lebih besar dari jumlah vCPU.

    Jika demikian, pertimbangkan opsi berikut:

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

    • Tingkatkan ukuran instans untuk mendapatkan jumlah vCPU yang lebih tinggi.

    • 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 blokir per detik dan hit blokir 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 ini dengan cepat terhubung ke dan memutuskan sambungan 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 os.cpuUtilization Wawasan Performa atau metrik CPUUtilization CloudWatch. Jika sistem operasi kelebihan beban, lihat metrik Peningkatan Pemantauan 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 mengetahui apakah pernyataan tersebut dapat menggunakan lebih sedikit CPU. Jalankan perintah EXPLAIN, lalu fokus pada simpul rencana yang memiliki dampak terbesar. Pertimbangkan untuk menggunakan visualizer rencana eksekusi PostgreSQL. Untuk mencoba alat bantu ini, lihat http://explain.dalibo.com/.

Merespons perubahan beban kerja

Jika beban kerja Anda berubah, cari jenis perubahan berikut:

Kueri baru

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

Peningkatan ukuran set data

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

Pemeliharaan atau pembuatan indeks

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

Fungsi baru

Periksa apakah fungsi ini berjalan seperti yang diharapkan selama pengujian. Secara khusus, periksa apakah jumlah eksekusi per detik 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 terlibat secara tiba-tiba berkembang ukurannya, sehingga sangat berbeda dengan 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.