当前位置 : 主页 > 编程语言 > 其它开发 >

记一次NAS故障分析(ZFS NFS)

来源:互联网 收集:自由互联 发布时间:2022-05-22
问题: 使用vdbench进行单层100w目录,每个目录30个文件,共3000w文件读写时,在创建文件得时候IO会出现断断续续得情况。 分析过程: 1、 nfs抓包分析 使用vdbench创建一个文件得流程eg:

问题:

         使用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的在服务器端正常释放缓存后,没啥问题。

 

网友评论