1. 程式人生 > >分割槽資料庫環境下 DB2 LOAD 效能調優

分割槽資料庫環境下 DB2 LOAD 效能調優

轉自: http://www.ibm.com/developerworks/cn/data/library/techarticle/dm-1112wul/

在本文中,除非特別宣告,對於 DB2 LOAD 的討論都是在分割槽資料庫環境下。同時本文專注於討論分割槽資料庫環境下 DB2 LOAD 的效能調優,不再對分割槽資料庫中的基本概念進行贅述,閱讀本文的讀者需要對分割槽資料庫概念有基本的瞭解。LOAD 作為 DB2 的實用程式,廣泛地應用於各種資料移動場景中,尤其是在資料倉庫的 ETL 過程中,LOAD 更是佔據了主導地位。因此如何有效地提升 LOAD 效能,在資料移動場景中滿足客戶的需求和期望,是至關重要的。在對 LOAD 效能進行調優之前,首先需要理解 LOAD 中各相關執行緒的作用和特點,從而有針對性地進行調整、優化。LOAD 執行緒模型如圖 1 所示。


圖 1. LOAD 執行緒模型
LOAD 執行緒模型

在 DB2 中,LOAD 操作請求由代理執行緒 db2agent 受理,該執行緒負責派生、協調、監視相關 LOAD 執行緒。LOAD 內部相關執行緒的處理流程,從預分割槽代理執行緒(db2lpprt)開始。預分割槽代理只存在於 Coordinator 分割槽節點,讀入輸入資料來源,通過 TCP/IP 網路將資料記錄分發至各資料庫分割槽的分割槽代理執行緒(db2lpart)。分割槽代理存在於各資料庫分割槽,對資料記錄的分割槽鍵進行計算從而決定該條記錄應去往哪個資料庫分割槽。當分割槽代理決定了資料記錄的去向,即通過 TCP/IP 網路將資料記錄傳送至各對應分割槽的媒體錄入執行緒(db2lmr)。媒體錄入執行緒對資料記錄進行初步處理,通過共享記憶體將資料記錄傳送給格式化執行緒(db2lfrm),該執行緒對所有資料記錄進行格式化,並將格式化後的資料記錄傳送給 Ridder 執行緒(db2lrid),Ridder 執行緒為每條記錄分配 RID,並建立表空間擴充套件資料塊(EXTENT),隨後將擴充套件資料塊傳送給快取處理執行緒(db2lbm),由該執行緒將資料最終寫入到磁碟上。

在接下來的章節,我們會詳細地分析 LOAD 各相關執行緒的作用,以及可能對其效能造成影響的各方面因素。這些因素包括,系統級引數、網路引數、例項級引數、資料庫級引數,LOAD 引數等。造成 LOAD 效能瓶頸的可能原因有很多,如 CPU 受限、記憶體瓶頸、網路受限、I/O 瓶頸等等。通過以 DB2 LOAD 執行緒模型為綱,對 LOAD 效能調優進行細化,目的是做到有的放矢,讓調優更有針對性。

在本章節中,我們將以 LOAD 內部處理流程的順序逐一解析相關執行緒的作用,以及影響其效能的因素,並對相關關鍵引數的設定給出了參考建議。

預分割槽代理只存在於 Coordinator 分割槽節點中,該執行緒的數量會因引數設定不同而有所變化。該執行緒的主要作用是讀取輸入資料來源,並通過 TCP/IP 網路以 Round-robin 的方式將資料記錄平均分發到各資料庫分割槽的分割槽代理執行緒(db2lpart)。

可能對該執行緒的處理效能造成影響的因素包括網路和 I/O。預分割槽代理從磁碟讀取輸入資料來源,除儲存設計本身的因素外,I/O 相關的引數設定不當,有可能造成 I/O 瓶頸;讀取的資料記錄需要通過 TCP/IP 網路傳送至各資料庫分割槽,除了網路本身頻寬因素外,網路相關引數設定不當,也會對 LOAD 整體效能造成影響。

