从接口超时到RAID
李成亚约 6 分钟进一步想，既然根源在于 IO 高，那么所有的 IO 类操作都会被影响到，比如应用的 logback 日志、 tomcat 的 access 日志、甚至于我们在宿主上执行的 IO 类命令（tail、grep......）。
# 第一列为响应时间，第二列为时间点
117 [02/Mar/2024:11:36:36
91 [02/Mar/2024:11:36:36
4055 [02/Mar/2024:11:36:43
5716 [02/Mar/2024:11:36:43
5654 [02/Mar/2024:11:36:43
3419 [02/Mar/2024:11:36:43
5727 [02/Mar/2024:11:36:43
5361 [02/Mar/2024:11:36:43
6769 [02/Mar/2024:11:36:43
6222 [02/Mar/2024:11:36:43
1932 [02/Mar/2024:11:36:43
6808 [02/Mar/2024:11:36:43
3705 [02/Mar/2024:11:36:43
6818 [02/Mar/2024:11:36:43
6388 [02/Mar/2024:11:36:43
5713 [02/Mar/2024:11:36:43
2609 [02/Mar/2024:11:36:43
2614 [02/Mar/2024:11:36:43
1989 [02/Mar/2024:11:36:43
6154 [02/Mar/2024:11:36:43
4531 [02/Mar/2024:11:36:43
5211 [02/Mar/2024:11:36:43
4753 [02/Mar/2024:11:36:43
6432 [02/Mar/2024:11:36:43
6420 [02/Mar/2024:11:36:43
223 [02/Mar/2024:11:36:43
2271 [02/Mar/2024:11:36:43
6602 [02/Mar/2024:11:36:43
...
...
...
339 [02/Mar/2024:11:38:57
155 [02/Mar/2024:11:38:57
154 [02/Mar/2024:11:38:57
3831 [02/Mar/2024:11:39:00
4856 [02/Mar/2024:11:39:04
4002 [02/Mar/2024:11:39:04
5740 [02/Mar/2024:11:39:04
4285 [02/Mar/2024:11:39:04
5803 [02/Mar/2024:11:39:04
3684 [02/Mar/2024:11:39:04
5898 [02/Mar/2024:11:39:04
4751 [02/Mar/2024:11:39:04
7672 [02/Mar/2024:11:39:04
5940 [02/Mar/2024:11:39:04
5698 [02/Mar/2024:11:39:04
4992 [02/Mar/2024:11:39:04
3852 [02/Mar/2024:11:39:01
5318 [02/Mar/2024:11:39:04
5926 [02/Mar/2024:11:39:04
5969 [02/Mar/2024:11:39:04
4388 [02/Mar/2024:11:39:04
5717 [02/Mar/2024:11:39:04
4819 [02/Mar/2024:11:39:04
7307 [02/Mar/2024:11:39:04
5896 [02/Mar/2024:11:39:04
5442 [02/Mar/2024:11:39:04
5815 [02/Mar/2024:11:39:04
至此，完整的因果链已经很清晰了：宿主做 RAID 一致性检测 → 宿主 IOPS 下降 → 应用的日志队列堆积 → 记日志产生等待 → 各种异步请求(dubbo/redis)超时 → sirius 接口超时
硬件侧
特定型号的 RAID 卡 + 开启了 RAID 巡检计划
ssd 磁盘 + raid1 + 长使用年限
软件侧
应用的磁盘 IO 量大：这种情况下， IO 使用率会明显增加，巡检的持续时间也会明显的延长，从3小时增加到8小时
应用对响应时间比较敏感：只有对响应时间敏感，问题才有可能被发现
而 sirius 服务的部分宿主刚好满足以上所有条件。
（二）问题的影响范围
目前只发现了 sirius 一个被影响方，影响也很小。
但理论上只要满足条件，就会被影响到；对应的现象是每周六上午11点开始，某些指标开始有轻微的波动，持续3到8小时，之后自愈。
（三）损失评估
虽然持续时间很长，从2023-10至2024-03，将近半年，但影响太小，未达到故障标准。
考虑到接口超时的现象有逐渐恶化的趋势，属于及时止损，避免了更大的负面影响。
（四）解决方案
运维侧
在全司范围内，关闭该型号RAID卡的所有巡检计划（PR、CC）
业务侧
减少非必要的日志记录
六、其他问题
（一）2024-02-10，sirius 全部重启完之后，超时率为什么恢复了？
巧合，而且时间过去太久，已经无法追溯当时操作的精确时间点了。
（二）问题为什么从2023-10才开始暴露出来？
sirius 在2023-10切换成了独享型 大规格pod的部署模式。
在这之前，sirius 有超过600个 pod，和全司所有业务共用一个很大的宿主池，所以 sirius 的 IO 压力被分散了，而且大部分其他业务的 IO 压力远没有 sirius 大，所以问题没有暴露出来。
而切换之后，sirius 缩减到200个 pod，使用固定的一批宿主池（100台），所以 sirius 的所有 IO 压力都要由这100台宿主承担，问题才得以暴露出来。
（三）RAID 巡检期间，为什么只有 IO 使用率有异常波形，次数和吞吐量没有？
只有通过系统调用发起的 IO，才会被记录到磁盘 IO 相关的监控中；RAID 巡检的相关指令是由 RAID 卡直接下发给磁盘，不经过操作系统。
IO 使用率其实也没有记录 RAID 巡检所带来的 IO，但这个指标是从耗时的维度来衡量的，巡检时，磁盘繁忙，导致对 IO 系统调用的处理能力下降，导致耗时升高。
所以是 RAID 巡检影响了 IO 系统调用的耗时。
（四）超时现象逐渐恶化的趋势是怎么来的？
不知道，但有几个猜测：
和磁盘数据量有关
和磁盘碎片化程度有关（ssd 同样也有碎片问题，只是对性能的影响远没有 hdd 那么严重；而且 ssd 的寿命是根据擦除次数来的，所以在 ssd 上开启碎片整理，只会加速损耗 ssd 的寿命）
七、通用的性能类问题排查方法
本部分内容是大多基于个人的理解和经验，难免有主观和局限的地方，大家如有不同的看法，欢迎交流探讨！
（一）方法层面
找规律：在异常情况中寻找规律或共性
变化规律
相关性规律
周期性规律
......
作对照
排查问题时，大脑里应该始终绷着的一根弦
从差异点入手，可以大幅提高排查问题的效率
用一切手段复现问题
大胆假设，小心求证
（二）技术层面
计算机领域内，和性能相关的，无外乎四类：CPU、内存、磁盘、网络
绝大部分的性能问题，根因都可以归到其中的一类
这四类所带来的影响都不是点的问题，而是面的问题，找到了影响面，也就找到了问题的所在
根据实际情况建立猜疑链
应用 → 中间件 → ...... → 操作系统 → 硬件 → 物理世界
不断向下，不跳步、不遗漏
平时多拓宽知识面
让自己在关键时刻能问出正确的问题，再利用 搜索引擎 + AI 找到答案
当前的技术环境下，问出正确的问题 比 知道答案 要重要的多得多
推荐阅读《性能之巅》，书中包含了非常全面的方法论和工具集，如果你想成为性能专家，这一本不容错过
（三）道的层面
信念感
99.99%的性能问题都是有原因的
不要轻易的归结为”网络波动“或”性能不稳定“之类的借口；我们每一次归为这些借口，就错过了一次突破自我的机会
敢于质疑”权威“
质疑要有事实基础 和 合理性
质疑的事情要有能力证明 或 证伪
对巧合的警惕：巧合的背后往往有深层次的原因
良好的心态
性能专家不是速成的，需要从相对简单的问题入手，建立正反馈，培养自信心
很多问题，想要查出来，确实需要一些运气成分；所以实在查不出来的时候，也请不要气馁
做事不设边界，回归到解决问题本身
八、参考资料
logback异步日志：https://logback.qos.ch/manual/appenders.html#AsyncAppender
RAID 周期性巡检：https://en.wikipedia.org/wiki/RAID#Integrity
MegaRAID芯片支持的巡检功能：https://techdocs.broadcom.com/us/en/storage-and-ethernet-connectivity/enterprise-storage-solutions/storcli-12gbs-megaraid-tri-mode/1-0/v11869215/v11673749/v11673787/v11675132.html
SSD磁盘碎片：https://en.wikipedia.org/wiki/Solid-state_drive#Hard_disk_drives，搜索fragmentation