Redis Đầy RAM Trên VPS: Cấu Hình maxmemory, Eviction Và Persistence Đúng Cách

Redis thường được dùng làm cache, session store, queue hoặc datastore tốc độ cao. Vì phần lớn dữ liệu nằm trong RAM, một Redis instance tăng không kiểm soát có thể chiếm gần hết memory của VPS và kéo theo:

• Linux swap mạnh;
• latency tăng;
• application process bị thiếu RAM;
• OOM killer dừng Redis hoặc process khác;
• persistence rewrite gây spike RAM/I/O;
• VPS mất ổn định.

Điều quan trọng nhất là xác định Redis của bạn đang đóng vai trò gì:

1. cache có thể tái tạo;
2. session/queue cần hạn chế mất dữ liệu;
3. primary datastore cần durability cao hơn.

Từ đó mới chọn maxmemory, eviction policy và persistence.

Kiểm tra Redis đang dùng bao nhiêu RAM

Kết nối:

redis-cli INFO memory

Một số field đáng chú ý:

used_memory
used_memory_human
used_memory_rss
used_memory_peak
maxmemory
maxmemory_policy
mem_fragmentation_ratio

Hoặc lấy nhanh:

redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy|mem_fragmentation_ratio'

used_memory là memory Redis allocator đang dùng cho dữ liệu/cấu trúc nội bộ.

used_memory_rss phản ánh lượng RAM process thực sự resident trong OS và có thể lớn hơn do fragmentation/allocator behavior.

Kiểm tra RAM toàn VPS

free -h

Và process:

ps -o pid,%mem,rss,cmd -C redis-server

Đừng đặt maxmemory bằng 100% RAM VPS.

Host còn cần RAM cho:

• kernel;
• filesystem cache;
• application;
• Nginx/PHP/Node;
• monitoring agent;
• Redis fork trong RDB/AOF rewrite;
• replication/AOF buffers nếu có.

maxmemory là gì?

Redis Open Source hỗ trợ directive:

maxmemory 2gb

Khi dataset tiến tới giới hạn này, Redis áp dụng maxmemory-policy để quyết định:

• xóa key nào;
• hoặc từ chối write mới.

Trên 64-bit Redis, nếu maxmemory bằng 0 thì dataset không bị giới hạn bởi setting này và chỉ bị ràng buộc bởi RAM hệ thống/OS.

Đây là lý do Redis dùng làm cache trên VPS nên có memory ceiling rõ ràng.

Đặt maxmemory bao nhiêu?

Không có tỷ lệ cố định đúng cho mọi VPS.

Ví dụ VPS 8 GB RAM chạy:

• app: ~2 GB peak;
• Redis: ~3 GB target;
• Nginx/agent/OS/cache: phần còn lại.

Bạn có thể bắt đầu Redis ở 3 GB thay vì 7–8 GB để có headroom.

Cách tốt hơn là đo:

• application peak RSS;
• Redis peak memory;
• fork overhead;
• persistence rewrite;
• traffic peak.

Sau đó mới chọn giới hạn.

Đặt runtime bằng CONFIG SET

Ví dụ:

redis-cli CONFIG SET maxmemory 3gb

Đặt policy:

redis-cli CONFIG SET maxmemory-policy allkeys-lru

Nhưng thay đổi runtime có thể không tồn tại sau restart nếu không được ghi vào config.

Redis hỗ trợ:

redis-cli CONFIG REWRITE

nếu config source cho phép rewrite.

Trước production, nên quản lý cấu hình bằng file/config management rõ ràng thay vì thay tay rồi quên.

Các eviction policy quan trọng

noeviction

maxmemory-policy noeviction

Khi đạt giới hạn, Redis không tự xóa key để tạo chỗ cho write mới. Command cần thêm memory sẽ trả lỗi.

Phù hợp khi:

• dữ liệu không được phép tự mất;
• ứng dụng phải xử lý backpressure/error;
• Redis được dùng như datastore hơn là cache.

