Redis에서 OOM command not allowed when used memory > 'maxmemory'가 보이면 가장 먼저 이해해야 할 것은, 이것이 보통 프로세스 죽음이 아니라 정책과 메모리 압박의 조합이라는 점입니다. 메시지는 강하게 보이지만, 실제 incident는 Redis가 압박 아래에서 어떻게 반응할 수 있는지와 더 관련이 있는 경우가 많습니다.
핵심은 먼저 maxmemory를 확인하고, 다음으로 maxmemory-policy를 확인하고, 실패한 명령이 현재 정책 아래에서 비워줄 수 없는 추가 메모리를 요구했는지를 보는 것입니다.
이 OOM 메시지가 보통 뜻하는 것
Redis의 maxmemory는 절대 넘지 않는 숫자라기보다, 넘었을 때 어떤 정책을 적용할지 결정하는 기준에 가깝습니다.
보통 아래 조건이 겹칠 때 OOM 스타일 에러가 납니다.
- 메모리 압박이 존재한다
- 명령이 추가 메모리를 필요로 한다
- 현재 정책이 그 write 경로에 맞는 key를 비워주지 못한다
즉 문제는 단순히 서버 RAM이 모자라다가 아니라 eviction 동작과 workload shape에 더 가깝습니다.
maxmemory와 정책부터 확인하세요
첫 확인은 아래 세 가지면 충분합니다.
maxmemory가 무엇인가maxmemory-policy가 무엇인가- 현재 workload가 eviction에 의존하는 구조인가
정책이 noeviction이면 추가 메모리가 필요한 write 명령은 key를 비우는 대신 실패합니다.
정책이 volatile-* 계열이면 TTL이 있는 key만 eviction 대상입니다. 앱은 cache-like key가 다 사라질 수 있다고 기대했는데 정책은 그렇지 않다면, Redis는 정상 동작 중이어도 incident는 놀랍게 보일 수 있습니다.
정책에 따라 결과가 달라지는 이유
이 에러는 정책 동작과 연결해서 보면 훨씬 이해가 쉽습니다.
대표 패턴은 이렇습니다.
noeviction: 메모리를 더 먹는 write가 실패volatile-*: TTL 있는 key만 후보allkeys-*: 모든 key가 eviction 대상
앱이 오래된 cache entry가 자동으로 사라질 것을 기대하지만 실제 정책이 그걸 허용하지 않으면 OOM 에러는 쉽게 납니다.
정책 자체를 더 넓게 보고 싶다면 Redis Eviction Policy Guide를 바로 같이 보는 것이 좋습니다.
흔한 근본 원인
1. 메모리 압박과 noeviction
Redis가 설정 ceiling에 도달했고, 들어오는 write를 위해 비워줄 경로가 없습니다.
2. eviction 가능한 key가 앱 기대와 다름
앱은 어떤 데이터를 비울 수 있다고 생각하지만, 실제 정책은 더 좁은 범위만 비웁니다.
3. big key나 예상보다 큰 write
단일 작업이 순간적으로 큰 메모리를 요구하면 직전까지 멀쩡하던 시스템도 갑자기 실패할 수 있습니다.
4. TTL 가정이 틀림
만료됐어야 할 key가 살아 있으면 메모리가 계속 차 있고 eviction 여지도 줄어듭니다.
5. 호스트 RAM보다 Redis ceiling이 먼저 닿음
운영체제 레벨 RAM은 남아 있어도 Redis는 자신의 설정 상한을 강하게 적용할 수 있습니다.
실전 점검 순서
- 현재 메모리 사용량을 확인한다
maxmemory를 확인한다maxmemory-policy를 확인한다- 실패한 명령이 데이터를 늘리거나 새로 할당하는지 본다
- 기대했던 cache key가 실제로 TTL을 갖고 있는지 확인한다
- big key가 문제를 더 날카롭게 만드는지 확인한다
이 순서로 보면 capacity 문제인지, 정책 불일치인지, write 패턴 문제인지 빨리 갈라집니다.
바로 확인할 명령
redis-cli INFO memory
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy
redis-cli --bigkeys이 명령으로 Redis가 설정 ceiling에 닿았는지, 현재 정책이 eviction을 허용하는지, unusually large key가 메모리 압박을 키우는지 확인할 수 있습니다.
초반 분기에 좋은 shortcut
이 에러가 보이면 아래처럼 먼저 갈라보세요.
- 정책이
noeviction이다: 압박 아래서 예상 가능한 write failure 먼저 - 정책이
volatile-*인데 TTL이 없다: eviction candidate mismatch 먼저 - 정책은 eviction 가능하지만 큰 key가 많다: workload shape 먼저
- host memory는 멀쩡한데 Redis만 거절한다: host crash보다 Redis ceiling 먼저
이 분기만으로도 incident가 훨씬 덜 미스터리해집니다.
증상별 진입 힌트
- Redis가
OOM command not allowed를 돌려주는데 앱은 여전히 write를 보내고 있다면 여기서 시작하면 됩니다. - key가 사라지는 쪽이 먼저 보이면 eviction policy 가이드와 같이 보세요.
- 이 에러가 없어도 메모리가 계속 높다면 Redis Memory Usage High도 같이 보세요.
FAQ
Q. 이 에러가 뜨면 Redis가 죽은 건가요?
아니요. 보통은 현재 정책 아래에서 메모리를 더 먹는 명령을 거절한 것입니다.
Q. 해결책은 항상 메모리 증설인가요?
아니요. 정책 변경, 데이터 크기 축소, TTL 복구, write burst 완화가 더 직접적인 해결책인 경우도 많습니다.
Q. 왜 어떤 명령만 실패하고 read는 되나요?
이 에러는 보통 추가 메모리가 필요한 명령에서만 발생하기 때문입니다.
Q. 가장 먼저 확인할 것은 무엇인가요?
maxmemory, maxmemory-policy, 그리고 workload가 실제로 가능한 eviction에 의존하고 있는지입니다.
Read Next
- 핵심이 정책 동작이라면 Redis Eviction Policy Guide를 보세요.
- 핵심이 만료 동작 누락이라면 Redis Keys Not Expiring를 보세요.
- 핵심이 전체 메모리 압박이라면 Redis Memory Usage High를 보세요.
Related Posts
Sources:
- https://redis.io/docs/latest/develop/reference/eviction/
- https://redis.io/faq/doc/1jbxid5qq7/is-maxmemory-the-maximum-value-of-used-memory
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.