共计 1982 个字符，预计需要花费 5 分钟才能阅读完成。
今天就跟大家聊聊有关 DBA_HIST_EVENT_HISTOGRAM 定位 GPFS 写缓慢问题该怎么分析，可能很多人都不太了解，为了让大家更加了解，丸趣 TV 小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
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 写缓慢问题该怎么分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注丸趣 TV 行业资讯频道，感谢大家的支持。