Không phù hợp nếu app không xử lý lỗi write và sẽ sập dây chuyền.

allkeys-lru

maxmemory-policy allkeys-lru

Redis ưu tiên loại các key ít được sử dụng gần đây nhất trong toàn bộ keyspace.

Đây là lựa chọn phổ biến cho cache chung khi mọi key đều có thể tái tạo.

allkeys-lfu

maxmemory-policy allkeys-lfu

Ưu tiên giữ key được truy cập thường xuyên và loại key có tần suất thấp.

Có thể tốt hơn LRU khi workload có tập “hot key” ổn định.

volatile-lru

Chỉ xét các key có TTL.

Nếu một số key không có TTL, chúng không thuộc tập bị eviction bởi policy này.

volatile-ttl

Ưu tiên loại key có TTL còn ngắn hơn.

Chọn policy theo use case

Use case	Policy thường cân nhắc
Cache thuần, mọi key tái tạo được	allkeys-lru / allkeys-lfu
Chỉ cache key có TTL	volatile-lru / volatile-lfu
Data không được tự xóa	noeviction
Muốn ưu tiên key sắp hết hạn	volatile-ttl

Đây không phải quy tắc cứng. Hãy test hit rate và behavior của ứng dụng.

Theo dõi eviction

redis-cli INFO stats | grep evicted_keys

Nếu evicted_keys tăng nhanh:

• memory limit có thể quá thấp;
• cache key tăng nhanh;
• TTL chưa hợp lý;
• workload thay đổi.

Eviction không nhất thiết là lỗi nếu Redis là cache. Nhưng nếu hit rate giảm mạnh và database phía sau bị tăng tải, bạn cần điều chỉnh.

Kiểm tra keyspace và TTL

redis-cli INFO keyspace

Scan TTL cần thận trọng với dataset lớn.

Không nên chạy:

redis-cli KEYS '*'

trên production lớn vì KEYS có thể block server đáng kể.

Dùng SCAN:

redis-cli --scan | head

Hoặc sampling/tool chuyên dụng.

Big key có thể làm memory tăng bất thường

Redis CLI có:

redis-cli --bigkeys

Lệnh này scan keyspace và giúp phát hiện key lớn theo type.

Với production lớn, chạy vào thời điểm phù hợp vì vẫn tạo workload scan.

Một key list/hash/set cực lớn có thể là vấn đề thiết kế hơn là chỉ thiếu RAM.

Redis persistence có những lựa chọn nào?

Redis Open Source hỗ trợ:

• RDB snapshot;
• AOF;
• không persistence;
• kết hợp RDB + AOF.

Nếu Redis chỉ là cache có thể tái tạo từ database, persistence có thể không cần.

Nếu Redis giữ session, queue hoặc dữ liệu quan trọng, cần đánh giá durability rõ ràng.

RDB snapshot

RDB tạo snapshot point-in-time của dataset theo điều kiện save.

Ví dụ config:

save 900 1
save 300 10
save 60 10000

Ý nghĩa: tạo snapshot khi số giây/số write thỏa điều kiện tương ứng.

Ưu điểm:

• file compact;
• restart thường nhanh;
• phù hợp backup định kỳ;
• ít overhead ghi liên tục hơn AOF.

Nhược điểm:

• crash có thể mất các thay đổi sau snapshot gần nhất;
• fork snapshot có thể tạo memory pressure trên dataset lớn.

AOF

Bật:

appendonly yes

AOF ghi lại write operation và replay khi restart.

Policy fsync phổ biến:

appendfsync everysec

Các mode khác:

always
no

everysec thường là trade-off giữa durability và performance: có khả năng mất khoảng dữ liệu gần nhất nếu hệ thống crash trước lần fsync tiếp theo.

Redis 7+ dùng multi-part AOF

Redis hiện đại dùng cơ chế multi-part AOF gồm base file và incremental file, được quản lý qua manifest.

Điều này khác nhiều tutorial cũ giả định chỉ có một file appendonly.aof duy nhất.