系統級引數:

  • queue_depth 該引數指定磁碟 I/O 請求佇列的長度,會影響磁碟 I/O 效能,尤其是在資料庫等 I/O 密集型應用中。將該引數的值設定較大有利於獲得更好的效能。
  • maxpgahead 該引數指定順序預讀取的最大資料頁數,預設值為 8,但通常增加該值能夠獲得更好的順序讀取效能。

網路引數:

  • tcp_nodelayack 該引數決定 TCP 接收方是否立即將確認包(ACK)返回給傳送方,當開啟該引數時(tcp_nodelayack = 1),TCP 接收方立即返回 ACK 包,不產生延遲;當關閉該引數時(tcp_nodelayack = 0)TCP 接收方會最多延遲 200ms 才將 ACK 包返回給傳送方。
  • tcp_recvspace 該引數指定 TCP/IP socket 預設資料接收快取大小。
  • tcp_sendspace 該引數指定 TCP/IP socket 預設資料傳送快取大小。

分割槽資料庫環境下,LOAD 的資料流向是單向的,資料接收方不會將接收到的資料傳送回傳送方,即分割槽代理執行緒不會將接收到的資料記錄再發送給預分割槽代理執行緒。因此,可以通過開啟引數 tcp_nodelayack(tcp_nodelayack = 1)來消除網路延遲,提升網路效能。對於引數 tcp_recvspace 和 tcp_sendspace,通常建議將該值設定較大,以提升網路效能。

LOAD 引數:

  • ANYORDER 如果指定該檔案型別修飾符,則 DB2 會為每一個輸入資料來源分配一個預分割槽代理執行緒,且 LOAD 在向表空間容器中寫入格式化的資料記錄時,不會維持輸入資料來源中資料記錄的原始順序;若未指定該引數,則只分配一個預分割槽代理來順序處理各輸入資料來源。在 I/O 資源沒有被充分利用的情況下,建議指定該引數在資料讀取階段提升 I/O 效能。

分割槽代理執行緒的數量和所在資料庫分割槽,都可以通過引數來指定,每一個數據庫分割槽並不要求一定要有分割槽代理執行緒存在。分割槽代理通過 Round-robin 的方式從預分割槽代理接收資料記錄,對每一條資料記錄的分割槽鍵(Distribution Key)進行計算,並建立 Distribution Map 項,從而決定該條記錄應該去往哪個資料庫分割槽。

分割槽階段的 CPU 開銷比載入階段的 CPU 開銷要小得多,很難用足所有的 CPU 資源,因而 CPU 基本上不會成為效能瓶頸。這一階段的效能瓶頸更可能來自網路的限制,因為分割槽代理需要將分佈好的資料記錄通過 TCP/IP 網路傳送到對應的資料庫分割槽上。因此在分割槽階段,也需要考慮上述網路引數的設定。

LOAD 引數:

  • PARTITIONING_DBPARTNUMS 該選項指定分割槽代理執行緒的數量和所在資料庫分割槽,這些因素都會對 LOAD 的效能產生影響。通常,在預分割槽代理未遭遇 CPU 瓶頸、I/O 瓶頸的情況下,適當增加分割槽代理的數量可以改善 LOAD 整體效能。

媒體錄入執行緒通過 TCP/IP socket 獲取分佈到本資料庫分割槽上的資料記錄,該執行緒獲得快取空間,儲存並解析輸入資料。在 LOAD 執行緒模型中,每個資料庫分割槽只有一個媒體錄入執行緒。該執行緒的主要作用是對資料記錄進行語法解析與檢查,如果發現不符合目標表定義的資料列,則將該條資料記錄轉儲到 DUMP 檔案中。可以通過指定檔案型別修飾符來避免語法檢查。

