All Products
Search

This Product

    Tair (Redis® OSS-Compatible):Gunakan log kueri lambat untuk troubleshooting masalah timeout

    Document Center

    Tair (Redis® OSS-Compatible):Gunakan log kueri lambat untuk troubleshooting masalah timeout

    Last Updated:Sep 10, 2026

    Kueri lambat merupakan penyebab umum timeout koneksi yang memengaruhi kualitas layanan Tair (Redis OSS-compatible). Sistem log kueri lambat Tair (Redis OSS-compatible) mencatat setiap kueri lambat beserta alamat IP klien yang mengirimkannya, sehingga Anda dapat mengidentifikasi kueri tersebut dan sumbernya. Ikuti prosedur dalam topik ini untuk menemukan penyebab timeout, dan gunakan jalur alternatif jika log kueri lambat tidak menjelaskan masalah tersebut.

    Metode peninjauan

    TipeMetode
    Log kueri lambat node dataHubungkan ke instans dari client dan jalankan perintah SLOWLOG GET. Untuk detailnya, lihat SLOWLOG GET. Gunakan Konsol atau panggil operasi API: Query slow query logsDescribeSlowLogRecords
    Log kueri lambat node proxyGunakan Konsol atau panggil operasi API: Query slow query logsDescribeSlowLogRecords

    Pilih jalur troubleshooting

    Log kueri lambat merupakan metode utama untuk troubleshooting masalah timeout, tetapi tidak mencakup semua penyebab. Cocokkan pengamatan Anda dengan jalur yang sesuai dalam topik ini.

    Kondisi yang teramatiJalur
    Terjadi timeout layananMulai dari log kueri lambat node proxy, lalu periksa log kueri lambat node data. Lihat Analyze slow query logs to identify the timeout cause.
    Terjadi timeout layanan dan instans menggunakan arsitektur standarLewati log kueri lambat node proxy dan analisis log kueri lambat node data. Lihat Analyze slow query logs to identify the timeout cause.
    Log kueri lambat node proxy kosong dan instans diakses melalui jaringan publik (Internet)Periksa tautan jaringan antara klien dan instans. Lihat Troubleshoot public network connection latency.
    Kueri baca pada suatu kunci terjadi dengan frekuensi tinggi tetapi masing-masing selesai lebih cepat daripada ambang batas slowlog-log-slower-than, sehingga tidak dicatat dalam log kueri lambatLihat Slow query log and audit log limits for hot key troubleshooting.
    Analisis log kueri lambat dan pemeriksaan koneksi jaringan publik tidak mengidentifikasi penyebabnyaLihat Lanjutkan pemecahan masalah di sisi VPC, ECS, dan aplikasi.

    Periksa performa sisi server terlebih dahulu

    Log kueri lambat hanya mencatat kueri yang melebihi ambang batas kueri lambat. Sebelum menentukan apakah timeout berasal dari kueri lambat atau dari tautan jaringan, pastikan terlebih dahulu apakah instans itu sendiri mengalami bottleneck performa.

    Jalankan AI Instance Inspection

    1. Pada halaman produk, klik AI Instance Inspection.

    2. Pilih kedelapan item inspeksi dan klik Start Inspection.

    3. Tinjau laporan inspeksi yang dihasilkan untuk mendeteksi anomali pada status instans, keamanan, ketersediaan tinggi (HA), performa node data, performa node proxy, log kueri lambat, kondisi big key dan hot key, serta peringatan kejadian.

    Lihat pemantauan performa

    1. Pada halaman produk, klik Performance Monitoring.

    2. Beralih ke tampilan Data Node atau tampilan Proxy Node, lalu tinjau penggunaan CPU, jumlah kueri per detik (QPS), waktu respons rata-rata (RT), serta laju traffic inbound dan outbound.

    3. Gunakan metrik untuk setiap node guna menentukan apakah instans mengalami masalah performa.

    Analisis log kueri lambat untuk mengidentifikasi penyebab timeout

    Timeout layanan dapat memiliki penyebab yang kompleks, tetapi sering kali terkait dengan kueri lambat. Ikuti langkah-langkah berikut untuk troubleshooting masalah timeout.

    1. Saat terjadi timeout layanan, pertama-tama periksa log kueri lambat node proxy. Untuk instruksinya, lihat Query slow query logs.

      Catatan

      • Jika instans Anda menggunakan arsitektur standar, lewati ke Langkah 3 untuk menganalisis log kueri lambat node data.

      • Jika log kueri lambat node proxy kosong, periksa koneksi jaringan antara klien dan instans. Jika instans diakses melalui jaringan publik (Internet), lihat Troubleshoot public network connection latency di bawah ini.

    2. Identifikasi perintah dari entri paling awal dalam log kueri lambat node proxy.

      Catatan

      Log kueri lambat node proxy biasanya dihasilkan ketika kueri lambat pada node data menyebabkan perintah menumpuk.

      Dalam contoh ini, entri log kueri lambat paling awal dihasilkan oleh perintah KEYS. Alamat IP dalam catatan log tersebut adalah alamat IP klien yang mengirim perintah tersebut.

      Pada halaman Slow Logs, klik tab Proxy Node untuk melihat log kueri lambat node proxy. Dalam contoh ini, tabel menampilkan lima catatan: satu untuk perintah KEYS dan empat untuk perintah SET, dengan waktu eksekusi berkisar antara 64.048 hingga 88.861 mikrodetik.

    3. Periksa log kueri lambat node data untuk melihat apakah perintah yang ditemukan dalam log proxy juga muncul, yang dapat mengonfirmasi perintah tersebut sebagai akar penyebab.

      Catatan

      Umumnya, perintah yang pertama kali menghasilkan entri log kueri lambat pada node proxy juga menghasilkan entri pada node data. Log kueri lambat node data biasanya memiliki lebih sedikit entri dibandingkan log node proxy karena keduanya mendefinisikan waktu eksekusi secara berbeda dan menggunakan ambang batas kueri lambat yang berbeda.

      Dalam contoh ini, perbandingan kedua log menunjukkan bahwa entri untuk perintah KEYS ada di keduanya. Tidak adanya perintah lain dari log proxy dalam log node data mengonfirmasi bahwa perintah KEYS merupakan akar penyebabnya.

      Pada halaman Slow Logs, klik tab Data Node untuk melihat log kueri lambat node data. Dalam contoh ini, hanya muncul satu entri log kueri lambat untuk perintah KEYS. Waktu eksekusinya yang lama mengonfirmasi bahwa perintah ini merupakan akar penyebab timeout.

    4. Dalam log kueri lambat node proxy, cari perintah dari langkah sebelumnya untuk menemukan alamat IP klien sumbernya. Kemudian, optimalkan aplikasi klien.

      Jika analisis log kueri lambat dan pemeriksaan koneksi jaringan publik tidak mengidentifikasi penyebabnya, lihat Continue troubleshooting on the VPC, ECS, and application side.

    Batas log kueri lambat dan log audit untuk troubleshooting hot key

    Parameter slowlog-log-slower-than menetapkan ambang batas untuk log kueri lambat pada node data. Nilai default-nya adalah 20.000 mikrodetik (20 ms). Kueri baca yang terjadi dengan frekuensi tinggi namun masing-masing selesai lebih cepat daripada ambang batas ini tidak akan dicatat. Akibatnya, log kueri lambat default tidak dapat mendeteksi kueri baca yang menyebabkan masalah hot key. Jika Anda mencurigai adanya masalah hot key, turunkan nilai parameter slowlog-log-slower-than agar lebih banyak kueri tercatat, sehingga Anda dapat mengidentifikasi sumber kueri baca berfrekuensi tinggi tersebut. Untuk instruksinya, lihat Query slow query logs.

    Setelah Anda mengaktifkan log audit, hanya operasi tulis yang dicatat. Operasi baca tidak dicatat. Akibatnya, Anda tidak dapat menggunakan log audit untuk melihat alamat IP klien dari kueri baca yang mengakses hot key. Untuk menemukan alamat IP klien tersebut, turunkan ambang batas slowlog-log-slower-than dan periksa log kueri lambat yang dihasilkan. Untuk informasi selengkapnya mengenai fitur log audit, lihat Overview of audit logs. Jika masalah hot key disebabkan oleh kueri tulis, gunakan fitur kueri hot key berbasis log audit. Untuk instruksinya, lihat Query historical hotkeys.

    Troubleshooting latensi koneksi jaringan publik

    Jika metrik sisi server tidak menunjukkan bottleneck performa (CPU, memori, dan koneksi semuanya normal, serta log kueri lambat kosong), tetapi klien tetap melaporkan error timeout koneksi, periksa tautan jaringan antara klien dan instans.

    Gejala umum

    Klien melaporkan error seperti socket error, read error, atau connection timeout, sedangkan metrik CPU, memori, dan koneksi sisi server instans normal, serta RT rendah.

    Penyebab utama

    Tautan jaringan publik antara klien dan instans tidak stabil, dan transmisi lintas wilayah menambahkan delay. Kedua efek ini lebih terasa dalam skenario akses lintas batas negara.

    Rekomendasi

    1. Gunakan koneksi jaringan internal untuk beban kerja bisnis inti, bukan mengandalkan tautan jaringan publik.

    2. Untuk penerapan lintas wilayah, gunakan Cloud Enterprise Network (CEN) untuk menghubungkan VPC lintas wilayah dan mencapai konektivitas jaringan internal berlatensi rendah dan stabil. Untuk instruksinya, lihat Manage inter-region connections.

    3. Di sisi klien, tingkatkan nilai timeout koneksi dan timeout baca/tulis, serta terapkan logika retry untuk menangani fluktuasi jaringan. Untuk solusi umum error timeout, lihat Common errors and troubleshooting.

    Lanjutkan troubleshooting di sisi VPC, ECS, dan aplikasi

    Jika analisis log kueri lambat dan pemeriksaan koneksi jaringan publik tidak mengidentifikasi penyebabnya, gunakan informasi dari sisi VPC, ECS, dan aplikasi untuk mempersempit cakupan.

    1. Ambil ID VPC dan ID vSwitch dari halaman produk.

    2. Periksa apakah instans ECS yang mengalami kelambatan atau timeout mengalami anomali, dan apakah waktunya bertepatan dengan perubahan aplikasi.

    3. Jika waktunya bertepatan dengan perubahan aplikasi, kembalikan perubahan tersebut atau selidiki lebih lanjut untuk menemukan petunjuk. Gunakan ID VPC dan ID vSwitch untuk melanjutkan troubleshooting di Konsol VPC atau ECS.