Belajar Redis - Memory Management & Performance Tuning

#Pendahuluan

Redis menyimpan segalanya di RAM — artinya memori adalah sumber daya paling berharga, dan latensi adalah janji utama yang harus dijaga. Episode 17 ini membekali kalian analisis dan tuning: memahami angka memori, mengoptimalkan representasi data, dan menemukan sumber latency.

Di produksi, pertanyaan pertama saat masalah adalah selalu: "berapa memori yang dipakai, dan apa yang paling lambat?" Dua alat di episode ini — INFO/MEMORY dan SLOWLOG/LATENCY — menjawab keduanya. Mari mulai dari memori.

#Analisis Penggunaan Memori

#Membaca INFO memory

redis-cli INFO memory

redis-cli INFO memory menampilkan seluruh metrik memori. Dua angka yang paling penting dipahami bedanya:

• used_memory: memori yang dialokasikan Redis untuk data (ukuran logis data).
• used_memory_rss: memori fisik yang benar-benar dipegang dari OS.

Jika used_memory_rss jauh lebih besar dari used_memory, terjadi fragmentasi — OS memberi lebih banyak memori dari yang dibutuhkan data. Jika rasionya tinggi (mem_fragmentation_ratio > 1.5), pertimbangkan CONFIG SET activedefrag yes atau restart terjadwal.

#MEMORY USAGE dan MEMORY DOCTOR

redis-cli MEMORY USAGE user:1
redis-cli MEMORY DOCTOR

MEMORY USAGE user:1 menghitung memori yang dipakai satu key — alat pemburu key boros. MEMORY DOCTOR menganalisis kesehatan memori dan memberikan saran: kunci high fragmentation, banyak key expired yang belum dibersihkan, atau penyimpanan yang tidak efisien.

#Optimasi Memori

#Mengatur maxmemory

Tanpa maxmemory, Redis bisa mengonsumsi seluruh RAM server. Tetapkan batas dan pilih eviction policy (episode 11):

maxmemory 4gb
maxmemory-policy allkeys-lfu
maxmemory-samples 10

maxmemory 4gb membatasi penggunaan, allkeys-lfu memilih buang data dingin, dan maxmemory-samples mengontrol akurasi sampling LFU/LRU — nilai lebih tinggi lebih akurat tapi lebih mahal CPU.

#Encoding Internal Redis

Ini rahasia efisiensi Redis: struktur data besar disimpan dalam encoding ringkas secara otomatis saat kecil, lalu berpindah ke encoding penuh saat tumbuh:

redis-cli OBJECT ENCODING small_list

OBJECT ENCODING small_list menampilkan encoding aktif sebuah key. Membiarkan Redis memilih otomatis hampir selalu tepat — kalian tidak perlu mengintervensi kecuali analisis menunjukkan pemborosan, dan intervensi biasanya lewat list-max-listpack-size dan kawan-kawan di redis.conf.

#Latency Analysis & Tuning

#Mengukur Latensi Dasar

redis-cli --latency

redis-cli --latency mengirim perintah PING terus-menerus dan menampilkan statistik latensi — referensi cepat apakah jaringan dan server sehat. Untuk menemukan perintah yang lambat, gunakan SLOWLOG:

redis-cli SLOWLOG GET 10
redis-cli CONFIG GET slowlog-log-slower-than

SLOWLOG GET 10 menampilkan 10 perintah terlambat terakhir beserta durasi dan argumennya. slowlog-log-slower-than (default 10000 mikrodetik) menentukan ambang dicatatnya perintah lambat. Perintah yang muncul berulang di SLOWLOG adalah tersangka utama masalah latency.

#LATENCY Monitoring

Redis punya sistem latency monitoring untuk mendeteksi spike sistematis:

redis-cli LATENCY LATEST
redis-cli LATENCY HISTORY command
redis-cli LATENCY RESET

LATENCY LATEST menampilkan peristiwa latency terbaru per tipe. LATENCY HISTORY memberi riwayat per tipe — misalnya fork, command, aof-write. LATENCY RESET membersihkan data lama. Event fork yang sering menandakan BGSAVE/AOF rewrite terlalu sering.

#Menghindari Perintah Blocking

Ingat model single-threaded (episode 2): perintah mahal memblokir semuanya. Tersangka utama:

• KEYS * pada keyspace besar — selalu ganti SCAN.
• SMEMBERS pada set raksasa — ganti SSCAN atau SINTERCARD.
• LRANGE 0 -1 / HGETALL pada struktur besar — pindai bertahap.
• Operasi tanpa index di RediSearch yang scan penuh.

Disiplin memakai varian SCAN dan membatasi hasil akan menghindari hampir seluruh spike latency yang menimpa Redis produksi.

#Penutup

Episode 17 membekali kalian memory management dan performance tuning: INFO memory dan MEMORY USAGE untuk analisis, pemahaman fragmentasi used_memory vs used_memory_rss, encoding internal yang otomatis dipilih Redis, serta SLOWLOG dan LATENCY untuk menemukan sumber latency.

Inti yang harus dibawa pulang:

• used_memory vs used_memory_rss: rasio tinggi menandakan fragmentasi memori.
• MEMORY USAGE menemukan key boros; MEMORY DOCTOR memberi saran diagnosa.
• Tetapkan maxmemory + policy eviction yang tepat sejak awal.
• Redis memilih encoding internal (listpack, intset, hashtable) secara otomatis.
• redis-cli --latency dan SLOWLOG GET adalah alat pertama debugging latency.
• LATENCY LATEST menangkap spike sistematis seperti fork.
• Hindari KEYS, SMEMBERS raksasa, dan LRANGE 0 -1 pada struktur besar.

Di episode 18 selanjutnya kita membahas Monitoring & Observability — mengawasi Redis secara menyeluruh. Kalian akan belajar membaca INFO, peringatan soal MONITOR, memetakan Redis ke Prometheus dengan redis_exporter, visualisasi di Grafana, dan menyusun alerting yang tepat. Lanjut!