LOAD 引數:

  • FASTPARSE 該檔案型別修飾符指定媒體錄入執行緒無需對輸入資料記錄進行語法解析和檢查,進而提升 LOAD 效能。當輸入資料來源本身比較健壯,不存在語法錯誤時,推薦使用該檔案型別修飾符。啟用該引數,LOAD 效能可獲得一定程度的提升。

格式化執行緒獲取快取空間,接收來自媒體錄入執行緒解析後的資料記錄,將資料記錄中的各種資料型別格式化為二進位制資料,並建立記錄列表,最後將記錄列表傳送至 Ridder 執行緒(db2lrid)。該執行緒的數量可通過引數來設定,通常格式化過程是 LOAD 載入階段中最消耗 CPU 資源的一項工作,因此合理的配置 CPU 資源至關重要。

LOAD 引數:

  • CPU_PARALLELISM 該引數設定 LOAD 格式化執行緒的數量,預設值為每一個數據庫分割槽中可用 CPU 數量(注意,不是物理機器中可用 CPU 數量),通常預設值已經是最優設定,無需手動更改該引數。需要注意的是,當分配給 LOAD 實用程式的記憶體資源(DATA BUFFER)不能滿足請求的 EDU(db2lfrm)數量時,LOAD 內部會降低 CPU 並行度。
  • DATA BUFFER 該引數指定 LOAD 用於內部處理的記憶體容量,預設值為資料庫實用程式堆(UTIL_HEAP_SZ)可用值的四分之一。但是該預設值通常情況下過低,不能滿足 LOAD 對記憶體的需求,應手動更改將其設定為更高。該引數對 LOAD 效能的影響非常重要,較小的記憶體空間可能導致 CPU 並行度的下降。
  • NOROWWARNINGS 在載入過程中,LOAD 會為每一條被拒絕、未格式化的資料行記錄訊息,訊息檔案的寫入會對 LOAD 效能產生較大影響,有時甚至佔據大部分 LOAD 處理時間。如果更加註重 LOAD 效能,而不關心資料行被拒絕的原因,可以啟用該檔案型別修飾符來避免向訊息檔案中寫入記錄級別的警告資訊,從而提升 LOAD 效能。

Ridder 執行緒獲取快取空間,接收來自格式化執行緒的記錄列表,為列表中的每條記錄分配 RID,並建立表空間擴充套件資料塊(EXTENT),建立好的擴充套件資料塊通過共享記憶體傳送至快取處理執行緒(db2lbm)。Ridder 執行緒同時還負責索引鍵排序與索引建立、統計資訊收集、一致點檢查等工作。需要注意的是,每個資料庫分割槽只有一個 Ridder 執行緒,但 Ridder 執行緒負責的工作繁多而又複雜,所以在該階段需要各方面的調優從而使得該處理執行緒不致成為 LOAD 整體效能的瓶頸。

LOAD 引數

  • STATISTICS LOAD 在載入資料的過程中,可以同時收集表和索引的統計資訊,這比 LOAD 執行完成後用 RUNSTATS 來收集統計資訊要高效的多,因為後者需要對錶資料進行重新掃描。但是收集統計資訊會造成比較嚴重的開銷,且收集統計資訊的工作由唯一的 Ridder 執行緒來完成,最多可影響 LOAD 300% 的效能,通常佔據了 LOAD 的絕大多數處理時間。通常建議將此引數設定為 NO。

Ridder 執行緒另一項很重要(同時對 LOAD 效能影響較大)的工作是索引的維護,包括索引的排序和重建。LOAD 支援三種索引模式(REBUILD,INCREMENTAL,DEFERRED),可以通過關鍵字 INDEXING MODE 來指定。


