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

# CPU
<a name="wait-event.cpu"></a>

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

**Topics**
+ [Versi mesin yang didukung](#wait-event.cpu.context.supported)
+ [Konteks](#wait-event.cpu.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#wait-event.cpu.causes)
+ [Tindakan](#wait-event.cpu.actions)

## Versi mesin yang didukung
<a name="wait-event.cpu.context.supported"></a>

Informasi peristiwa tunggu ini relevan untuk semua versi RDS for PostgreSQL.

## Konteks
<a name="wait-event.cpu.context"></a>

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

**Topics**
+ [Bagaimana cara mengetahui kapan peristiwa tunggu ini terjadi?](#wait-event.cpu.when-it-occurs)
+ [DBLoadMetrik CPU](#wait-event.cpu.context.dbloadcpu)
+ [Metrik os.cpuUtilization](#wait-event.cpu.context.osmetrics)
+ [Kemungkinan penyebab penjadwalan CPU](#wait-event.cpu.context.scheduling)

### Bagaimana cara mengetahui kapan peristiwa tunggu ini terjadi?
<a name="wait-event.cpu.when-it-occurs"></a>

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
<a name="wait-event.cpu.context.dbloadcpu"></a>

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

### Metrik os.cpuUtilization
<a name="wait-event.cpu.context.osmetrics"></a>

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
<a name="wait-event.cpu.context.scheduling"></a>

 Kernel sistem operasi (OS) menangani penjadwalan untuk CPU. Ketika CPU *aktif*, sebuah proses mungkin perlu menunggu untuk dijadwalkan. CPU aktif saat melakukan penghitungan. Ini juga aktif saat memiliki utas idle yang tidak berjalan, yaitu, utas idle yang menunggu 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 `CPUUtilization`Metriknya 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
<a name="wait-event.cpu.causes"></a>

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

**Topics**
+ [Kemungkinan penyebab lonjakan mendadak](#wait-event.cpu.causes.spikes)
+ [Kemungkinan penyebab frekuensi tinggi jangka panjang](#wait-event.cpu.causes.long-term)
+ [Corner cases](#wait-event.cpu.causes.corner-cases)

### Kemungkinan penyebab lonjakan mendadak
<a name="wait-event.cpu.causes.spikes"></a>

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
<a name="wait-event.cpu.causes.long-term"></a>

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
<a name="wait-event.cpu.causes.corner-cases"></a>

Jika tidak ada kemungkinan penyebab yang merupakan penyebab sebenarnya, situasi berikut mungkin terjadi:
+ CPU menukar proses masuk dan keluar.
+ CPU mungkin mengelola entri tabel halaman jika fitur *huge page* telah dinonaktifkan. Fitur manajemen memori ini diaktifkan secara default untuk semua kelas instans DB selain kelas instans DB mikro, kecil, dan menengah. Untuk informasi selengkapnya, lihat [Halaman besar untuk RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md). 

## Tindakan
<a name="wait-event.cpu.actions"></a>

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

**Topics**
+ [Selidiki apakah basis data menyebabkan peningkatan CPU](#wait-event.cpu.actions.db-CPU)
+ [Tentukan apakah jumlah koneksi meningkat](#wait-event.cpu.actions.connections)
+ [Tanggapi perubahan beban kerja](#wait-event.cpu.actions.workload)

### Selidiki apakah basis data menyebabkan peningkatan CPU
<a name="wait-event.cpu.actions.db-CPU"></a>

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
<a name="wait-event.cpu.actions.connections"></a>

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

#### Koneksi meningkat
<a name="wait-event.cpu.actions.connections.increased"></a>

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 Aurora](rds-proxy.md).
  + 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
<a name="wait-event.cpu.actions.connections.decreased"></a>

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](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/](http://explain.dalibo.com/).

### Tanggapi perubahan beban kerja
<a name="wait-event.cpu.actions.workload"></a>

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