今天就跟大家聊聊有关DBA_HIST_EVENT_HISTOGRAM定位GPFS写缓慢问题该怎么分析,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
1问题
9月1日接监控告警,8月份批量生成文件缓慢,没有在窗口内完成。
2分析
生成批量文件的逻辑很简单,针对一个查询语句进行循环,依次使用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缓慢。
3测试验证
通过测试比较写本地文件系统与写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写缓慢问题该怎么分析有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注云行业资讯频道,感谢大家的支持。