Memcached stats命令详解与性能优化实践

1. Memcached stats 命令概述

Memcached作为高性能的分布式内存对象缓存系统，其内置的stats命令是运维人员和开发者最常用的诊断工具之一。通过stats命令，我们可以获取Memcached实例的运行状态、性能指标和内存使用情况等关键信息，这对于监控系统健康状态、排查性能瓶颈和优化缓存策略至关重要。

在实际生产环境中，我经常遇到这样的场景：某个应用的响应速度突然变慢，经过初步排查发现可能是缓存层出现了问题。这时候stats命令就成了我的第一把"手术刀"，它能快速揭示缓存命中率、内存使用率、连接数等核心指标，帮助我快速定位问题根源。

与常见的redis-cli info命令不同，Memcached的stats命令提供了更细粒度的分类统计，包括items、slabs、settings等子命令，每个子命令都对应着特定维度的监控数据。这种设计使得我们可以针对性地获取某类信息，而不必每次都获取全部统计数据，这在大型分布式系统中尤为重要。

2. 基础stats命令详解

2.1 基本语法与连接方式

要使用stats命令，首先需要通过telnet或nc工具连接到Memcached服务器。以下是基本的连接方式：

bash复制telnet 127.0.0.1 11211

连接成功后，直接输入"stats"命令即可获取基础统计信息：

code复制stats

在我的实际使用中，更推荐使用nc(netcat)工具，因为它能更好地处理批量命令和自动化脚本：

bash复制echo "stats" | nc 127.0.0.1 11211

这个基础命令会返回几十行关键指标，每行格式为"STAT <指标名> <值>"。例如：

code复制STAT pid 12345
STAT uptime 3600
STAT time 1625097600
STAT version 1.6.9
...

2.2 核心指标解析

stats命令返回的指标中，以下几个最为关键：

1. 命中率相关：

   • get_hits：成功获取缓存项的次数
   • get_misses：未命中缓存的次数
   • 命中率 = get_hits / (get_hits + get_misses)

   在我的经验中，健康的系统通常应该保持90%以上的命中率。如果低于这个值，可能需要考虑调整缓存策略或扩容。

2. 内存使用相关：

   • bytes：当前存储的字节数
   • limit_maxbytes：配置的最大内存限制
   • mem_allocated：实际分配的内存总量

   需要特别注意的是，当bytes接近limit_maxbytes时，Memcached会开始淘汰旧数据，这时命中率往往会急剧下降。

3. 连接与性能相关：

   • curr_connections：当前连接数
   • total_connections：历史总连接数
   • cmd_get：总get命令数
   • cmd_set：总set命令数

   我曾经遇到过一个案例，curr_connections异常高导致性能下降，最终发现是客户端没有正确关闭连接造成的。

3. 高级stats子命令详解

3.1 stats items：监控缓存项分布

stats items命令提供了关于缓存中所有item的详细信息，特别是按slab分类的统计。执行方式：

code复制stats items

返回结果示例：

code复制STAT items:1:number 123
STAT items:1:age 3600
STAT items:2:number 456
...

这个命令特别有用的一点是，它可以帮助我们发现"热点"slab class。我曾经通过这个命令发现某个特定大小的对象被频繁访问，导致对应的slab class成为瓶颈，最终通过调整对象大小分布解决了问题。

3.2 stats slabs：内存分配详情

stats slabs命令展示了Memcached内存分配的核心机制——slab allocator的详细信息：

code复制stats slabs

返回结果中，每个slab class都会有一组详细的统计信息：

code复制STAT 1:chunk_size 96
STAT 1:chunks_per_page 10922
STAT 1:total_pages 1
STAT 1:total_chunks 10922
STAT 1:used_chunks 10921
...

理解这些数据对于优化内存使用至关重要。例如，当某个slab class的used_chunks接近total_chunks时，说明该大小的对象非常密集，可能需要调整增长因子(-f参数)来优化内存分配。

3.3 stats settings：运行时配置

stats settings命令显示了Memcached实例的当前配置参数：

code复制stats settings

返回结果包括：

code复制STAT maxbytes 67108864
STAT maxconns 1024
STAT tcpport 11211
STAT growth_factor 1.25
...

