企业官网建设流程全解析

JuiceFS 怎么用 stats 命令实时观察性能指标定位故障

【免费下载链接】juicefsJuiceFS is a distributed POSIX file system built on top of Redis and S3.项目地址: https://gitcode.com/GitHub_Trending/ju/juicefs

文件系统挂载后出现性能异常——读吞吐上不去、元数据操作变慢、对象存储流量莫名偏高——光看日志很难快速定位瓶颈在哪一层。JuiceFS 的juicefs stats子命令用于解决这个问题：它读取挂载点上 JuiceFS Client 的内部指标数据，以类似dstat的格式按秒刷新实时性能数据，覆盖进程资源、FUSE 层、元数据引擎、本地缓存和对象存储五个层面，帮助你在故障发生时直接观察每一层的吞吐、时延和请求量，从而判断瓶颈位置。

前提条件：

• 文件系统已经通过juicefs mount挂载成功，且你知道挂载点路径（下例用/mnt/jfs）；
• 命令需要在挂载点所在的主机上运行，因为它是从挂载点内部的指标文件读取数据的。

运行 stats 命令并认识输出结构

最短主路径就一条命令：

juicefs stats /mnt/jfs

执行后终端会按默认 1 秒的刷新间隔持续输出，直到按 Ctrl-C 停止。需要更多指标时提高详细级别：

# More metrics juicefs stats /mnt/jfs -l 1

命令的完整用法为juicefs stats [command options] MOUNTPOINT，常用选项（见 命令参考）：

注意：参数必须是挂载点根路径。命令会检查该路径的 inode，如果不是挂载点，会直接报path "xxx" is not a mount point并退出，所以传入挂载点下的某个子目录是不行的。

命令输出的区段含义，以 故障诊断文档 对各项指标的解释为准：

usage——进程资源

• cpu：进程 CPU 使用率；
• mem：进程使用的物理内存；
• buf：当前读/写 buffer 大小。文档给出的判断标准是：如果这个值持续接近甚至超过配置的--buffer-size，应该增大 buffer 或降低应用负载；
• cache：内部指标，可忽略。

fuse——FUSE 层

• ops/lat：FUSE 每秒处理的操作数及其平均时延（毫秒）；
• read/write：FUSE 层的读/写带宽。

meta——元数据引擎

• ops/lat：每秒处理的元数据操作数及平均时延。注意：直接由缓存返回的操作不计入，以便展示客户端真正与元数据引擎交互时的更准确时延；
• txn/lat：元数据引擎每秒处理的写事务数及平均时延。getattr这类只读请求只计入ops，不计入txn（txn在-l 1时才显示）；
• retry：元数据引擎每秒重试的写事务数。

blockcache——本地数据缓存

• read/write：客户端本地数据缓存的读/写带宽。

object——对象存储

• get/get_c/lat：对象存储处理读请求的带宽、每秒请求数和平均时延（毫秒）；
• put/put_c/lat：处理写请求的带宽、每秒请求数和平均时延；
• del_c/lat：删除请求的每秒数量和平均时延。

对照指标定位三类典型问题

运行stats的同时让业务负载跑起来，按下面的判断路径逐项排查。每一条的判定依据都来自文档，观察到的数值只用于对照趋势，不是固定阈值。

对象存储流量远大于实际读流量：排查读放大

这是文档明确给出stats用途的场景之一：开启缓存后，读请求穿透到对象存储会显著拖慢读性能，可以用这些指标检查数据是否已被缓存；同时对比object.get和fuse.read的流量，可以粗略判断当前的读放大状态。

典型的读放大现象是对象存储流量远大于客户端读速度，例如文档中的例子：客户端以 200MiB/s 读取，而 S3 流量涨到 2GiB/s。定位流程（见 Troubleshooting Cases）：

1. 在stats中确认object.get带宽显著高于fuse.read带宽；
2. 采集一段时间的访问日志来确认访问模式：

# Collect access log for a period of time, like 30 seconds: cat /jfs/.accesslog | grep -v "^#$" >> access.log # 简单统计操作类型 grep "read (" access.log | wc -l

3. 文档中的诊断结论：如果日志显示应用在对同一个大文件做频繁的随机小读（read操作第三个参数 offset 在相邻两次之间大幅跳变），预取的块无法被有效利用（块默认 4MiB），此时可以把--prefetch设为 0 关闭预取并发，重新挂载后问题消除。

重复读同一文件时 blockcache 仍有持续读流量

文档说明：已经由内核 page cache 处理的读请求不会计入blockcache读指标。因此，如果你对同一个固定文件做重复读，却仍然看到持续的blockcache读流量，说明读请求根本没有进入 page cache，文档建议朝这个方向排查（例如内存不足）。

buffer 长期贴近上限：调整 --buffer-size

usage区的buf指标对应--buffer-size控制的读/写 buffer（cache 文档给出其默认值为 300 MiB）。文档给出了几条明确的判断与操作方向：

• buf持续接近或超过配置的--buffer-size时，增大 buffer 或降低应用负载；
• 顺序读单个大文件时，如果stats显示buf已经接近一半满，说明可以增大--buffer-size来扩大预读窗口（单文件顺序读的预读空间约为总 buffer 的 1/4 到 1/2）；
• 写方向：如果已增大--max-uploads但上传流量没有明显增长，考虑再增大--buffer-size；反过来，增大--buffer-size没有带来上传流量增长时，应同时增大--max-uploads；
• 低带宽环境下，--buffer-size同时决定每次flush的上传数据量，可能需要调低--buffer-size以避免 flush 超时（见 Troubleshooting Cases 中对象存储连接问题一节）。

验证指标数据与进一步深入

stats的数据来源是挂载点内的指标文件，可以直接查看原始内容做交叉验证：

# 假设挂载点是 /jfs cat /jfs/.stats

也可以通过挂载后自动暴露的 Prometheus 格式地址（默认http://localhost:9567/metrics，可用--metrics选项自定义）查看完整指标：

curl http://localhost:9567/metrics

如果需要的是“每次文件操作慢在哪一步”而不是聚合指标，文档提供了互补的手段：juicefs profile MOUNTPOINT基于访问日志对每个文件系统操作做实时统计可视化，还可以回放已保存的访问日志：

# 提前采集访问日志 cat /jfs/.accesslog > /tmp/juicefs.accesslog # 复现性能问题后，回放日志文件定位瓶颈 juicefs profile -f /tmp/juicefs.accesslog

此外，juicefs debug MOUNTPOINT可以自动收集版本、内核信息、.config内容、.stat文件快照（间隔 5 秒记录两次）、挂载命令行参数、Go pprof 信息和最近 5000 行日志到debug目录，适合在问题发生时一次性打包留档，便于事后分析或提交给支持方。

适用边界

• stats只观察聚合层面的指标，单次操作的耗时分布要结合juicefs profile和访问日志看；
• 指标含义以官方文档为准：meta的ops不含缓存直接命中的操作，blockcache的read不含 page cache 已处理的读，object区的带宽是客户端与对象存储之间的实际流量，不要把这些口径混用后再下结论；
• 各项lat单位是毫秒，ops/txn/get_c等每秒数量是相对--interval间隔的速率值。

【免费下载链接】juicefsJuiceFS is a distributed POSIX file system built on top of Redis and S3.项目地址: https://gitcode.com/GitHub_Trending/ju/juicefs