今天就跟大家聊聊有關(guān)DBA_HIST_EVENT_HISTOGRAM定位GPFS寫緩慢問題該怎么分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：域名與空間、網(wǎng)頁空間、營銷軟件、網(wǎng)站建設(shè)、武山網(wǎng)站維護、網(wǎng)站推廣。

1問題

   9月1日接監(jiān)控告警，8月份批量生成文件緩慢，沒有在窗口內(nèi)完成。

2分析

   生成批量文件的邏輯很簡單，針對一個查詢語句進行循環(huán)，依次使用utl_file.put_line寫入文件（文件在集群文件系統(tǒng)GPFS上）。

  查詢SQL執(zhí)行計劃，未發(fā)現(xiàn)異常。

  查詢gv$active_session_history，發(fā)現(xiàn)會話等待事件集中在“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中對應(yīng)的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

從上表中可以發(fā)現(xiàn)，實例1等待次數(shù)wait_count隨等待時長wait_time_milli增加快速穩(wěn)定下降，實例2等待次數(shù)wait_count沒有隨等待時長wait_time_milli增加下降，在wait_time_milli=128ms時存在一個明顯的高峰17714，懷疑寫入GPFS緩慢。

3測試驗證

   通過測試比較寫本地文件系統(tǒng)與寫GPFS文件性能差異。

--寫本地文件系統(tǒng)，

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文件系統(tǒng)

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;

/      

測試結(jié)果如下：

次序	文件大小	本地文件(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	重新打開未刪除原文件，寫入

  從上表中可以發(fā)現(xiàn)：

  規(guī)律1：在重復(fù)寫同一個文件時，寫GPFS文件系統(tǒng)比寫本地文件慢一個數(shù)量級

  規(guī)律2：如果寫入一個新文件，寫入速度與本地文件系統(tǒng)相當(dāng)

  至此，確定問題根源為GPFS寫緩慢導(dǎo)致批量文件未能在窗口內(nèi)完成。

看完上述內(nèi)容，你們對DBA_HIST_EVENT_HISTOGRAM定位GPFS寫緩慢問題該怎么分析有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

網(wǎng)站題目：DBA_HIST_EVENT_HISTOGRAM定位GPFS寫緩慢問題該怎么分析
網(wǎng)頁鏈接：http://www.rwnh.cn/article34/gdgsse.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、企業(yè)建站、Google、虛擬主機、網(wǎng)站設(shè)計、手機網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)