巧用DBA_HIST_EVENT_HISTOGRAM定位GPFS寫緩慢問題

redhouser發表於2018-04-25
Histogram

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寫緩慢導致批次檔案未能在視窗內完成。

4後續措施

   （1）敦促維護部門聯絡廠商更新相關補丁。

   （2）如再次出現生成檔案失敗問題，透過手工刪除檔案，很可能會加快寫GPFS速度。

  

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/18922393/viewspace-2153318/，如需轉載，請註明出處，否則將追究法律責任。

相關文章