资讯

精准传达 • 有效沟通

从品牌网站建设到网络营销策划,从策略到执行的一站式服务

DBA_HIST_EVENT_HISTOGRAM定位GPFS写缓慢问题该怎么分析

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


当前标题:DBA_HIST_EVENT_HISTOGRAM定位GPFS写缓慢问题该怎么分析
路径分享:http://cdkjz.cn/article/gdgsse.html
多年建站经验

多一份参考,总有益处

联系快上网,免费获得专属《策划方案》及报价

咨询相关问题或预约面谈,可以通过以下方式与我们联系

大客户专线   成都:13518219792   座机:028-86922220