什么是 Memcached 与 slabs 机制
在现代 Web 应用中，缓存是提升性能的关键一环。Memcached 是一个广泛使用的分布式内存缓存系统，它能将频繁访问的数据存储在内存中，从而大幅减少数据库查询压力。尤其在高并发场景下，Memcached 的响应速度几乎是瞬时的。
但你是否想过，Memcached 是如何高效管理内存的？这就要提到它的核心机制之一：slabs（分 slab）。简单来说，Memcached 不会像传统内存管理那样“按需分配”，而是预先将内存划分为多个固定大小的块，这些块被称为 slab classes。
想象一下，你有一个巨大的仓库，里面存放着不同尺寸的箱子。如果每次来货都临时找箱子，效率很低。而 Memcached 的做法是：提前准备好 100 个 1KB 的箱子、100 个 2KB 的箱子、100 个 4KB 的箱子……这就是 slab 的工作方式。每个 slab class 管理一种固定大小的内存块，当有数据要存储时，直接从对应大小的 slab 中分配一个块即可，避免了频繁的内存碎片和分配开销。
那么，如何查看这些 slab 的状态？这就引出了今天的主角：stats slabs 命令。
使用 Memcached stats slabs 命令查看 slab 信息
stats slabs 是 Memcached 提供的一个诊断命令，用于获取所有 slab class 的详细运行状态。它能告诉你每个 slab 的使用情况、命中率、内存分配情况等，是排查缓存性能问题的重要工具。
要使用这个命令，你需要通过 telnet 或 nc 连接到 Memcached 服务器的监听端口（默认是 11211）：
telnet 127.0.0.1 11211
连接成功后，输入以下命令：
stats slabs
回车后，你会看到类似下面的输出：
STAT slabs 1 1
STAT slabs 2 2
STAT slabs 3 3
...
STAT total_malloced 123456789
END
这些信息中，每一行代表一个 slab class。我们来逐行分析。
分析 stats slabs 的输出字段
stats slabs 的输出格式是：
STAT <slab_id> <field_name> <value>
其中 slab_id 是 slab class 的编号，从 1 开始递增。每个 slab class 对应一种固定大小的内存块。
下面是一个典型的输出示例，并附上详细注释：
STAT 1 number 1000
STAT 1 bytes 1024
STAT 1 curr_items 500
STAT 1 total_items 800
STAT 1 used_chunks 500
STAT 1 free_chunks 500
STAT 1 chunk_size 1024
STAT 1 number 1000：表示 slab class 1 共有 1000 个 chunk（内存块）。STAT 1 bytes 1024：这是 slab class 1 的总字节数，即 1000 × 1024 = 1,024,000 字节。STAT 1 curr_items 500：当前正在使用的 chunk 数量，即 500 个数据项被缓存。STAT 1 total_items 800：从启动以来，总共分配过 800 个数据项。STAT 1 used_chunks 500：当前已被占用的 chunk 数量，和curr_items基本一致。STAT 1 free_chunks 500：当前空闲的 chunk 数量，说明有 500 个空位可用于新数据。STAT 1 chunk_size 1024：每个 chunk 的大小是 1024 字节。
从这些数据可以看出，当前 slab class 1 的使用率为 50%（500 / 1000），说明还有较大空间。
了解 slab 的内存分配规律
Memcached 的 slab 大小是按 1.25 倍递增的。例如：
- slab 1：1024 字节
- slab 2：1280 字节（1024 × 1.25）
- slab 3：1600 字节
- slab 4：2000 字节
- ...
这种设计是为了在内存利用率和分配效率之间取得平衡。如果 slab 太小，分配大量小对象时会浪费内存；如果 slab 太大，存储小数据时会浪费空间。
你可以通过以下命令查看所有 slab 的 chunk 大小：
stats slabs
然后观察 chunk_size 字段，你会发现它们呈指数增长。
💡 小贴士：如果发现某个 slab 的
free_chunks很少，而curr_items很高，说明该 slab 类型的数据使用频繁，但内存紧张，可能需要调整缓存策略或增加 Memcached 实例。
实际案例：分析缓存命中率与 slab 使用
假设你发现系统响应变慢，怀疑是缓存问题。你可以通过 stats slabs 结合 stats items 来综合分析。
先查看 slab 状态：
stats slabs
输出示例：
STAT 1 chunk_size 1024
STAT 1 curr_items 800
STAT 1 total_items 1200
STAT 1 used_chunks 800
STAT 1 free_chunks 200
STAT 2 chunk_size 1280
STAT 2 curr_items 600
STAT 2 total_items 1000
STAT 2 used_chunks 600
STAT 2 free_chunks 400
再查看所有 item 的统计信息：
stats items
输出：
STAT items:1:age 120
STAT items:1:hits 15000
STAT items:1:misses 2000
STAT items:2:age 90
STAT items:2:hits 12000
STAT items:2:misses 1500
...
END
通过对比：
- slab 1：命中率 = 15000 / (15000 + 2000) ≈ 88.2%
- slab 2：命中率 = 12000 / (12000 + 1500) ≈ 88.9%
命中率不错，但 slab 1 的 free_chunks 只有 200，说明接近满载。如果继续写入，可能会出现“内存不足”或“淘汰旧数据”的情况。
此时可以考虑：
- 优化缓存键设计，避免存储过大数据；
- 增加 Memcached 实例，分摊压力；
- 或者调整 slab 的大小策略（通过启动参数
-S控制）。
如何优化 slab 使用？常见问题与建议
问题 1：大量 slab 的 free_chunks 为 0
这说明某些 slab 类型已经耗尽，新数据无法分配，Memcached 会开始淘汰旧数据（LRU 策略）。这可能导致缓存命中率下降。
解决方法：查看 stats slabs 中哪些 slab 的 free_chunks 为 0，再用 stats items 查看对应 slab 的 hits 和 misses，判断是否是热点数据导致。
问题 2：内存浪费严重，总 malloced 很高
运行 stats malloced 可以看到总分配内存。如果 total_malloced 远大于实际缓存数据大小，说明存在内存浪费。
检查 stats slabs 中的 free_chunks 总和，如果很多 slab 都有大量空闲 chunk，但实际数据不多，说明 slab 大小设置不合理，可尝试调整启动参数。
问题 3：频繁的淘汰（evictions）
通过 stats settings 查看 eviction 设置。如果 evict_to_free 为 on，说明 Memcached 会主动淘汰旧数据。这在内存紧张时是正常行为，但若频繁发生，应优化 slab 分配。
总结：掌握 Memcached stats slabs 命令的实用价值
Memcached stats slabs 命令 是每一位使用 Memcached 的开发者都应掌握的核心工具。它不仅能让你清晰地看到内存分配情况，还能帮助你诊断缓存性能瓶颈、优化缓存策略。
通过分析 slab 的 curr_items、free_chunks、chunk_size 等字段，你可以判断哪些数据类型占用了大量内存，哪些 slab 已经接近满载，从而做出针对性优化。
在实际项目中，建议定期监控 stats slabs 输出，结合 stats items 和 stats cachedump 命令，构建完整的缓存健康度评估体系。这不仅能提升系统稳定性，还能为后续的性能调优提供数据支持。
记住：缓存不是越多越好，而是“恰到好处”。掌握 stats slabs，就是掌握内存分配的“显微镜”，让你的系统运行更高效、更稳定。