一起 MINIO(Go) 响应慢故障实录分析

挖坑的张师傅

发布于 2024-06-19 20:25:16

2090

发布于 2024-06-19 20:25:16

文章被收录于专栏：张师傅的博客

前段时间我们边缘部署的 minio 出现下载和删除文件都很慢的问题，严重影响了相关业务功能，因此进行了分析和解决。本文记录了完整的分析过程, 涉及了以下几个方面：

使用 strace 分析系统调用
使用 trace-cmd 观测内核函数堆栈和事件
NFS 协议及 noac 选项介绍
minio 删除文件的流程分析

问题概述

我们遇到的主要问题有两个：

下载 minio 中存储的文件时, 概率性地会长时间无响应, 导致相关页面的视频点播失败
存储服务器的 2PB 容量已达 97%, 触发了写保护, 无法继续写入。为释放空间, 需要先删除旧数据, 但删除 minio 中的文件异常缓慢, 导致删除进度不达预期

第一个问题是最先暴露的，出问题的时候，curl 文件长时间无返回：

引发了如下视频点播失败:

第二个问题是晚一点暴露的，存储服务器的容量是 2PB，在前段时间已经达到了 97%，触发了存储服务器的写保护，导致所有的写入删除都失败了。不得不停止写入，关闭写保护，想办法先删除数据，腾出容量。在删除数据的过程中，发现删除接口非常慢，导致我们没法在短时间内释放容量，开放上传功能。

这两个问题，都是指向了 minio 接口慢，于是进行了一系列的分析，过程记录如下。

部署架构

部署架构如下，客户端通过 NFS 协议挂载了由存储供应商提供的 4 节点 2PB 总容量存储集群, 在其上运行 minio 服务, 存储大量 1MB~4MB 的小文件。

为更好理解后续分析, 我们先简单介绍一下 NFS 协议原理。

NFS 协议简介

通过 tcpdump 抓包, 可以观察到使用 NFS 协议读取一个文件的典型过程如下:


cat /mnt/ya/file.mb > /dev/null

读取/mnt/ya/file.mb 文件时, 涉及到 3 个文件/文件夹的 fileHandle:

0x7867b7e8: /mnt
0x3b936eb4: /mnt/ya
0x2977a4cf: /mnt/ya/file.mb

可以看到读取 /mnt/ya/file.mb 经历了下面这几步：

获取 /mnt 的文件夹属性
判断是否有 /mnt 文件夹的访问权限
在 /mnt 目录查找 ya 文件夹的 filehandle，查到是 0x3b936eb4
判断是否有 /mnt/ya 文件夹的访问权限
获取 /mnt/ya 文件夹属性
在 /mnt/ya 目录查找 file.mb 文件的 filehandle，查到是 0x2977a4cf
判断是否有 /mnt/ya/file.mb 的访问权限
获取 /mnt/ya/file.mb 的文件属性
读取 /mnt/ya/file.mb 文件

这么来看 NFS 协议是一个低效的协议，读取一个文件的过程就是逐层判断是否有权限。为了优化减少网络请求，默认情况下，NFS 客户端会缓存文件和目录的属性（如权限、大小和时间戳），以减少对 NFS 服务器的远程过程调用的需求。

初步排查接口慢

通过观察 minio 进程的线程状态, 发现绝大部分线程都处于不可中断的 D 状态, 推测它们可能被阻塞在文件 IO 操作上。

minio 是 go 语言开发的，得益于 go 方便的 profile 机制，可以非常方便看到 goroutine 的堆栈信息。MinIO 的 mc 工具（MinIO Client）是一个现代化的命令行工具，提供了类似于 UNIX 命令（如 ls、cat、cp、mirror、admin）的功能。我们可以通过它提供的 admin profile 功能来触发 Go 的 profile。

使用下面的命令采集 goroutine 的数据

$ ./mc admin profile start --type=goroutines minio/

# 等待一段时间

# 停止 profile，会生成 profile.zip 文件
$ ./mc admin profile stop minio/

$ unzip profile.zip

$ ls -l

-rw------- 1 root root  35K 6月   7 18:57 profile-127.0.0.1:9000-goroutines.txt
-rw------- 1 root root  36K 6月   7 18:57 profile-127.0.0.1:9000-goroutines-before.txt
-rw------- 1 root root 1.5M 6月   7 18:57 profile-127.0.0.1:9000-goroutines-before,debug=2.txt
-rw-r--r-- 1 root root 512K 6月   7 18:57 profile.zip

查看生成的 profile 文件，我们发现大量的接口阻塞在系统调用上，根据不同的文件操作，有些阻塞在 .syscallopenat（打开文件）、syscall.fstatat（查看文件信息）、syscall.unlinkat（删除文件）等。

通过这个 profile 我们可以确定是 minio 发起了系统调用，到了内核 nfs 模块，但 nfs 模块迟迟未返回响应，导致 minio 长时间阻塞在系统调用上。