表 1. 索引模式
REBUILD INCREMENTAL DEFERRED
該索引模式下,如果是離線 LOAD 模式,則在開始索引重建之前,將當前已存在索引物件置為無效;如果是聯機 LOAD 模式,則建立一份新的索引影像,允許併發使用者訪問舊的索引物件,當最終提交時,會用新的索引影像替換舊的索引物件。 該索引模式下,只需要將新插入資料記錄的索引鍵新增到已有的索引物件即可。如果是聯機 LOAD 模式,新插入但還未提交的記錄索引鍵,通過偽插入(pseudo-inserted)演算法對使用者是不可見的,LOAD 提交後對使用者立即可見。該索引模式下,LOAD 會對新插入記錄的索引更改進行日誌記錄,產生少量日記記錄開銷。 該索引模式下,將當前索引物件置為無效,不會重建或追加索引。如果 LOAD 完成後,沒有顯示地重建索引(CREATE INDEX),那麼索引管理器會根據資料庫配置引數 INDEXREC(ACCESS,RESTART 等)的設定來選擇重建索引的時機。

無論目標表上有多少索引,LOAD 會為每一個索引做排序,這些排序是順序進行的,索引物件的建立也是順序進行的,統一由一個代理執行緒 db2agent 依次順序完成。與此不同的是,索引管理器在建立索引時,採用了不同的機制。當通過 CREATE INDEX 來建立索引時,在分割槽資料庫環境下,會生成多個代理執行緒來建立索引。鑑於每個 db2agent 都會分配私有排序堆(SORTHEAP),因此 CREATE INDEX 方式能夠更好地利用記憶體資源。所以通常情況下,如果不是必需,不推薦在 LOAD 過程中建立索引;更有效的方式是在 LOAD 前,將目標表索引物件刪除,在 LOAD 完成後,通過 CREATE INDEX 方式在目標表上重建索引。通常在以下兩種情況,才推薦在 LOAD 過程中建立索引:

  • LOAD 載入的資料量(INSERT 方式)與目標表現存資料量相比,較小,這時推薦採用索引模式 INCREMENTAL 來維護索引;此時如果採用 CREATE INDEX 方式,會對目標表所有資料行進行索引重建。
  • 目標表索引數量過多,導致 CREATE INDEX 方式的並行掃描、排序的時間甚至超過了 LOAD 過程中表掃描、排序的時間。

如果只關心 LOAD 整體效能,而忽略索引物件的維護,推薦採用在 LOAD 前刪除目標表索引物件,LOAD 完成後以 CREATE INDEX 方式來維護索引的方式,因為索引物件的建立和維護會造成比較嚴重的開銷,經常佔據 LOAD 的絕大多數處理時間。但如果客戶明確要求需要測試 LOAD 過程中建立、維護索引的場景,則需要考慮如下因素來儘量提升該階段的效能。

例項級引數

  • SHEAPTHRESH 該引數確定了例項內所有私有排序記憶體總量的軟上限,當實際值超過該引數設定時,新的排序請求獲得的記憶體空間將遠遠小於所請求的記憶體容量大小,因此推薦增大對該引數的設定,從而為排序請求設定更大的可用記憶體空間。
  • DIAGLEVEL 該引數指定向 DB2 診斷檔案 db2diag.log 中寫入的內容,如果將該引數設定為 4,即包含資訊性訊息,則會大量增加寫入的資訊量。不同執行緒對 db2diag.log 檔案的寫入,會加 X 鎖(eXclusive 鎖),頻繁地對 db2diag.log 檔案訪問,可能導致不同程度的鎖等待,從而影響整體效能。通常建議將該引數降至為 3,即只包含錯誤和警告資訊。

資料庫級引數

  • SORTHEAP 該引數確定了每個代理執行緒 db2agent 用於排序的記憶體空間大小。當所需要排序的資料量超過該引數的設定時,排序資料會溢位到臨時表空間的緩衝池中,如果緩衝池依然不足以容納溢位的排序資料,則溢位資料最終被寫到磁碟上,造成額外的 I/O 開銷。因此,在允許的情況下,儘量增大對該引數的設定,同時要儘可能地建立更大的緩衝池,避免額外的 I/O 開銷。
  • NUM_IOSERVERS 該引數指定資料預讀取執行緒的數量,鑑於可能造成的 I/O 開銷,應考慮增大對該引數的設定。
  • NUM_IOCLEANERS 該引數指定髒資料寫入執行緒的數量,鑑於可能造成的 I/O 開銷,應考慮增大對該引數的設定。

