All Products
Search

This Product

    Tair (Redis® OSS-Compatible):Memahami laporan diagnostik instans

    Document Center

    Tair (Redis® OSS-Compatible):Memahami laporan diagnostik instans

    Last Updated:Jul 17, 2026

    Laporan diagnostik mengevaluasi kesehatan instans ApsaraDB for Redis dengan menganalisis metrik performa, distribusi permintaan, dan data kueri lambat. Gunakan laporan ini untuk mengidentifikasi anomali dan mengambil tindakan sebelum berdampak pada bisnis Anda.

    Prasyarat

    Sebelum memulai, pastikan Anda telah:

    Bagian laporan

    Laporan diagnostik terdiri dari empat bagian:

    • Informasi dasar instans: ID instans, tipe instans, versi engine, dan zona tempat instans dideploy.

    • Rangkuman: skor kesehatan instans dan rincian pengurangan poin.

    • Tingkat performa: kondisi saat ini dari metrik performa utama.

    • 10 node teratas yang menerima jumlah kueri lambat terbanyak: 10 node data teratas berdasarkan jumlah kueri lambat, disertai detail kueri tersebut.

    Informasi dasar instans

    Bagian ini menampilkan ID instans, tipe instans, versi engine, dan wilayah tempat instans dideploy.

    Periode diagnostik berlangsung dari pukul 11:10:23, 1 Maret 2021 hingga pukul 14:10:23, 1 Maret 2021. Informasi dasar instans mencakup bidang-bidang berikut:

    • Instance ID: ID instans dan nama instans (contoh akhiran: "-Diagnostic Report Test").

    • Spesifikasi: Edisi Kluster 2 GB (2 node).

    • Tipe instans: Redis 5.0.

    • Zona: Tiongkok (Hangzhou).

    Rangkuman

    Bagian ini menampilkan skor kesehatan keseluruhan instans. Skor maksimum adalah 100. Skor di bawah 100 mencantumkan item diagnostik yang menyebabkan pengurangan poin serta penjelasannya.

    Skor kesehatan adalah 70 dari 100. Item berikut menyebabkan pengurangan poin:

    • Penggunaan CPU tinggi: Penggunaan CPU mencapai 85,9%, melebihi ambang batas aman. 10 poin dikurangi.

    • Penggunaan memori tinggi: Penggunaan memori mencapai 100,0%, melebihi ambang batas aman. 10 poin dikurangi.

    • Akses log lambat: 12 entri log lambat teratas dicatat di server. 10 poin dikurangi.

    Tingkat performa

    Bagian ini menampilkan kondisi saat ini dari metrik performa utama. Perhatikan dengan cermat metrik apa pun yang berada dalam kondisi Hazard—pembacaan yang terus-menerus melebihi ambang batas dapat menurunkan throughput dan meningkatkan latensi.

    Untuk instans yang berjalan dalam arsitektur kluster atau arsitektur Pemisahan baca/tulis, periksa apakah metrik didistribusikan secara tidak merata di seluruh node data. Tinjau grafik kurva Top 5 Nodes untuk setiap metrik guna mengidentifikasi node mana yang mengalami beban tertinggi. Untuk detail arsitektur, lihat Instans master-replika kluster dan Instans Pemisahan baca/tulis.
    Performance level

    Tabel berikut menjelaskan setiap metrik performa, ambang batasnya, dampak bisnis jika ambang batas dilampaui, serta cara pemecahan masalahnya.

    Metrik Ambang Batas Berlaku untuk Dampak Kemungkinan penyebab dan langkah selanjutnya
    CPU utilization 60% Semua arsitektur Penggunaan CPU tinggi mengurangi throughput dan meningkatkan waktu respons. Klien mungkin menjadi tidak responsif. Penyebab: perintah kompleksitas tinggi, hotkey, atau pembuatan koneksi yang terlalu sering. Lihat Memecahkan masalah penggunaan CPU tinggi pada instans.
    Memory usage 80% Semua arsitektur Penggunaan memori tinggi yang berkelanjutan meningkatkan waktu respons, mengganggu stabilitas queries per second (QPS), dan memicu eviksi kunci secara sering. Penyebab: kehabisan memori atau banyak kunci besar. Lihat Memecahkan masalah penggunaan memori tinggi pada instans.
    Connections usage node data 80% Hanya instans kluster dalam mode koneksi langsung. Saat klien terhubung melalui node proxy, pantau koneksi di tingkat node proxy. Lihat Mengaktifkan mode koneksi langsung dan Melihat data pemantauan performa. Saat koneksi mencapai batas, permintaan koneksi baru akan timeout atau gagal. Penyebab: lonjakan traffic atau koneksi idle yang tidak dilepas. Lihat Sesi instans.
    Inbound traffic 80% Semua arsitektur Saat traffic melebihi bandwidth yang disediakan oleh tipe instans, performa klien menurun. Penyebab: lonjakan workload atau kunci besar yang sering dibaca/ditulis. Lihat Memecahkan masalah penggunaan traffic tinggi pada instans.
    Outbound traffic 80% Semua arsitektur

    Distribusi permintaan tidak merata

    Untuk instans yang berjalan dalam arsitektur kluster atau arsitektur Pemisahan baca/tulis, laporan juga memeriksa apakah permintaan didistribusikan secara merata di seluruh node data. Jika terdeteksi distribusi permintaan tidak merata untuk suatu metrik, identifikasi node mana yang menerima beban tidak seimbang tersebut.

    Laporan menandai distribusi permintaan tidak merata ketika kedua kondisi berikut terpenuhi:

    1. Nilai puncak di seluruh node data melebihi ambang batas minimum berikut:

      • CPU utilization: 10%

      • Memory usage: 20%

      • Inbound dan outbound traffic: 5 Mbit/s

      • Penggunaan koneksi: 5%

    2. Skor keseimbangan melebihi 1,3. Skor keseimbangan dihitung sebagai: max{rata-rata nilai performa semua node data} / median nilai performa semua node data. Misalnya, sebuah instans memiliki empat node data dengan rata-rata penggunaan CPU sebesar 10%, 30%, 50%, dan 60%. Median-nya adalah 40%, dan skor keseimbangannya adalah 60% / 40% = 1,5. Karena 1,5 > 1,3, laporan menganggap distribusi CPU utilization tidak merata.

    Kemungkinan penyebab Metode pemecahan masalah
    Node data memiliki kunci yang terlalu besar. Gunakan fitur analisis kunci offline atau fitur statistik kunci teratas untuk mengidentifikasi dan mendistribusikannya ulang.
    Sebuah node data memiliki hotkey. Gunakan fitur statistik kunci teratas untuk mengidentifikasi hotkey.
    Hash tag dikonfigurasi secara tidak tepat. Kunci dengan hash tag yang sama selalu ditempatkan pada node data yang sama. Jika banyak kunci menggunakan hash tag yang sama, node tersebut menjadi kelebihan beban. Tinjau dan sesuaikan konfigurasi hash tag Anda agar kunci tersebar di berbagai node.

    10 node teratas yang menerima jumlah kueri lambat terbanyak

    Bagian ini mencantumkan 10 node data teratas berdasarkan jumlah kueri lambat dan memberikan detail tentang kueri tersebut. Laporan ini mengambil data log lambat dari dua sumber:

    • Log audit sistem: log lambat yang disimpan selama 4 hari.

    • Log node data: 1.024 entri log terbaru, disimpan langsung di setiap node data. Hubungkan ke instans menggunakan redis-cli dan jalankan perintah SLOWLOG GET untuk mengambilnya.

    Dua node, r-bp***-db-0 dan r-bp***-db-1, masing-masing memiliki 6 kueri lambat. Perintah kueri lambat utama dan durasi eksekusinya adalah sebagai berikut:

    • keys *: Waktu eksekusi maksimum sekitar 86 ms, rata-rata sekitar 86 ms.

    • keys key:0000001*: Waktu eksekusi maksimum sekitar 62 ms, rata-rata sekitar 59 ms.

    • Beberapa perintah del: Waktu eksekusi sekitar 12–18 ms.

    Gunakan data kueri lambat untuk mengidentifikasi perintah yang menyebabkan masalah performa.

    Penyebab Solusi
    Perintah dengan kompleksitas waktu O(N) atau biaya CPU tinggi, seperti KEYS * Evaluasi dan nonaktifkan perintah berisiko tinggi seperti FLUSHALL, KEYS, dan HGETALL. Lihat Menonaktifkan perintah berisiko tinggi.
    Kunci besar yang sering dibaca/ditulis ke node data. Analisis kunci besar tersebut menggunakan fitur analisis kunci offline, lalu pecah berdasarkan kebutuhan bisnis Anda.