Pemantauan DAX

Cache hit ratio - Menunjukkan seberapa efektif DAX melayani data cache, mengurangi kebutuhan untuk mengakses tabel DynamoDB yang mendasarinya. Beberapa kesalahan cache untuk cluster menunjukkan efisiensi caching yang baik. Tetapi beberapa klik cache menunjukkan bahwa Anda mungkin perlu meninjau kembali TTL pengaturan caching atau beban kerja tidak cocok untuk caching.

Gunakan Amazon CloudWatch untuk menghitung rasio hit cache DAX klaster Anda. BandingkanItemCacheHits,ItemCacheMisses,QueryCacheHits, dan QueryCacheMisses metrik untuk mendapatkan rasio ini. Rumus berikut menunjukkan bagaimana rasio hit cache dihitung. Untuk menghitung rasio menggunakan rumus ini, bagilah cache hits Anda dengan jumlah cache hits dan misses Anda.

Cache hit ratio = Cache hits / (Cache hits + Cache misses)

Rasio hit cache adalah angka antara 0 dan 1, yang direpresentasikan sebagai persentase. Persentase yang lebih tinggi menunjukkan pemanfaatan cache keseluruhan yang lebih baik.

ErrorRequestCount— Jumlah permintaan yang mengakibatkan kesalahan pengguna yang dilaporkan oleh node atau cluster. ErrorRequestCounttermasuk permintaan yang dibatasi oleh node atau cluster. Memantau kesalahan pengguna dapat membantu Anda mengidentifikasi kesalahan konfigurasi penskalaan atau pola item/partisi panas dalam aplikasi Anda.

Latensi operasi — Memantau latensi operasi baca dan tulis ke dan dari DAX cluster dapat membantu Anda dalam mengidentifikasi kemacetan kinerja. Peningkatan latensi mungkin menunjukkan masalah dengan konfigurasi DAX klaster, jaringan, atau kebutuhan untuk menskalakan.

Konsumsi jaringan - Awasi NetworkBytesIn dan NetworkBytesOut metrik untuk memantau lalu lintas jaringan DAX cluster Anda. Peningkatan throughput jaringan yang tidak terduga dapat berarti lebih banyak permintaan klien atau pola kueri yang tidak efisien yang menyebabkan lebih banyak data ditransfer.

Memantau konsumsi jaringan membantu Anda mengelola biaya untuk DAX cluster Anda. Ini juga memastikan jaringan tidak menjadi hambatan untuk kinerja cluster.

Tingkat penggusuran - Menunjukkan seberapa sering item dihapus dari cache Anda untuk memberi ruang bagi item baru. Jika tingkat penggusuran meningkat dari waktu ke waktu, cache Anda mungkin terlalu kecil atau strategi caching Anda tidak efektif.

Pantau EvictedSize metrik CloudWatch untuk menentukan apakah ukuran cache Anda memadai untuk beban kerja Anda. Jika ukuran total yang diusir terus bertambah, Anda mungkin perlu meningkatkan DAX klaster Anda untuk mengakomodasi cache yang lebih besar.

CPUpemanfaatan — Mengacu pada persentase CPU pemanfaatan node atau cluster. Ini adalah metrik penting untuk memantau database atau sistem caching apa pun. CPUPemanfaatan yang tinggi dapat berarti DAX klaster Anda mungkin kelebihan beban dan perlu penskalaan untuk menangani peningkatan permintaan.

Pantau CPUUtilization metrik untuk DAX cluster Anda. Jika CPU pemanfaatan Anda secara konsisten mendekati atau melebihi 70-80%, pertimbangkan untuk meningkatkan DAX klaster Anda seperti yang dijelaskan di bagian berikut.

Jika jumlah permintaan yang dikirim DAX melebihi kapasitas node, DAX batasi tingkat penerimaan permintaan tambahan. Ini dilakukan dengan mengembalikan a ThrottlingException. DAXterus mengevaluasi CPU pemanfaatan klaster Anda untuk menentukan volume permintaan yang dapat diproses sambil mempertahankan status klaster yang sehat.

Anda dapat memantau ThrottledRequestCount metrik yang DAX diterbitkan ke CloudWatch. Jika melihat pengecualian ini secara rutin, Anda harus mempertimbangkan untuk menaikkan skala klaster.

Tingkatkan atau perkecil — Jika DAX klaster Anda memiliki CPU pemanfaatan tinggi, klik cache rendah (setelah mengoptimalkan strategi caching), atau latensi operasi yang tinggi, Anda harus meningkatkan skala cluster Anda. Menambahkan lebih banyak node, juga disebut scaling out, dapat membantu mendistribusikan beban secara lebih merata. Untuk beban kerja dengan peningkatan penulisan per detik, Anda mungkin perlu memilih node yang lebih kuat (meningkatkan skala).

Turunkan skala — Jika Anda secara konsisten melihat latensi CPU pemanfaatan dan operasi yang rendah di bawah ambang batas Anda, Anda mungkin memiliki sumber daya yang disediakan secara berlebihan. Dalam kasus seperti itu, kurangi node untuk mengurangi biaya. Anda dapat mengurangi jumlah node menjadi 1 selama periode pemanfaatan rendah, tetapi Anda tidak dapat mematikan cluster sepenuhnya.