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

Konsep kunci untuk penyetelan kinerja basis data

DevOpsGuru untuk RDS mengasumsikan bahwa Anda terbiasa dengan beberapa konsep kinerja utama. Untuk mempelajari lebih lanjut tentang konsep-konsep ini, lihat Tinjauan Performance Insights di Panduan Pengguna Amazon Aurora atau Tinjauan Performance Insights di Panduan Pengguna Amazon RDS.

Metrik

Sebuah metrik merupakan serangkaian titik data yang diurutkan berdasarkan waktu. Pikirkan metrik sebagai variabel untuk memantau, dan titik data sebagai representasi nilai-nilai variabel tersebut dari waktu ke waktu. Amazon RDS menyediakan metrik secara real time untuk database dan untuk sistem operasi (OS) tempat instans DB Anda berjalan. Anda dapat melihat semua metrik sistem dan informasi proses untuk instans Amazon RDS DB Anda di konsol Amazon RDS. DevOpsGuru untuk RDS memantau dan memberikan wawasan untuk beberapa metrik ini. Untuk informasi selengkapnya, lihat Metrik pemantauan di klaster Amazon Aurora atau metrik Pemantauan di instans Layanan Database Relasional Amazon.

Deteksi masalah

DevOpsGuru untuk RDS menggunakan metrik database dan sistem operasi (OS) untuk mendeteksi masalah kinerja basis data kritis, apakah masalah tersebut akan datang atau sedang berlangsung. Ada 2 cara utama DevOps Guru untuk deteksi masalah RDS bekerja:

Mendeteksi masalah dengan ambang batas

Ambang batas adalah nilai pembatas yang digunakan untuk mengevaluasi metrik yang dipantau. Anda dapat menganggap ambang batas sebagai garis horizontal pada bagan metrik yang memisahkan perilaku normal dari perilaku yang berpotensi bermasalah. DevOpsGuru untuk RDS memantau metrik tertentu dan membuat ambang batas dengan menganalisis level apa yang dianggap berpotensi bermasalah untuk sumber daya tertentu. DevOpsGuru untuk RDS kemudian membuat wawasan di konsol DevOps Guru ketika nilai metrik baru melewati ambang batas yang ditentukan selama periode waktu tertentu secara konsisten. Wawasan berisi rekomendasi untuk mencegah dampak kinerja database future.

Misalnya, DevOps Guru untuk RDS mungkin memantau jumlah tabel sementara yang menggunakan disk selama periode 15 menit dan membuat wawasan ketika laju tabel sementara menggunakan disk per detik sangat tinggi. Peningkatan tingkat penggunaan tabel sementara on-disk dapat memengaruhi kinerja database. Dengan mengekspos situasi ini sebelum menjadi kritis, DevOps Guru untuk RDS membantu Anda mengambil tindakan korektif untuk mencegah masalah.

Mendeteksi masalah dengan anomali

Sementara ambang batas menyediakan cara yang sederhana dan efektif untuk mendeteksi masalah database, dalam beberapa situasi mereka tidak cukup. Pertimbangkan kasus di mana nilai metrik melonjak dan menyeberang ke perilaku yang berpotensi bermasalah secara teratur karena proses yang diketahui, seperti pekerjaan pelaporan harian. Karena lonjakan seperti itu diharapkan, membuat wawasan dan pemberitahuan untuk masing-masing akan menjadi kontraproduktif dan kemungkinan akan menyebabkan kelelahan yang waspada.

Namun, masih perlu untuk mendeteksi lonjakan yang sangat tidak biasa, karena metrik yang jauh lebih tinggi daripada yang lain atau bertahan lebih lama dapat mewakili masalah kinerja database yang sebenarnya. Untuk mengatasi masalah ini, DevOps Guru untuk RDS memantau metrik tertentu untuk mendeteksi ketika perilaku metrik menjadi sangat tidak biasa atau anomali. DevOpsGuru kemudian melaporkan anomali ini dalam wawasan.

Misalnya, DevOps Guru untuk RDS mungkin membuat wawasan ketika beban DB tidak hanya tinggi, tetapi juga secara signifikan menyimpang dari perilaku biasanya, yang menunjukkan perlambatan besar yang tidak terduga dari operasi database. Dengan hanya mengenali lonjakan beban DB anomali, DevOps Guru for RDS memungkinkan Anda fokus pada masalah yang benar-benar penting.

Muatan DB

Konsep kunci untuk penyetelan basis data adalah metrik beban basis data (beban DB). Beban DB mewakili seberapa sibuk database Anda pada waktu tertentu. Peningkatan beban DB berarti peningkatan aktivitas database.

