Redis memproses perintah satu per satu, sehingga satu perintah lambat menahan semua request di belakangnya.
Mengapa Saat layanan berjalan, seluruh key dicari dengan KEYS, atau ranking dan list berisi jutaan elemen dibaca atau dihapus sekaligus → Akibatnya Semua request lain menunggu sampai perintah itu selesai (puluhan ms hingga beberapa detik) → Di layar Fitur yang memakai sesi, ranking, dan cache tersendat sesaat secara bersamaan, login tertunda
Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur DB (Tim Infrastruktur)
Tugas Tim Pengembang Game
Gunakan SCAN sebagai pengganti KEYS, pecah key besar, hapus dengan UNLINK (penghapusan di latar belakang), sebar waktu kedaluwarsa yang menumpuk di detik yang sama.
Tugas Tim Infrastruktur
Pantau log perintah lambat (SLOWLOG), blokir perintah berbahaya seperti KEYS di server produksi, periksa key besar secara rutin, matikan THP dan sisakan memori yang cukup untuk fork, jalankan penyimpanan RDB dan AOF di replika.
Kisaran angka
Perintah biasa butuh kurang dari 1 ms. Jika jutaan elemen ditangani sekaligus, waktunya bisa mencapai ratusan ms hingga beberapa detik.
Di grafik
Melonjak acak sesekali · Latensi respons Redis, jumlah perintah lambat
Yang diperiksa
Periksa perintah yang melebihi slowlog-log-slower-than dengan SLOWLOG GET, aktifkan latency monitor (default nonaktif) dengan CONFIG SET latency-monitor-threshold, lalu periksa latensi per event seperti fork dan expire-cycle dengan LATENCY LATEST dan LATENCY DOCTOR. Periksa juga waktu fork dan key besar dengan latest_fork_usec di INFO dan redis-cli --bigkeys
Cocok jika
Pada waktu Redis berhenti, SLOWLOG mencatat KEYS atau perintah yang menangani key besar sekaligus, atau LATENCY mencatat event fork atau expire-cycle pada waktu yang sama dengan durasi puluhan ms atau lebih
Tidak cocok jika
SLOWLOG dan LATENCY kosong tetapi lambat hanya di sisi server game: lebih mungkin jaringan atau waktu tunggu di dalam server game (SLOWLOG hanya mengukur waktu eksekusi perintah, tanpa waktu kirim-terima dengan klien)
Sarana pemeriksaan
Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut
Redis juga berhenti sesaat ketika menduplikasi prosesnya (fork) untuk membuat file simpanan (snapshot RDB) atau menulis ulang AOF. Di server modern, jedanya sekitar 10 ms per 1 GB memori, jadi sekitar 300 ms untuk 30 GB. Jika halaman besar (THP) diaktifkan, setiap penulisan setelah fork menyalin satu halaman besar secara utuh (copy-on-write), sehingga jeda dan pemakaian memori melonjak. Karena itu THP biasanya dimatikan dan memori disisakan dengan lega. Redis juga berhenti sesaat untuk menghapus key jika sangat banyak key kedaluwarsa pada detik yang sama.
Sumber
Diagnosing latency issuesRedis Satu thread memproses request secara berurutan sehingga perintah lambat menahan semua yang di belakangnya; gunakan SCAN sebagai pengganti KEYS; hasil pengukuran fork di server fisik dan VM modern sekitar 9–13 ms per 1 GB; THP membuat latensi dan memori melonjak karena penyalinan setelah fork; Redis berhenti jika banyak key kedaluwarsa pada detik yang sama
KEYSRedis Gunakan dengan sangat hati-hati di lingkungan produksi karena bisa merusak performa pada DB besar (40 ms untuk 1 juta key di laptop kelas entry-level)
UNLINKRedis Penghapusan asinkron: key langsung dilepas, sedangkan pengambilan kembali memori dilakukan di thread lain
SLOWLOGRedis Log perintah lambat yang mencatat perintah yang melebihi slowlog-log-slower-than; waktu eksekusinya tidak mencakup I/O kirim-terima dengan klien
Redis latency monitoringRedis latency-monitor-threshold default 0 (nonaktif); LATENCY LATEST dan LATENCY DOCTOR; mencatat latensi per event seperti fork dan expire-cycle
INFORedis latest_fork_usec: waktu yang dibutuhkan fork terakhir (mikrodetik)
Redis CLIRedis --bigkeys: memindai keyspace untuk menemukan key besar