快取處理執行緒通過共享記憶體從 Ridder 執行緒獲取格式化的擴充套件資料塊,形成資料頁,並將其寫入磁碟。如果指定 COPY YES 選項,則快取處理執行緒會將擴充套件資料塊和資料頁傳送給媒體寫入執行緒( 圖 1.中未標出),後者將資料寫入至 Load Copy。

LOAD 引數

  • DISK_PARALLELISM 該引數確定了每個資料庫分割槽內快取處理執行緒的數量,預設值為表空間容器數量或者格式化執行緒數量的四分之一(取最大值)。通常該引數的預設值已經是最優配置,無需手動更改。但是當表空間橫跨的磁碟較多,如表空間是建立在磁碟陣列上時,增大該引數的設定有利於獲得更好的效能。
  • COPY YES 由於 LOAD 過程中記錄的日誌內容較少,在可恢復資料庫中,在 LOAD 完成後,目標表所在表空間會處於 Backup Pending 狀態,使用者無法對錶空間進行 DML 操作(INSERT,UPDATE,DELETE),資料庫要求立即對錶空間進行備份。為了避免在 LOAD 完成後,表空間處於 Backup Pending 狀態,可以指定 COPY YES 選項,從而在 LOAD 過程中對錶空間進行備份,該備份稱為 Load Copy。

需要注意的是,在 LOAD 過程中,表空間備份本身和將備份寫入磁碟所造成的 I/O 開銷,都會對 LOAD 整體效能產生影響。如果儲存系統不能提供足夠的並行 I/O 進而消化掉備份所帶來的 I/O 消耗,那麼在 LOAD 過程中對錶空間進行備份就會成為效能瓶頸。可以通過選項 COPY NO 和 NONRECOVERABLE 指定在 LOAD 過程中不要備份表空間,二者區別在於:

  • COPY NO LOAD 過程中不備份表空間,但 LOAD 完成後,表空間處於 Backup Pending 狀態,需要手動對錶空間進行備份,否則無法進行 DML 訪問。
  • NONRECOVERABLE LOAD 過程中不備份表空間,LOAD 完成後,表空間可以進行正常的訪問,但是當資料庫進行恢復和前滾操作時,LOAD 對目標表進行的更改將丟失,目標表也會處於異常狀態,無法訪問。

通常在效能測試中,為了提升 LOAD 整體效能,採用 COPY NO 選項,在 LOAD 完成後,手動地對目標表所在表空間進行備份。

例項演示

在本章節中,對 LOAD 進行例項演示,通過關鍵引數調整前後的對比來展示效能調優的效果。例項演示分為四部分,即硬體環境、資料庫環境、測試場景和測試結果。

硬體環境

該例項演示的硬體環境為兩臺 IBM SystemX 3650,架構為 x86_64,配置為雙核 2.6GHz CPU,16GB 記憶體,900GB 硬碟儲存。兩臺 Server 通過 1Gbit 乙太網進行通訊。

資料庫環境

作業系統環境為 SuSE Linux Enterprise Edition,核心為 2.6.16.60;資料庫版本為 DB2 9.7 for Linux,UNIX and Windows。分割槽資料庫環境:在每臺 Server 上建立兩個資料庫分割槽,總共四個資料庫分割槽。這樣每個資料庫分割槽佔用的資源大致為 1 個 CPU,7GB 記憶體,400GB 儲存空間。

測試場景

本 LOAD 測試的輸入資料來源為 DEL 格式,記錄數為 10485760,達到千萬行數量級,檔案儲存大小為 2.7GB。本次測試的測試方法論為,保證其他關鍵引數不變,對關注引數(某一個引數)進行調整,對比調整前後 LOAD 效能情況,從而展示該關注引數對 LOAD 效能的影響。此次測試的關注引數包括:ANYORDER,FASTPARSE,STATISTICS,COPY YES/NO,DATA BUFFER,SORTHEAP,SHEAPTHRES。下文將逐一對這些場景進行描述。測試用目標表結構及其建立語句如下:


