记一次NAS故障分析（ZFS NFS）

问题：

使用vdbench进行单层100w目录，每个目录30个文件，共3000w文件读写时，在创建文件得时候IO会出现断断续续得情况。

分析过程：

1、  nfs抓包分析

使用vdbench创建一个文件得流程eg: vdb_f0398.file：

Lookup call -> lookup reply ->create call ->create reply ->write call ->write reply

2、  当vdbench IO归0时，观察存储端状态

1）  read IO特别大，write IO为0

看4标识

2）  zfs arc到了limit点为，arc_prune数值增加，意味着频繁得回收arc，但arc大小为变化

看上图1是设定的arc_meta_limit，2是已经使用的arc_meta空间，一般触发回收时会高出limit限制几百M，3是回收次数。其在arc_meta使用触发回收时短时间内多次回收调用，但是回收的arc空间很少，之后不再回收，导致arc一直是full的状态。

3）  arc相关参数变化

没有释放arc

看图5标识，此处为有写IO时，此时为readdir执行完了一次后，在对应的目录下创建了30个文件（vdbech配置的）。

4）  使用perf分析进程变化情况

发现进程lz4_decompress_zfs 进程变化比较明显

5）  通过dump_stack打印lz4的调用栈：

从打印情况看两个可疑点，出问题的时候zfs_readdir 和 reconnect_path被不停的调用

6）  从这两个地方分析是否存在问题

1》  zfs_readdir其dump_stack情况

分析内部代码，打印事件发现：

会发现while执行的次数和时间会随着目录数的增加线性增长，100w目录查询一次一般会超过10s（8s-180s,当时应该受到arc回收影响，没出现IO归零时不会调用到此函数）

2》  reconnect_path情况

出现问题时，exportfs参数没有收到期望的具体vdb.1_6795.dir目录名，而是根目录/(注意此处设置nfsd thread数为1，默认是32，会进行32次根目录的调用，其造成阻塞的概率增大，并耗时非常长)

由此触发了zfs_readdir

此处引出问题，为什么参数会是根目录？？？？

7）  当arc缓存开始执行回收操作时，出现问题

而多次回收内存并未释放多少，前面图示可以看出。

8）  由上联合起来分析汇总：

当arc使用接近限制阈值的时候，触发回收操作，而回收操作只回收一点，但将原来的目录缓存破坏掉，使用新创建的文件元数据来填充arc，大量的arc缓存无法释放。导致当服务器端nfs执行 lookup确定要创建的文件是否合法时，触发了reconnect_path->zfs_readdir等操作，来进行所有目录的重新匹配，而此时arc已经满了无法缓存，导致接下来的每次lookup都要执行一遍readdir。

此处引出问题，为什么缓存释放不了？？？

3、  由上分析，猜测服务器vdbench缓存了inode，dentry等信息

通过在跑vdbench IO时，观察服务器内存使用情况发现，随着创建文件夹和文件，内存使用明显

尝试在存储端arc接近缓存阈值时，清除服务器的缓存，主要是dentry、inode信息。多次测试发现问题不再重现。Arc可以正常释放，并且释放速度较快。

4、  综上确定问题出现vdbenc IO，在创建文件夹和文件的时候会影响zfs ARC缓存释放，引出问题：

1）  vdbench 在没有创建完文件之前会维护这些link？

2）  Nfs客户端做的缓存？

3）  此现象对其他公司nas产品是否一样？

4）  需要存储端解决此问题？如何解决？

5、arc小于2G回收会出问题这个大概率是之前的因素影响，还在分析代码并测试中~~。测试了一次1.5G的在服务器端正常释放缓存后，没啥问题。