@论坛小助手 替换了新主机，报警频率降低会自动恢复，有可能是因为IO抖动引发的吗？
1 个赞
日志采集场景: clog盘满
日志采集命令: obdiag gather scene run --scene=observer.clog_disk_full
为了更好地帮助您分析和解决问题，建议您使用上述 obdiag 命令进行日志采集，并将生成的日志压缩包提供给我们进一步分析。此外，请您回答以下问题以便我们更全面地了解情况：
- 是否可以确认更换主机后 IO 性能有所提升？例如通过 iostat 或其他工具观察到的具体数据变化是什么？
- 在告警发生时，是否观察到系统级的 IO 等待时间或磁盘队列长度有明显增加？
- 更换主机前后的硬件配置（如磁盘类型、RAID 配置等）是否有差异？如果有，请详细说明。
- 是否在 OCP 中观察到其他相关联的告警信息，例如高负载或特定时间段内的性能波动？
- 在更换主机之前，是否有过针对 IO 抖动的优化尝试（如调整内核参数、文件系统配置等）？如果有，请描述具体措施。
通过以上信息，我们可以更准确地判断问题是否由 IO 抖动引发，并为您提供针对性的解决方案。
附上敏捷诊断工具 obdiag 使用帮助链接
2 个赞
-
告警的机器是 OCP 机器 还是 OB 机器？
-
CLOG 目录（一般是
/data/log1）所在的磁盘不要跟 OS 共用，也不建议跟数据目录（一般是/data/1）共用磁盘。 CLOG 目录要用现有条件下最好的磁盘（如NVMe SSD，其次是SATA SSD)。
发下面命令可以提供更详细的信息。
df -h
lsblk
5 个赞
看看大佬回答
2 个赞
1，一般先看下磁盘iops等指标性能，,结合业务QPS,TPS等能反映业务是否繁忙相关的指标判断。
2，二般可能是业务量突增，clog盘写不过来的情况下，主要还是磁盘大小不够，这种情况也会影响副本同步。
3，三般排查网络问题，确保网络没毛病。
4，四般，OCP告警延迟，或误报。
2 个赞
CPU使用率和负载正常，TPS和QPS无波动，业务无明显增长，磁盘容量充足，网络正常，确认是误报。
顺便搞清楚每个告警指标查的是哪个视图，有没有具体SQL。
1 个赞
定位不到哪个sql引发的io抖动，全是类似的sql同时跑的
我是指OCP监控采集的方式方法。OB也是通过并行机制提高并发的套路，业务SQL引发的IO抖动很正常，你没法每天都去抓这些SQL，意义不大，毕竟改不改也不是你能说了算，所以磁盘性能要求高也是合理的，否则无法满足客户的无厘头SQL。
1 个赞
明白啦感谢，抽空研究一下。
1 个赞