今天就跟大家聊聊有关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写缓慢问题该怎么分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。