清單 1. 目標表結構
				
 CREATE TABLE LOAD_PERF (A INT,B INT,C CHAR(128),D CHAR(128))

場景 1

目標表無索引,在保證其他關鍵引數不變的前提下,對比以下情況 LOAD 效能提升效果。

  • 調整前:未指定 ANYORDER
  • 調整後:指定 ANYORDER

清單 2. 調優前 LOAD 命令
				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY FASTPARSE NOROWWARNINGS INSERT INTO LOAD_PERF 
 STATISTICS NO COPY NO DATA BUFFER 5000 PARTITIONED DB CONFIG 
 PARTITIONING_DBPARTNUMS(0,1,2,3)


清單 3. 調優後 LOAD 命令
				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY ANYORDER FASTPARSE NOROWWARNINGS INSERT INTO 
 LOAD_PERF STATISTICS NO COPY NO DATA BUFFER 5000 PARTITIONED DB CONFIG 
 PARTITIONING_DBPARTNUMS(0,1,2,3)

場景 2

目標表無索引,在保證其他關鍵引數不變的前提下,對比以下情況 LOAD 效能提升效果。

  • 調整前:未指定 FASTPARSE
  • 調整後:指定 FASTPARSE

清單 4. 調優前 LOAD 命令
				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY ANYORDER NOROWWARNINGS INSERT INTO LOAD_PERF 
 STATISTICS NO COPY NO DATA BUFFER 5000 PARTITIONED DB CONFIG 
 PARTITIONING_DBPARTNUMS(0,1,2,3)

調優後的 LOAD 命令請參看 清單 3.

場景 3

目標表無索引,在保證其他關鍵引數不變的前提下,對比以下情況 LOAD 效能提升效果。

  • 調整前:指定 STATISTICS YES
  • 調整後:指定 STATISTICS NO

清單 5. 調優前 LOAD 命令
				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY ANYORDER FASTPARSE NOROWWARNINGS REPLACE INTO 
 LOAD_PERF STATISTICS YES COPY NO DATA BUFFER 5000 PARTITIONED DB CONFIG 
 PARTITIONING_DBPARTNUMS(0,1,2,3) 

調優後的 LOAD 命令請參看 清單 3.

場景 4

目標表無索引,在保證其他關鍵引數不變的前提下,對比以下情況 LOAD 效能提升效果。

  • 調整前:指定 COPY YES
  • 調整後:指定 COPY NO

清單 6. 調優前 LOAD 命令
				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY ANYORDER FASTPARSE NOROWWARNINGS INSERT INTO 
 LOAD_PERF STATISTICS NO COPY YES TO /home/wulei/LOAD/ DATA BUFFER 5000 
 PARTITIONED DB CONFIG PARTITIONING_DBPARTNUMS(0,1,2,3) 

調優後的 LOAD 命令請參看 清單 3.

場景 5

目標表無索引,在保證其他關鍵引數不變的前提下,對比以下情況 LOAD 效能提升效果。

  • 調整前:採用預設 DATA BUFFER 值,資料庫引數 UTIL_HEAP_SZ 預設值為 5000
  • 調整後:手動設定 DATA BUFFER 值為 5000

清單 7. 調優前 LOAD 命令
				
 LOAD FROM SRC.DEL OF DEL MODIFIED BY ANYORDER FASTPARSE NOROWWARNINGS INSERT INTO 
 LOAD_PERF STATISTICS NO COPY NO PARTITIONED DB CONFIG 
 PARTITIONING_DBPARTNUMS(0,1,2,3) 

調優後的 LOAD 命令請參看 清單 3.

場景 6

