好的，各位老铁，大家好！我是你们的老朋友，人称“代码诗人”的程序猿张三。今天咱们不聊风花雪月，也不谈人生理想，就来聊聊一个听起来有点深奥，但实际上跟咱们 Redis 小日子息息相关的家伙：vm.overcommit_memory。
开场白：一场关于内存的“信用透支”
想象一下，你是一家公司的老板，手里管着一大笔钱（服务器内存）。每天都有各种项目（进程）来找你申请经费（内存）。正常情况下，你会根据自己的家底（实际物理内存）来批钱。但是，如果你突然脑洞大开，决定搞个“信用透支”计划，允许项目们申请的总经费超过你的实际家底，那会发生什么呢？
这就是 vm.overcommit_memory 试图解决的问题，或者说，埋下的坑。🤣
第一幕：vm.overcommit_memory 是个啥？
vm.overcommit_memory 是 Linux 内核中的一个参数，它决定了内核如何处理进程的内存分配请求。简单来说，它控制着内核是否允许“过度承诺”内存。
-
0(Heuristic overcommit): 这是默认值。内核会尝试猜测是否有足够的内存可用。它会考虑当前已分配的内存、交换空间以及一些启发式算法。但是，这个猜测并不总是准确的，尤其是当你的应用涉及到大量的内存映射文件时。 -
1(Always overcommit): 胆子最大的选项！内核会无条件地允许所有内存分配请求，即使这意味着系统最终会耗尽内存。这就像你给所有项目开了无限额度的信用卡，后果自负。 -
2(Don’t overcommit): 最保守的选项。内核会严格检查是否有足够的内存可用，并且拒绝任何可能导致内存耗尽的分配请求。这就像你只允许项目们花你实际拥有的钱，一分也不多给。
用表格总结一下：
| 值 | 名称 | 描述 | 风险 |
|---|---|---|---|
| 0 | Heuristic overcommit | 内核尝试猜测是否有足够的内存可用。 | 猜测可能不准确，在高负载情况下可能导致 OOM (Out Of Memory) |
| 1 | Always overcommit | 内核允许所有内存分配请求，即使这意味着系统最终会耗尽内存。 | 风险最高！系统可能会崩溃或者触发 OOM Killer，随机杀死进程来释放内存。 |
| 2 | Don’t overcommit | 内核会严格检查是否有足够的内存可用，并且拒绝任何可能导致内存耗尽的分配请求。 | 应用程序可能会因为无法分配到足够的内存而崩溃或无法启动。 |
第二幕：vm.overcommit_memory 如何影响 Redis？
Redis，作为一款高性能的内存数据库，对内存的依赖程度可想而知。vm.overcommit_memory 的设置直接影响 Redis 的运行状态。
-
vm.overcommit_memory = 0：- 优点： 在大多数情况下，这都是一个合理的选择。系统会尽力避免内存耗尽。
- 缺点： 在某些高负载情况下，内核的猜测可能会出错。如果 Redis 试图分配一大块内存（比如 RDB 持久化或者 AOF 重写），而内核错误地认为内存不足，Redis 可能会收到
ENOMEM错误，导致操作失败。更糟糕的是，如果系统真的耗尽了内存，OOM Killer 可能会毫不留情地杀死 Redis 进程。💔
-
vm.overcommit_memory = 1：- 优点： Redis 可以尽情地申请内存，理论上不会因为内存不足而失败。
- 缺点： 风险极高！这就像饮鸩止渴。如果 Redis 真的耗尽了内存，系统可能会崩溃或者 OOM Killer 会随机杀死其他进程来释放内存，甚至包括 Redis 自己。这会导致数据丢失或者服务中断。☠️
-
vm.overcommit_memory = 2：- 优点： 最安全的选择。可以保证系统不会因为内存耗尽而崩溃。
- 缺点： Redis 可能会因为无法分配到足够的内存而启动失败或者在运行时出现错误。这可能会限制 Redis 的性能和容量。
第三幕：Redis 的应对之策：overcommit_memory 和 oom-score-adj
Redis 开发者也不是吃素的，他们早就考虑到了 vm.overcommit_memory 带来的问题，并提供了相应的解决方案。
-
overcommit_memory配置项 (Redis 4.0+):
这个配置项允许 Redis 自身来决定如何处理内存分配请求。它可以覆盖操作系统的vm.overcommit_memory设置。yes： 默认值。Redis 会像vm.overcommit_memory = 1一样，允许过度承诺内存。no： Redis 会像vm.overcommit_memory = 2一样，拒绝过度承诺内存。
-
oom-score-adj配置项:- 这个配置项允许你调整 Redis 进程的 OOM 评分。OOM Killer 会根据进程的 OOM 评分来决定哪个进程应该被杀死。
- 你可以通过设置
oom-score-adj来降低 Redis 进程的 OOM 评分，从而降低 Redis 被 OOM Killer 杀死的概率。
第四幕：最佳实践：如何配置 vm.overcommit_memory 和 Redis？
那么，问题来了，到底应该如何配置 vm.overcommit_memory 和 Redis 才能达到最佳效果呢？这是一个需要根据实际情况权衡的问题。
-
场景一：小内存服务器，对数据安全性要求极高
vm.overcommit_memory = 2：确保系统不会因为内存耗尽而崩溃。Redis: overcommit_memory no：强制 Redis 拒绝过度承诺内存。Redis: maxmemory：设置 Redis 的最大内存使用量，避免 Redis 占用过多的内存。Redis: oom-score-adj：适当降低 Redis 的 OOM 评分，但不要过度降低，以免影响其他进程。
风险： Redis 可能会因为内存不足而无法执行某些操作。
-
场景二：大内存服务器，对性能要求极高，允许一定程度的数据丢失
vm.overcommit_memory = 0：让内核自己去判断，并观察系统运行状况。Redis: overcommit_memory yes：允许 Redis 过度承诺内存。Redis: maxmemory：设置 Redis 的最大内存使用量，但可以设置得相对较高。Redis: oom-score-adj：适当降低 Redis 的 OOM 评分，但要注意监控系统内存使用情况。
风险： 系统可能会因为内存耗尽而触发 OOM Killer，导致 Redis 数据丢失。
-
场景三：中等内存服务器，需要平衡性能和安全性
vm.overcommit_memory = 0：让内核自己去判断，并观察系统运行状况。Redis: overcommit_memory no：强制 Redis 拒绝过度承诺内存，避免风险。Redis: maxmemory：设置 Redis 的最大内存使用量，留出一定的缓冲空间。Redis: oom-score-adj：适当降低 Redis 的 OOM 评分，但要注意监控系统内存使用情况。
总结：没有银弹，只有权衡
配置 vm.overcommit_memory 和 Redis 就像走钢丝，需要在性能、安全性和可用性之间找到一个平衡点。没有一劳永逸的解决方案，只有根据实际情况不断调整和优化。
记住，以下几点至关重要：
- 理解
vm.overcommit_memory的含义和风险。 - 根据服务器的内存大小和应用场景选择合适的配置。
- 设置 Redis 的
maxmemory，避免 Redis 占用过多的内存。 - 适当调整 Redis 的
oom-score-adj，降低 Redis 被 OOM Killer 杀死的概率。 - 密切监控系统内存使用情况，及时发现和解决问题。
彩蛋：一些额外的建议
- 使用 Redis Sentinel 或 Cluster: 这些高可用方案可以保证在 Redis 节点发生故障时，服务仍然可用。
- 定期进行 RDB 持久化或者 AOF 重写: 即使发生了数据丢失，也可以通过恢复备份来减少损失。
- 使用内存分析工具: 比如
memtier_benchmark或者redis-cli --bigkeys来分析 Redis 的内存使用情况，找出内存瓶颈。 - 升级服务器内存: 如果预算允许，增加服务器内存是最直接有效的解决方案。
结尾：内存管理，永无止境
好了，各位老铁，关于 vm.overcommit_memory 对 Redis 内存的影响，今天就先聊到这里。内存管理是一个复杂而又重要的课题，需要我们不断学习和探索。希望今天的分享能对你有所帮助。记住，代码的世界里没有绝对的真理，只有不断地尝试和优化。
下次再见！👋