Kami telah mengalami masalah berkelanjutan dengan bertukar instance ElastiCache Redis kami. Amazon tampaknya memiliki beberapa pemantauan internal mentah di tempat yang pemberitahuan menukar lonjakan penggunaan dan hanya me-restart instance ElastiCache (sehingga kehilangan semua item cache kami). Berikut grafik BytesUsedForCache (garis biru) dan SwapUsage (garis oranye) pada instance ElastiCache kami selama 14 hari terakhir:
Anda dapat melihat pola meningkatnya penggunaan swap yang tampaknya memicu reboot instance ElastiCache kami, di mana kami kehilangan semua item yang di-cache kami (BytesUsedForCache turun ke 0).
Tab 'Acara Cache' di dasbor ElastiCache kami memiliki entri yang sesuai:
ID Sumber | Ketik | Tanggal | Peristiwa
cache-instance-id | cache-cluster | Sel 22 Sep 07:34:47 GMT-400 2015 | Cache node 0001 dimulai kembali
cache-instance-id | cache-cluster | Sel 22 Sep 07:34:42 GMT-400 2015 | Kesalahan me-restart mesin cache pada node 0001
cache-instance-id | cache-cluster | Minggu, 20 Sep 11:13:05 GMT-400 2015 | Cache node 0001 dimulai kembali
cache-instance-id | cache-cluster | Kamis 17 Sep 22:59:50 GMT-400 2015 | Cache node 0001 dimulai kembali
cache-instance-id | cache-cluster | Rabu 16 Sep 10:36:52 GMT-400 2015 | Cache node 0001 dimulai kembali
cache-instance-id | cache-cluster | Sel 15 Sep 2011 05:02 GMT-400 2015 | Cache node 0001 dimulai kembali
(snip entri sebelumnya)
SwapUsage - dalam penggunaan normal, baik Memcached maupun Redis tidak harus melakukan swap
Pengaturan kami yang relevan (tidak standar):
- Jenis contoh:
cache.r3.2xlarge
maxmemory-policy
: allkeys-lru (kami telah menggunakan default volatile-lru sebelumnya tanpa banyak perbedaan)maxmemory-samples
: 10reserved-memory
: 2500000000- Memeriksa perintah INFO pada instance, saya melihat
mem_fragmentation_ratio
antara 1,00 dan 1,05
Kami telah menghubungi dukungan AWS dan tidak mendapatkan banyak saran yang berguna: mereka menyarankan agar memori yang dicadangkan lebih tinggi (standarnya adalah 0, dan kami memiliki cadangan 2,5 GB). Kami tidak memiliki replikasi atau snapshot yang disiapkan untuk instance cache ini, jadi saya percaya tidak ada BGSAVE yang seharusnya terjadi dan menyebabkan penggunaan memori tambahan.
The maxmemory
cap dari cache.r3.2xlarge adalah 62495129600 byte, dan meskipun kita memukul topi kami (minus kami reserved-memory
) cepat, tampaknya aneh bagi saya bahwa sistem operasi host akan merasa tertekan untuk menggunakan begitu banyak Swap di sini, dan begitu cepat, kecuali Amazon telah menghidupkan pengaturan swappiness OS untuk beberapa alasan. Adakah ide mengapa kita menyebabkan begitu banyak penggunaan swap pada ElastiCache / Redis, atau solusi yang dapat kita coba?