【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.1.0
【问题描述】
正常使用中，莫名的就IO卡死了。
集群的5个节点IO都异常了，排查tomcat日志没发现大文件的导入。
查询ocp的sql诊断，也没发现问题时间段insert大量的数据。
想问下这种情况，如何排查下？已经出现了几次了。
想定位IO卡死的原因，麻烦老师了
可以看看 gv$sql_audit表看看最近都是什么SQL语句？
IO比较多，是不是在做compaction?
看看TopSQL 是不是有SQL 索引不好，导致随机读太多了。
gv$sql_audit和ocp上面显示的有什么区别吗？
gv$sql_audit的哪个字段可以按时间查询？
在不知道哪里出问题的情况下；
1、检查硬件是否存在故障；
2、优化top 10 的SQL语句；
3、将合并延后，检查当前合并及转储配置是否合理
看上面那个delete语句，也是遍历了全表吧，没有使用索引
delete正常情况下是很快的，这个我们已经验证过了，这是出问题时候的现象
那有什么可疑的日志吗？
查询了tomcat的日志没发现什么异常，没有大文件的导入。以前出现IO问题出现过导入文件的，这次并没有。
不是，我是说observer的日志，有啥可疑的吗？
这个需要怎么查那？搜索IO吗？或者关键词什么的？error吗？
-
grep “may be hung”
-
grep “IO STATUS” 查看IO配置、实时iops（对应__all_virtual_io_quota表)
-
grep "IO SENDER STATUS"查看IO请求调度信息
1 个赞
好的，谢谢，我这边排查下。
sda 盘看起来 读写等待和读写服务时间都很不正常。首先要排查一下是不是磁盘异常了，看主机 日志 。 /var/log/messages
sda 应该不是 ssd 吧。如果是普通的sas 盘，读写量稍微上去性能就很慢。
从 iostat 看，这个服务器就一块物理盘 sda 。所以 OS，跟 OB 都在一块盘上吗？
同时 OB的运行日志、数据文件、事务日志文件也是同一块盘。生产环境不应该这么布局。
缓解建议：
- 调整 ob 日志参数 ob_esi_syslog_level syslog_level 都为 ERROR。
- 调整 obproxy 日志参数 xflush_log_level monitor_log_level syslog_level 。
INFO 的日志量太大了，对这种盘是个很大的负担。如果对分析问题没帮助不如就减少一些日志输出。
分析建议：
装一个 io 监控 比如说 tsar ，这样能看一段时间的 io 变化，然后跟 ob的事件表（__all_rootservice_event_History ）关联分析。
这篇文章供参考：
1 个赞
/var/log/messages出问题的时间段并无发现异常，都是Session的记录。
数据和日志都在一个盘的问题是存在的，现在也没法调整了。
ob的日志确实很大，不想调整了。
我们试下tsar，谢谢老师了。
我们的是lvm的虚拟磁盘，用fio测试，性能还是可以的。
平常数据库使用是没问题的，偶现的IO卡死，10-20分钟自动恢复了。
确实是存在IO瓶颈的，导致卡死是我们不能接受的。
没啥用的日志关掉，应该是能少使用不少io的。
出了问题，那日志自己也看不懂啊，留着没啥用。需要再打开复现收集日志就好了
1 个赞