Đừng viết script backup AOF bằng cách chỉ copy một file tên cố định mà chưa kiểm tra cấu trúc phiên bản Redis đang dùng.

RDB + AOF có nên bật cả hai?

Redis documentation khuyến nghị cân nhắc cả hai khi dữ liệu quan trọng:

• AOF cung cấp durability tốt hơn;
• RDB vẫn hữu ích cho snapshot/backup và recovery nhanh trong một số tình huống.

Nhưng cả hai tăng:

• disk I/O;
• storage;
• fork/rewrite workload;
• operational complexity.

Cache thuần không nhất thiết cần cả hai.

Persistence và disk space

Kiểm tra:

df -h

Xem Redis data directory:

redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename
redis-cli CONFIG GET appenddirname

AOF rewrite và RDB snapshot cần đủ disk headroom.

Nếu disk gần đầy, Redis có thể gặp lỗi persistence dù RAM vẫn còn.

Xem bài VPS Ubuntu bị đầy ổ đĩa để xử lý capacity tổng thể.

Theo dõi RDB status

redis-cli INFO persistence

Quan tâm các field như:

rdb_last_bgsave_status
rdb_last_save_time
rdb_bgsave_in_progress
aof_enabled
aof_last_write_status
aof_rewrite_in_progress

Nếu rdb_last_bgsave_status hoặc aof_last_write_status không phải ok, cần điều tra ngay nếu Redis giữ dữ liệu quan trọng.

Fork và Copy-on-Write

Khi Redis tạo RDB hoặc rewrite AOF, nó có thể fork process con.

Linux sử dụng copy-on-write, nhưng nếu dataset đang bị write mạnh trong lúc fork/rewrite, memory bổ sung có thể tăng đáng kể.

Đó là lý do không nên đặt maxmemory quá sát tổng RAM VPS khi persistence được bật.

Swap có giúp Redis không OOM?

Swap có thể ngăn OOM trong một số tình huống nhưng Redis rất nhạy với latency.

Nếu Redis page bị swap ra disk, response time có thể tăng mạnh.

Hãy xem swap như lớp an toàn, không phải nơi chứa dataset thường xuyên.

Nếu VPS phải swap Redis liên tục, nên giảm dataset, hạ maxmemory, scale RAM hoặc tách Redis sang máy riêng.

Redis làm cache: một cấu hình khởi điểm

Ví dụ conceptual:

maxmemory 3gb
maxmemory-policy allkeys-lfu
appendonly no

Phù hợp khi:

• dữ liệu cache tái tạo được;
• không cần durability;
• muốn giữ key “hot”.

Nhưng nếu mất Redis khiến backend database bị thundering herd, bạn vẫn cần thiết kế warm-up/rate limiting.

Redis giữ session

Có thể cân nhắc:

maxmemory 3gb
maxmemory-policy noeviction
appendonly yes
appendfsync everysec

Nếu session không được phép bị eviction ngẫu nhiên.

Tuy nhiên, noeviction nghĩa write có thể lỗi khi chạm giới hạn. Application phải xử lý tình huống này.

Redis cho queue

Queue thường không nên dùng eviction policy xóa message “ít dùng”.

noeviction hoặc kiến trúc queue chuyên dụng có thể phù hợp hơn.

Nếu queue backlog tăng không giới hạn, memory limit chỉ giúp phát hiện vấn đề chứ không sửa consumer throughput.

Security: Redis không nên public Internet

Kiểm tra listener:

sudo ss -tulnp | grep 6379

Redis production thường nên:

• bind localhost/private IP;
• firewall đúng source;
• dùng ACL/password phù hợp;
• không public 6379 ra Internet;
• dùng TLS nếu architecture yêu cầu.

Memory tuning không có ý nghĩa nếu Redis bị truy cập trái phép.

Monitoring nên có

Theo dõi:

• used_memory;
• used_memory_rss;
• maxmemory;
• eviction count;
• keyspace hit/miss;
• connected clients;
• blocked clients;
• persistence errors;
• fork duration;
• disk usage.