Sesi basis data mewakili dialog aplikasi dengan basis data relasional. Sesi aktif adalah sesi yang sedang dalam proses menjalankan permintaan database. Sesi dianggap aktif jika berjalan di CPU atau menunggu sumber daya tersedia sehingga dapat dilanjutkan. Misalnya, sesi aktif mungkin menunggu halaman dibaca ke dalam memori, dan kemudian mengkonsumsi CPU saat membaca data dari halaman.

DBLoadMetrik dalam Performance Insights diukur dalam sesi aktif rata-rata (AAS). Untuk menghitung AAS, Performance Insights mengambil sampel jumlah sesi aktif setiap detik. Untuk periode waktu tertentu, AAS adalah jumlah total sesi aktif dibagi dengan jumlah total sampel. Nilai AAS 2 berarti bahwa, rata-rata, 2 sesi aktif dalam permintaan pada waktu tertentu.

Analogi untuk beban DB adalah aktivitas di gudang. Misalkan gudang mempekerjakan 100 pekerja. Jika 1 pesanan masuk, 1 pekerja memenuhi pesanan sementara pekerja lainnya menganggur. Jika 100 atau lebih pesanan masuk, semua 100 pekerja memenuhi pesanan secara bersamaan. Jika Anda secara berkala mengambil sampel berapa banyak pekerja yang aktif selama periode waktu tertentu, Anda dapat menghitung jumlah rata-rata pekerja aktif. Perhitungan menunjukkan bahwa, rata-rata, N pekerja sibuk memenuhi pesanan pada waktu tertentu. Jika rata-rata 50 pekerja kemarin dan 75 pekerja hari ini, tingkat aktivitas di gudang meningkat. Dengan cara yang sama, beban DB meningkat seiring dengan meningkatnya aktivitas sesi.

Untuk mempelajari selengkapnya, lihat Pemuatan basis data di Panduan Pengguna Amazon Aurora atau Pemuatan basis data di Panduan Pengguna Amazon RDS.

Peristiwa tunggu

Peristiwa tunggu adalah jenis instrumentasi database yang memberi tahu Anda sumber daya mana yang menunggu sesi database sehingga dapat dilanjutkan. Saat Performance Insights menghitung sesi aktif untuk menghitung beban database, Performance Insights juga mencatat peristiwa tunggu yang menyebabkan sesi aktif menunggu. Teknik ini memungkinkan Performance Insights untuk menunjukkan kepada Anda peristiwa tunggu mana yang berkontribusi terhadap pemuatan DB.

Setiap sesi aktif berjalan di CPU atau menunggu. Misalnya, sesi mengkonsumsi CPU ketika mereka mencari memori, melakukan perhitungan, atau menjalankan kode prosedural. Ketika sesi tidak menggunakan CPU, mereka mungkin menunggu file data dibaca atau log untuk ditulis. Semakin banyak waktu untuk sesi menunggu sumber daya, semakin sedikit waktu untuk sesi dijalankan di CPU.

Saat Anda menyetel database, Anda sering mencoba menemukan sumber daya yang ditunggu sesi. Misalnya, dua atau tiga peristiwa tunggu mungkin menyumbang 90% dari beban DB. Ukuran ini berarti bahwa, rata-rata, sesi aktif menghabiskan sebagian besar waktunya menunggu sejumlah kecil sumber daya. Jika Anda dapat mengetahui penyebab penantian ini, Anda dapat mencoba memperbaiki masalahnya.

Pertimbangkan analogi pekerja gudang. Pesanan masuk. Pekerja mungkin terlambat memenuhi pesanan. Misalnya, pekerja yang berbeda mungkin sedang mengisi ulang rak, atau troli mungkin tidak tersedia. Atau sistem yang digunakan untuk memasukkan status pesanan lambat. Semakin lama pekerja menunggu, semakin lama pesanan yang dibutuhkan untuk dipenuhi. Menunggu adalah bagian alami dari alur kerja gudang, tetapi jika waktu tunggu menjadi berlebihan, produktivitas menurun. Sama halnya, menunggu sesi berulang atau panjang dapat menurunkan performa basis data.

Untuk informasi selengkapnya tentang peristiwa tunggu di Amazon Aurora, lihat Menyetel dengan acara tunggu untuk Aurora PostgreSQL dan Menyetel dengan peristiwa tunggu untuk Aurora MySQL di Panduan Pengguna Amazon Aurora.

Untuk informasi selengkapnya tentang peristiwa tunggu di database Amazon RDS lainnya, lihat Menyetel dengan peristiwa tunggu untuk RDS for PostgreSQL di Panduan Pengguna Amazon RDS.