Redis adalah database dalam memori yang memberikan kinerja yang sangat cepat. Ini menjadikannya alternatif yang menarik untuk database berbasis disk ketika kinerja menjadi perhatian. Anda mungkin sudah menggunakan ScaleGrid hosting untuk Redis™* untuk memberi daya pada aplikasi yang sensitif terhadap kinerja. Bagaimana Anda memastikan bahwa penerapan Redis Anda sehat dan memenuhi persyaratan Anda? Anda perlu mengetahui metrik pemantauan mana yang harus ditonton Redis™ dan alat untuk memantau metrik server penting ini untuk memastikan kesehatannya. Redis mengembalikan daftar besar metrik basis data saat Anda menjalankan perintah info di shell Redis. Anda dapat memilih pilihan cerdas dari metrik yang relevan dari ini. Dan ini dapat membantu Anda memastikan kesehatan sistem Anda dan dengan cepat melakukan analisis akar masalah dari setiap masalah terkait kinerja yang mungkin Anda hadapi.
Pos blog ini mencantumkan metrik basis data penting untuk dipantau. Kami akan melihat setiap metrik dari perspektif kinerja database dan mendiskusikan masalah umum dan solusi yang terkait dengannya.
1. Metrik Performa:Throughput
Throughput memberi tahu Anda berapa banyak operasi database yang dilakukan server Anda dalam durasi waktu tertentu. Itu tergantung pada beban kerja aplikasi Anda dan logika bisnisnya. Dengan melihat riwayat throughput, Anda dapat menyimpulkan pola beban pada server mis. beban puncak, frekuensi beban puncak, kerangka waktu beban puncak, beban rata-rata, dll.
Anda dapat mengumpulkan nilai metrik throughput untuk semua perintah yang dijalankan di server Redis dengan menjalankan “info commandstats ”.
127.0.0.1:6379> info commandstats # Commandstats cmdstat_get:calls=797,usec=4041,usec_per_call=5.07 cmdstat_append:calls=797,usec=4480,usec_per_call=5.62 cmdstat_expire:calls=797,usec=5471,usec_per_call=6.86 cmdstat_auth:calls=147,usec=288,usec_per_call=1.96 cmdstat_info:calls=46,usec=902,usec_per_call=19.61 cmdstat_config:calls=2,usec=130,usec_per_call=65.00 cmdstat_eval:calls=796,usec=36950,usec_per_call=46.42 cmdstat_command:calls=796,usec=8578,usec_per_call=10.78
Redis mengelompokkan berbagai perintahnya ke dalam koneksi, server, cluster, generik, dll. Pemantauan ScaleGrid untuk Redis™ menggabungkan throughput berbagai perintah ke dalam salah satu grup yang disebutkan di atas. Throughput direpresentasikan sebagai grafik area bertumpuk, di mana ketinggian setiap area berwarna memberikan throughput sekelompok perintah.
Troughput yang berkurang biasanya menunjukkan bahwa server mendapat lebih sedikit kueri. Itu juga bisa menunjukkan potensi masalah, katakanlah, kueri yang mahal. Demikian pula, peningkatan throughput menandakan beban kerja intensif di server dan latensi yang lebih besar.
2. Pemanfaatan Memori
Memori adalah sumber daya penting untuk kinerja Redis. Memori bekas mendefinisikan jumlah total byte yang dialokasikan oleh Redis menggunakan pengalokasinya (baik libc standar, jemalloc, atau pengalokasi alternatif seperti tcmalloc).
Anda dapat mengumpulkan semua data metrik penggunaan memori untuk instance Redis dengan menjalankan “memori info ”.
127.0.0.1:6379> info memory # Memory used_memory:1007280 used_memory_human:983.67K used_memory_rss:2002944 used_memory_rss_human:1.91M used_memory_peak:1008128 used_memory_peak_human:984.50K
Terkadang, ketika Redis dikonfigurasi tanpa batas memori maksimal, penggunaan memori pada akhirnya akan mencapai memori sistem, dan server akan mulai membuat kesalahan “Memori Habis”. Di lain waktu, Redis dikonfigurasi dengan batas memori maksimal tetapi tidak ada penggusuran aturan. Ini akan menyebabkan server tidak mengeluarkan kunci apa pun, sehingga mencegah penulisan apa pun hingga memori dibebaskan. Solusi untuk masalah seperti itu adalah mengonfigurasi Redis dengan memori maksimal dan beberapa kebijakan penggusuran. Dalam hal ini, server mulai mengeluarkan kunci menggunakan kebijakan eviction karena penggunaan memori mencapai maksimum.
Memori RSS (Ukuran Set Penghuni) adalah jumlah byte yang telah dialokasikan sistem operasi ke Redis. Jika rasio 'memory_rss' ke 'memory_used' lebih besar dari ~1,5, maka itu menandakan fragmentasi memori. Memori yang terfragmentasi dapat dipulihkan dengan memulai ulang server.
3. Rasio Cache Hit
Rasio cache hit menunjukkan efisiensi penggunaan cache. Secara matematis, ini didefinisikan sebagai (Total key hit)/ (Total key hit + Total key misses).
“statistik info ” perintah menyediakan keyspace_hits &keyspace_misses data metrik untuk menghitung lebih lanjut rasio hit cache untuk instance Redis yang sedang berjalan.
127.0.0.1:6379> info stats # Stats ............. sync_partial_err:0 expired_keys:10 evicted_keys:12 keyspace_hits:4 keyspace_misses:15 pubsub_channels:0 pubsub_patterns:0 .............
Jika rasio hit cache lebih rendah dari ~0,8 maka sejumlah besar kunci yang diminta akan dikeluarkan, kedaluwarsa, atau tidak ada sama sekali. Sangat penting untuk memperhatikan metrik ini saat menggunakan Redis sebagai cache. Rasio hit cache yang lebih rendah menghasilkan latensi yang lebih besar karena sebagian besar permintaan mengambil data dari disk. Ini menunjukkan bahwa Anda perlu menambah ukuran cache Redis untuk meningkatkan kinerja aplikasi Anda.
4. Koneksi Aktif
Jumlah koneksi adalah sumber daya terbatas yang diterapkan oleh sistem operasi atau oleh konfigurasi Redis. Memantau koneksi aktif membantu Anda memastikan bahwa Anda memiliki koneksi yang cukup untuk melayani semua permintaan Anda pada waktu puncak.
5. Kunci Digusur/Kedaluwarsa
Redis mendukung berbagai kebijakan penggusuran yang digunakan oleh server ketika penggunaan memori mencapai batas maksimal. Nilai positif yang terus-menerus dari metrik ini merupakan indikasi bahwa Anda perlu meningkatkan memori.
127.0.0.1:6379> info stats # Stats .............. sync_partial_err:0 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 ..............
Redis mendukung TTL (waktu untuk hidup) properti untuk setiap kunci. Server menghapus kunci jika TTL terkait telah berlalu. Jika aplikasi tidak menentukan properti ini, ini menyebabkan data yang kedaluwarsa menumpuk di memori. Nilai metrik positif menunjukkan bahwa data kedaluwarsa Anda sedang dibersihkan dengan benar.
6. Metrik Replikasi
‘connected_slaves’ metrik menginformasikan keterjangkauan server budak ke master. Ketidakterjangkauan slave dapat menyebabkan latensi baca yang lebih tinggi bergantung pada beban baca di server.
127.0.0.1:6379> info replication # Replication role:master/slave connected_slaves:0/master_slave_io_seconds_ago:0 master_repl_offset:0 ..............
‘master_slave_io_seconds_ago ' metrik memberi tahu berapa banyak waktu yang berlalu selama komunikasi antara seorang budak dan tuannya. Nilai yang lebih tinggi untuk metrik ini dapat menjadi indikasi masalah pada master/slave atau beberapa masalah jaringan. Ini lebih lanjut menyebabkan budak menyajikan data basi.
Kesimpulan
Kami telah menyebutkan beberapa metrik penting yang akan memberikan visibilitas yang baik tentang kesehatan dan kinerja server database Anda. Mungkin ada orang lain yang relevan dengan server basis data khusus Anda dan kasus penggunaan. Kami akan merekomendasikan untuk membaca dan memahami semua metrik yang dilaporkan oleh perintah “info”.
Jika Anda memerlukan bantuan untuk mengelola hosting AWS untuk penerapan Redis™, jangan ragu untuk menghubungi kami melalui email di [email protected] atau di Twitter @scalegridio.