至此已经不是 minio 这个 go 程序能处理的了。出问题的时候，通过 ls 命令直接去查看 nfs 的文件，一样会卡住无返回。

为进一步分析 NFS 内核行为, 我们使用 trace-cmd 工具查看所有 NFS 相关事件。

trace-cmd record -e "nfs:*"

发现 minio 频繁执行 nfs_refresh_inode 操作, fhandle 为 0x463b99f0

经过分析，频繁触发的 fhandle 是一个文件夹，路径是 /mnt/minio107054/data1/store-pub，除此之外还有一个文件夹 inode 更新非常频繁 /mnt/minio107054/data1/.minio.sys。

不仅是 minio 表现是这样，当我直接执行 ls 的时候，trace-cmd 的输出也是如此。

这两个文件夹的 refresh inode 操作都返回了 invalid data 错误, 提示 inode 缓存数据无效。

为深入追踪内核行为, 我们使用 trace-cmd 的 function_graph 功能分析内核函数调用栈。以 stat /mnt/minio107054/data1/store-pub/xxx.ts 为例:

trace-cmd record -p function_graph -F  stat /mnt/minio107054/data1/store-pub/xxx.ts

会生成一个非常长的内核函数调用栈文件，我们先来确定哪个函数耗时较长。

通过这个调用栈，我们可以清晰的看到，是 fstatat 这个系统调用执行了近 260s（4 分钟+）之久。中间执行的函数有 70 多万行。我们来具体看下这 70 多万行到底发生了什么。

到这里我们基本上清楚了，系统调用慢的原因是，由于大目录属性频繁变更, 导致 inode 缓存数据失效, NFS 客户端需要不断从 NFS 服务器获取最新的 inode 数据。为了解决这个问题，存储原厂的工程师提议我们启用 noac 挂载选项来禁用客户端的属性缓存来临时规避这个问题。

使用 noac 选项可以禁用文件和目录属性的缓存。这样每次客户端访问文件属性时，都会直接从 NFS 服务器获取最新的数据，而不是使用本地缓存的数据。这样可以临时绕开上面这类 /mnt/minio107054/data1/store-pub 大文件夹的属性变更的影响。但是会大大增加网络通信的次数，但是这明显会好过长时间卡在属性更新上。

启用 noac 以后，删除依然非常慢，大并发下需要 20 多秒才能删除一个文件，接下来我们来解决删除慢的问题。

文件删除为什么慢

我们接下来接续分析为什么删除文件会慢。因为删除文件会触发系统调用，我们可以用 strace 来观测文件删除的过程。

strace -tt -T -f  -p `pidof minio` -o strace.out

通过 strace 追踪, 发现 minio 删除一个文件如 store-pub/xxx.ts 实际会删除以下四个文件:

数据文件 store-pub/xxx.ts
元数据文件 .minio.sys/buckets/store-pub/xxx.ts/fs.json （文件）
空文件夹 .minio.sys/buckets/store-pub/xxx.ts
非空文件夹 .minio.sys/buckets/store-pub（删除会失败）

strace 可以显示系统调用的时间和返回值。通过看 strace 日志我们发现删除最后一个非空文件夹 .minio.sys/buckets/store-pub 时，一定会失败，返回 ENOTEMPTY（文件夹非空），耗时长达 10 几秒到 20 几秒。

实际上, 这一删除操作是多余的。这个元数据目录是 bucket 的根目录，除非 bucket 下所有文件都被删完，否则不可能是空的。

minio 这一部分删除的逻辑可谓简单粗暴，比如你要删除 /a/b/c/d.txt，你可以指定 base_path，比如 /a，它的删除逻辑是尝试递归所有上层目录，直到遇到 basepath 或者删除失败。

删除 /a/b/c/d.txt
删除 /a/b/c/
删除 /a/b
尝试删除 /a，发现与 base_path 相等，退出

这种实现方式实现比较简单，删除文件的同时，可以删除这个文件路径上所有的空目录。

这里删除元数据文件时 .minio.sys/buckets/store-pub/xxx.ts/fs.json，它传入的 base_path 是 .minio.sys/buckets/

const minioMetaBucket = ".minio.sys";
minioMetaBucketDir := pathJoin(fs.fsPath, minioMetaBucket)

if bucket != minioMetaBucket {
 // Delete the metadata object.
 // fsMetaPath = minio.sys/buckets/store-pub/xxx.ts/fs.json
 // minioMetaBucketDir = 
 err = fsDeleteFile(ctx, minioMetaBucketDir, fsMetaPath)
 if err != nil && err != errFileNotFound {
  return objInfo, toObjectErr(err, bucket, object)
 }
}

// basePath：要往上删到哪一级路径
// deletePath：要删除文件的路径
func fsDeleteFile(ctx context.Context, basePath, deletePath string) error {
}

于是修改 minio 源码，增加 basePath 的层级到 minio.sys/buckets/store-pub