共計 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 行業資訊頻道，感謝大家的支持。