目標表有索引,索引列數量為一列,資料型別為 Integer,索引為非唯一索引。LOAD 中索引模式 INDEXING MODE 為預設的 REBUILD 方式。在保證其他關鍵引數不變的前提下,對比以下情況 LOAD 效能提升效果。

  • 調整前:採用引數 SORTHEAP,SHEAPTHRES 的預設值;預設值分別為 SORTHEAP = 256 SHEAPTHRES = 0,另引數 SHEAPTHRES_SHR = 5000
  • 調整後:手動設定 SORTHEAP = 5000,SHEAPTHRES = 10000

調優前後的 LOAD 命令請參看 清單 3.


清單 8. 引數設定命令
				
 DB2 UPDATE DB CFG FOR TESTDB USING SORTHAEP 5000 
 DB2 UPDATE DBM CFG USING SHEAPTHRES 10000 

測試結果

對應上文描述的各測試場景,現將測試結果陳列如下,通過對比調整前後 LOAD 耗時情況來展示調優效果。

場景 1


表 2. 測試結果
ANYORDER LOAD 耗時
調整前 未指定 4 分 26 秒
調整後 指定 4 分 25 秒

場景 2


表 3. 測試結果
FASTPARSE LOAD 耗時
調整前 未指定 4 分 26 秒
調整後 指定 4 分 23 秒

場景 3


表 4. 測試結果
STATISTICS LOAD 耗時
調整前 YES 4 分 22 秒
調整後 NO 4 分 15 秒

場景 4


表 5. 測試結果
COPY LOAD 耗時
調整前 YES 5 分 41 秒
調整後 NO 4 分 17 秒

下圖展示了調優前後系統的 I/O 情況,通過下圖可以看出,當指定 COPY YES 時,系統需要進行的 I/O 操作明顯增加,I/O 訪問量是調優後的 2~3 倍,進而嚴重影響 LOAD 整體效能。


圖 2. 調優前系統 I/O
調優前系統 I/O

圖 3. 調優後系統 I/O
調優後系統 I/O

場景 5


表 6. 測試結果
DATA BUFFER LOAD 耗時
調整前 預設值 5 分 15 秒
調整後 手動設定 4 分 19 秒

場景 6


表 7. 測試結果
SORTHEAP,SHEAPTHRES LOAD 耗時
調整前 預設值 9 分 17 秒
調整後 手動設定 7 分 30 秒

下圖展示了調優前後系統的 I/O 情況,通過下圖可以看出,當採用引數預設值時,系統需要進行的 I/O 操作明顯增加,這是因為預設的排序堆設定不足以容納需要排序的資料量,當緩衝池的空間有限時,LOAD 會將資料快取到磁碟上。如圖所示,調優前 I/O 訪問量是調優後的 2~3 倍,嚴重影響了 LOAD 整體效能。


圖 4. 調優前系統 I/O
調優前系統 I/O

圖 5. 調優後系統 I/O
調優後系統 I/O

附件中包含了例項演示中各場景的測試指令碼和測試結果,供讀者下載。

本文中使用了一些英文縮寫術語,目的在於突出文章重點內容,而儘量減少讀者注意力的分散,現將縮寫術語解釋如下:

  • EDU Engine Dispatchable Unit,DB2 內部各類執行緒,引擎排程單元。
  • RID Record ID,資料記錄唯一 ID 標識,由資料頁號和資料頁內記錄槽號構成。
  • EXTENT 表空間擴充套件資料塊,由若干資料頁組成,是表空間儲存和訪問資料的基本單元,同時也是表空間容器寫入的基本單位,當資料寫滿一個 EXTENT 時,則開始到下一個容器中寫入資料。
  • RUNSTATS 該 DB2 命令用於收集表、索引的各類統計資訊。
  • Load Copy 在 LOAD 過程中,對目標表所在表空間進行的備份,稱作 Load Copy。

下載

描述 名字 大小 下載方法
本文用到的 db2 測試指令碼及結果示例 DB2_LOAD_Performance_Test 50KB HTTP