Nếu đã có Prometheus/Grafana, bạn có thể dùng Redis exporter phù hợp và alert trước khi memory chạm trần. Xem Giám sát VPS bằng Prometheus và Grafana.

Cache hit rate

redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'

Tính đơn giản:

hit rate = hits / (hits + misses)

Nếu eviction tăng mạnh và hit rate giảm, memory pressure đang làm cache kém hiệu quả.

Slowlog

Redis có slowlog để tìm command tốn thời gian:

redis-cli SLOWLOG LEN
redis-cli SLOWLOG GET 10

Command nặng trên structure lớn có thể làm event loop bị block dù CPU/RAM chưa chạm trần.

maxmemory không bao gồm mọi loại memory giống nhau

Redis có nhiều vùng memory nội bộ và buffer. Với replication hoặc persistence, một số buffer có behavior riêng.

Vì vậy:

maxmemory = tổng RAM VPS

là thiết kế nguy hiểm.

Luôn để headroom.

Sai lầm thường gặp

Redis cache nhưng dùng noeviction

Khi đầy RAM, write mới lỗi thay vì tự loại cache cũ.

Redis giữ session nhưng dùng allkeys-lru

Session có thể bị xóa do pressure dù chưa hết TTL.

Bật AOF nhưng không theo dõi disk

AOF/rewrite có thể làm storage tăng.

Đặt maxmemory quá sát RAM VPS

Persistence fork và OS/app khác có thể khiến OOM.

Dùng KEYS * trên production lớn

Có thể block Redis trong lúc scan toàn bộ keyspace.

Checklist production

• Xác định Redis là cache hay datastore.
• Đặt maxmemory với headroom.
• Chọn eviction policy theo use case.
• Theo dõi evicted_keys.
• Dùng TTL hợp lý cho cache.
• Chọn RDB/AOF theo RPO.
• Theo dõi persistence status.
• Chừa RAM cho fork/rewrite.
• Theo dõi disk.
• Không public port 6379.
• Monitor hit rate và slowlog.

FAQ

Redis có tự giới hạn RAM không?

Nếu maxmemory không được đặt trên Redis 64-bit, dataset có thể tăng cho tới khi OS/RAM trở thành giới hạn thực tế. Production nên đặt ceiling rõ ràng.

Cache nên dùng allkeys-lru hay allkeys-lfu?

Cả hai đều hợp lý. LRU ưu tiên recency, LFU ưu tiên frequency. Hãy benchmark hit rate với workload thật.

Redis có cần AOF nếu chỉ dùng cache?

Không nhất thiết. Nếu cache có thể tái tạo và downtime warm-up chấp nhận được, persistence có thể tắt để đơn giản hóa.

RDB có mất dữ liệu không?

Có thể mất thay đổi kể từ snapshot gần nhất nếu process/server crash trước snapshot tiếp theo.

AOF everysec có tuyệt đối không mất dữ liệu không?

Không. Nó cân bằng performance/durability và vẫn có thể mất khoảng write gần nhất trong một số failure scenario.

Kết luận

Redis trên VPS ổn định khi ba quyết định được làm rõ: RAM ceiling bao nhiêu, khi đầy thì xóa key nào, và dữ liệu cần bền tới mức nào.

Đừng chỉ tăng RAM mỗi khi Redis gần đầy. Hãy đặt maxmemory, chọn eviction policy đúng use case, kiểm soát TTL và thiết kế persistence theo RPO thực tế.

Nếu Redis đã được tối ưu nhưng working set hợp lệ vẫn tăng đều và cần nhiều RAM hơn, bạn có thể tham khảo các dịch vụ VPS tại HUONG CLOUD và lựa chọn cấu hình dựa trên memory peak, persistence overhead và traffic thực tế.

Nguồn tham khảo

• Redis Docs — Key eviction: https://redis.io/docs/latest/develop/reference/eviction/
• Redis Docs — Persistence: https://redis.io/docs/latest/management/persistence/