一个cifs获取文件属性导致getattr请求数变多【网上问题】的定位过程

前言 本文为原创，可能会存在一些知识点或理解上的问题，欢迎切磋和交流  ^_^

特此说明：

以下内容是我在攻关定位某局点问题时的一些思路，不涉及实际具体业务、实际具体问题、实际具体代码流程，仅仅是个人的一点心得和总结。

1、问题背景

这周客户现场设备升级版本后，客户cifs访问共享目录出了一个性能问题，通过cifs访问NAS共享目录时，mds日志getattr请求数剧增，导致mds出现性能瓶颈；当有大量业务存在时，访问共享卡顿。

2、问题描述

通过cifs访问共享目录，后台mds查看日志getattr请求数量剧增，初步分析和当前版本cifs获取文件属性getattr请求整个I/O栈实现的方案有关系。

3、问题定位过程

3.1 按测试操作步骤进行操作对比验证

目前怀疑是两个版本之间getattr请求从samba层到ceph内核层，再到mds层整个IO栈实现方案不同导致出现该问题，目前要确定的是通过验证测试得出两组数据，从而确定到底是哪个流程哪行代码导致请求数增多，这个是问题定位的核心思路。

一开始按照测试的想法进行对比验证，相关操作如下表所示：

同理，B版本如上统计相关数据，并对比，得出数据后，对比两个版本，并未得出和现象相一致的规律，也感到很奇怪。这里其实是犯了错误的，这样统计数据只是简单拿数据说话，我们期望数据反映的和我们想的相一致，即我们认为可能是内核io实现出了问题，那么理所当然，统计验证数据应该是内核态请求数量增高才对，这才符合预期，但实际的数据是错误的！这个过程一共犯了两个错误：

1. 数据统计出错，导致看不出规律；
2. 不能只统计数据，mds层要统计是哪些请求，这些请求个数分别是多少；

所以，此次对比验证测试说白了，没有得出想要的结果，浪费了时间。如果数据准确无误，是可以直接得出结论。

3.2 拆分测试动作

调整测试策略，针对性能问题攻关定位，如果大概明确了是具体版本问题，那么在做差异化对比测试验证时，要把测试用例规划尽可能详细，只有这样，后面做的工作才不至于无效，得出的数据才是有用的。测试策略如下：

1. 进入多层深度目录操作(只点击目录，不刷新操作)
2. 单层目录多文件刷新操作(只做刷新动作)

因为开始的测试策略有问题，导致数据不准确，从新添加调试信息，确保数据统计准确；另外在mds层不仅仅统计getattr请求数量，不同请求也区别开来。得出数据后，

得出结论：

1.samba层、ceph层请求个数相一致，但是mds层请求个数不同；

2.两个版本mds层请求种类不同，有差异；

此时就有了怀疑点：是否是xxxA系统调用导致getattr请求数增多？

但是分析代码流程，该系统调用并不存在异常点；同时，两个版本对比数据也可以确认该系统调用并无嫌疑，故排除；

3.3 单目录单文件刷新

进一步单例化测试步骤，采用单目录单文件结构，只做刷新操作，结果发现mds层请求种类依然不同。

提出怀疑点：xxxB系统调用本身是否有问题

3.4 写demo验证xxx系统调用

要验证是否xxxB系统调用本身的问题，单独编写一个demo，看调用情况是否一致，执行后发现mds层同样有多种不同请求，即验证了怀疑点。

4、定位总结

以上内容总结起来有两点关键：

对比数据(包含不同的请求、请求个数)；

通过请求种类，提出怀疑点，确定是谁的问题导致。