今天就跟大家聊聊有关DBA_HIST_EVENT_HISTOGRAM定位GPFS写缓慢问题该怎么分析,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
9月1日接监控告警,8月份批量生成文件缓慢,没有在窗口内完成。
生成批量文件的逻辑很简单,针对一个查询语句进行循环,依次使用utl_file.put_line写入文件(文件在集群文件系统GPFS上)。
查询SQL执行计划,未发现异常。
查询gv$active_session_history,发现会话等待事件集中在“utl_file I/O”上:
sql_id | wait_class | event | count |
5nddq6b1a4bbu | User I/O | utl_file I/O | 22708 |
5nddq6b1a4bbu | 391 | ||
75m4xybvbvj7y | Concurrency | os thread startup | 3 |
75m4xybvbvj7y | 735 | ||
Other | enq: PS - contention | 4 |
查询dba_hist_event_histogram中对应的utl_file I/O等待事件等待时间分布如下:
SNAP_ID | INSTANCE_NUMBER | EVENT_NAME | WAIT_TIME_MILLI | WAIT_COUNT |
80837 | 1 | utl_file I/O | 1 | 608614205 |
80837 | 1 | utl_file I/O | 2 | 123584 |
80837 | 1 | utl_file I/O | 4 | 970730 |
80837 | 1 | utl_file I/O | 8 | 25320 |
80837 | 1 | utl_file I/O | 16 | 363 |
80837 | 1 | utl_file I/O | 32 | 90 |
80837 | 1 | utl_file I/O | 64 | 16 |
80837 | 1 | utl_file I/O | 128 | 56 |
80837 | 1 | utl_file I/O | 256 | 1 |
80837 | 1 | utl_file I/O | 512 | 1 |
80837 | 2 | utl_file I/O | 1 | 3069290 |
80837 | 2 | utl_file I/O | 2 | 1 |
80837 | 2 | utl_file I/O | 4 | 2 |
80837 | 2 | utl_file I/O | 8 | 1 |
80837 | 2 | utl_file I/O | 32 | 5 |
80837 | 2 | utl_file I/O | 64 | 8624 |
80837 | 2 | utl_file I/O | 128 | 17714 |
80837 | 2 | utl_file I/O | 256 | 4315 |
80837 | 2 | utl_file I/O | 512 | 118 |
80837 | 2 | utl_file I/O | 1024 | 6 |
从上表中可以发现,实例1等待次数wait_count随等待时长wait_time_milli增加快速稳定下降,实例2等待次数wait_count没有随等待时长wait_time_milli增加下降,在wait_time_milli=128ms时存在一个明显的高峰17714,怀疑写入GPFS缓慢。
通过测试比较写本地文件系统与写GPFS文件性能差异。
--写本地文件系统,
declare
g_file utl_file.file_type;
begin
dbms_output.enable(null);
g_file := UTL_FILE.fopen('LOCAL_DIR','test20170805.txt','W');
for x in 1..1000000 loop
utl_file.put_line(g_file, x||rpad('x',1000,'x'));
end loop;
utl_file.fclose(g_file);
end;
/
--写GPFS文件系统
declare
g_file utl_file.file_type;
begin
dbms_output.enable(null);
g_file := UTL_FILE.fopen('GPFS_DIR','test20170805.txt','W');
for x in 1..1000000 loop
utl_file.put_line(g_file, x||rpad('x',1000,'x'));
end loop;
utl_file.fclose(g_file);
end;
/
测试结果如下:
次序 | 文件大小 | 本地文件(sec) | GPFS文件(sec) | 备注 |
1 | 100MB | 7.4 | 7.5 | 打开新文件,写入 |
2 | 100MB | 8.2 | 72 | 重新打开未删除原文件,写入 |
3 | 1GB | 74 | 75 | 打开新文件,写入 |
4 | 1GB | 75 | 756 | 重新打开未删除原文件,写入 |
5 | 1GB | 74 | 676 | 重新打开未删除原文件,写入 |
从上表中可以发现:
规律1:在重复写同一个文件时,写GPFS文件系统比写本地文件慢一个数量级
规律2:如果写入一个新文件,写入速度与本地文件系统相当
至此,确定问题根源为GPFS写缓慢导致批量文件未能在窗口内完成。
看完上述内容,你们对DBA_HIST_EVENT_HISTOGRAM定位GPFS写缓慢问题该怎么分析有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注亿速云行业资讯频道,感谢大家的支持。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。