这些信息在调试配置问题时非常有用。我曾经遇到过客户端连接被拒绝的情况，通过检查maxconns发现配置值设置过低，调整后问题解决。

4. 实战应用与问题排查

4.1 性能瓶颈诊断案例

去年我们遇到一个线上问题：缓存响应时间偶尔会突然升高。通过stats命令，我们进行了如下排查：

1. 首先检查基础stats：

   code复制echo "stats" | nc 127.0.0.1 11211
   

   发现get_misses异常高，但内存使用率(bytes)只有60%

2. 接着检查items分布：

   code复制echo "stats items" | nc 127.0.0.1 11211
   

   发现某些slab class的evicted值很高

3. 最后检查slabs：

   code复制echo "stats slabs" | nc 127.0.0.1 11211
   

   发现某些slab class的used_chunks接近total_chunks

最终结论是：虽然总体内存使用率不高，但特定大小的对象过于集中，导致这些slab class频繁淘汰数据。解决方案是调整应用层，将大对象拆分为更均匀的大小分布。

4.2 内存泄漏排查技巧

Memcached本身不会泄漏内存，但不当的使用方式可能导致内存无法有效利用。以下是我总结的排查步骤：

1. 监控bytes增长趋势：

   code复制watch -n 1 "echo stats | nc 127.0.0.1 11211 | grep bytes"
   

2. 检查items的age分布：

   code复制echo "stats items" | nc 127.0.0.1 11211 | grep age
   

   如果age值普遍很大，说明缓存项很少被更新或淘汰

3. 分析slab利用率：

   code复制echo "stats slabs" | nc 127.0.0.1 11211 | grep -E 'total_chunks|used_chunks'
   

通过这些数据，可以判断是否存在某些长期不被使用但又占用大量内存的缓存项。

5. 监控与自动化实践

5.1 命令行监控技巧

对于临时性的监控，可以使用watch命令结合stats：

bash复制watch -n 1 "echo stats | nc 127.0.0.1 11211 | grep -E 'bytes|get_hits|get_misses|curr_items'"

这个命令会每秒刷新一次关键指标，非常适合快速诊断。

5.2 脚本化监控方案

对于生产环境，我通常会编写shell脚本定期收集stats数据：

bash复制#!/bin/bash

HOST="127.0.0.1"
PORT="11211"
LOG_FILE="/var/log/memcached_stats.log"

STATS=$(echo "stats" | nc $HOST $PORT)
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")

{
    echo "===== $TIMESTAMP ====="
    echo "$STATS" | grep -E 'bytes|get_hits|get_misses|curr_items|evictions|limit_maxbytes'
    echo ""
} >> $LOG_FILE

这个脚本可以配置为cron任务，每5分钟运行一次，记录关键指标的历史趋势。

5.3 与监控系统集成

对于更专业的监控，可以将stats数据导入Prometheus等监控系统。以下是使用memcached_exporter的配置示例：

yaml复制scrape_configs:
  - job_name: 'memcached'
    static_configs:
      - targets: ['memcached-exporter:9150']
    metrics_path: /metrics
    params:
      target: ['memcached-server:11211']

这种方案可以提供更丰富的仪表盘和告警功能。

6. 常见问题与解决方案

6.1 连接数过高问题

症状：curr_connections持续高位，可能伴随性能下降。

解决方案：

1. 检查客户端连接池配置，确保合理复用连接
2. 适当增加maxconns参数
3. 使用stats conns命令分析连接来源

6.2 内存碎片问题

症状：内存使用率不高，但频繁出现evictions。

解决方案：

1. 调整slab增长因子(-f参数，通常1.05-1.25)
2. 预热缓存，提前分配slab
3. 考虑使用多个小实例替代单个大实例

6.3 命中率低问题

症状：get_misses比例过高，响应时间增加。

解决方案：

1. 增加内存容量
2. 优化缓存键设计，提高复用率
3. 调整过期策略，避免同时大量失效

在实际操作中，我发现很多命中率问题其实源于应用层设计不当，比如缓存键过于随机或缺乏一致性。这时候单纯调整Memcached参数可能收效甚微，需要与应用开发人员协同优化。