3 ms·
The bigger problem is that because of how awesome Redis is, it tends to get used for lots of things and RAM is finite. There's lots of configurations for Redis
by rubiquity 11y ago
The bigger problem is that because of how awesome Redis is, it tends to get used for lots of things and RAM is finite. There's lots of configurations for Redis for how it handles running out of memory and nobody looks at these until they've run out of RAM and important things start disappearing. I can't count how many Rails apps I've encountered that use Redis for all or a mix of caching, background queues, pubsub, and list operations.
- pselbert 11y agoRAM is finite whether you're using it with Redis or Memcached. Redis provides multiple databases (0-16) for just this situation. Use one db for caching, another for Sidekiq, and another for ad-hoc tasks. Redis can also be configured to evict entries with an expiration first, which means cached data will be cycled through while the important bits linger safely.
- itamarhaber 11y agoNot a good idea, I'm afraid. Your ad-hoc will cause the caching to stutter and the job queues to stagger. Redis is a single-threaded server and shared databases, well, share the same process. The common practice is to use dedicated Redis servers, one for each database. This also has the nice side benefit of allowing you config each as needed (e.g. LRU eviction for cache, persistency for jobs, etc...)