文 | 劉漢檳

大數(shù)據(jù)量和高吞吐是銀行內容管理系統(tǒng)長期設計的核心問題，本文通過內容管理系統(tǒng)在農(nóng)信銀行后督系統(tǒng)的設計和實現(xiàn)實例 (基于 DB2V97 數(shù)據(jù)庫)，描述對于內容管理系統(tǒng)如何針對每天大約 400 萬個圖片、可能存放 15 年達到 2PB 文件規(guī)模的大數(shù)據(jù)量系統(tǒng)進行數(shù)據(jù)模型設計、表分區(qū)以及壓縮的具體設計實現(xiàn)，以及系統(tǒng)在高并發(fā)下一些實際問題的處理，系統(tǒng)上線后吞吐量和性能得到了客戶的認可，可以為類似的銀行系統(tǒng)提供重要的參考。

前言

本文是對使用 IBM 內容管理系統(tǒng)為平臺的廣東農(nóng)信銀行客戶后督系統(tǒng)的分析和介紹，以及對大數(shù)據(jù)量和高吞吐的基于 DB2 數(shù)據(jù)庫的 IBM Content Manager 系統(tǒng)的一些設計上的分析以及一些實際問題的解決，系統(tǒng)在調優(yōu)后性能和吞吐量滿足的客戶的需求，可以作為類似系統(tǒng)的參考，但是要注意，每一個系統(tǒng)都有自己獨特的需求和實際情況，本文無法涵蓋您在系統(tǒng)建設過程中的所有問題。

另外，將來實際系統(tǒng)中在數(shù)據(jù)量達到一定量級時，可能會碰到新的難題，我們希望能和客戶一起協(xié)作解決并將經(jīng)驗分享給大家。第 2 部分，我們將著重介紹實例問題和分析解決的辦法供類似系統(tǒng)參考。

對于實例系統(tǒng)中出現(xiàn)的與性能和高并發(fā)相關的關鍵問題的分析和解決

在客戶的實際后督生產(chǎn)系統(tǒng)中，在系統(tǒng)工程師的努力下，經(jīng)過了對網(wǎng)絡、存儲、DB2、WAS、TSM 和 CM 的調優(yōu)以后，依舊在高吞吐和為此設計的高并發(fā)的系統(tǒng)中發(fā)現(xiàn)了兩個棘手的問題，嚴重影響了性能，并造成了一些 CM 孤兒數(shù)據(jù) (Orphan data) 很難被處理，這些問題雖然不一定會在每個系統(tǒng)中都出現(xiàn)，但一旦出現(xiàn)解決起來耗時耗力，在客戶和 IBM 支持人員的協(xié)作下，問題得到了圓滿的解決，本文借此機會感謝所有參與解決這些問題的客戶和 IBM 支持人員，并將問題和分析解決的思路共享出來，可以供有類似問題的高吞吐高并發(fā)內容管理系統(tǒng)參考。

問題一. 啟用遷移后資源數(shù)據(jù)庫占用 CPU 達到 100%

此時 I/O，網(wǎng)絡資源都很充足，根據(jù)對動態(tài) SQL 語句的監(jiān)控，發(fā)現(xiàn)大量并發(fā)操作會執(zhí)行同一條語句。

清單 1. 造成 CPU100%問題的 SQL

此語句的訪問計劃 (Access plan) 雖然使用了如下的索引 TRAN_ID_X1，但是訪問的行數(shù)巨大并造成了巨量的邏輯讀，經(jīng)過分析是造成 CPU 資源占用過大的根本原因。

清單 2. 調優(yōu)前訪問計劃

分析 RMTRANSACTIONS 表可以發(fā)現(xiàn)此表是 VOLATILE 類型的表，并且有三個索引：

主鍵索引包含 (OBJ_COLLID, OBJ_ITEMID, OBJ_VERSION, OBJ_LIBRARYID, TRANSACTION_DATE) 字段。

索引 TRAN_TMP_ID_X0包含 (OBJ_TMP_COLLID, OBJ_TMP_ITEMID, OBJ_TMP_VERSION) 字段。

索引 TRAN_ID_X1包含 (TRANSACTIONID, TRANSACTION_DATE, PROCESSTIMEOUT) 字段。

根據(jù)清單 1 內動態(tài) SQL 語句的寫法，訪問執(zhí)行計劃可能使用兩種路徑，路徑 1 就是現(xiàn)在清單 2 中使用的索引 TRAN_ID_X1，路徑 2 就是在或 (or) 條件中使用主鍵索引和索引 TRAN_TMP_ID_X0。

由于 RMTRANSACTIONS 表是 VOLATILE 類型的表，VOLATILE 代表這個表是變動非常頻繁的表，統(tǒng)計信息已經(jīng)不能正確反映實際的數(shù)據(jù)量，DB2 在表的查詢時候只要有滿足條件的索引，會忽略統(tǒng)計信息，優(yōu)先使用索引，這個表的特點就是資源數(shù)據(jù)庫有事務發(fā)生時候會記錄相應的事務記錄，事務結束后會刪除相應的記錄。

所以一般情況下記錄很少或者為 0，當打包遷移發(fā)生時，會在短時間內有大量事務產(chǎn)生，記錄數(shù)可能在 0 到幾萬條之間頻繁變化，非常符合 VOLATILE 表的特性，而且這三個索引都有期望的 SQL 語句會經(jīng)常使用，索引的設計和定義也沒有問題。那么問題出在哪呢?

我們結合遷移的場景仔細分析這個 SQL 語句，會發(fā)現(xiàn)，索引 TRAN_ID_X1(TRANSACTIONID, TRANSACTION_DATE, PROCESSTIMEOUT) 影響的查詢條件是 TRANSACTIONID<>?，業(yè)務的含義是尋找有沒有其他的 TRANSACTIONID 和現(xiàn)在要使用的是否有相同的。

對于一個遷移事務，對應的表內應該沒有相同的 TRANSACTIONID 或者至多一條，所以在這個<>? 的條件中，將會在索引掃描后對基礎表做全表掃描去匹配剩下的條件 (比如 OBJ_ITEMID) 等，這樣一來，使用這個索引的結果就是做了一次索引的全掃描加上全表掃描，這樣就會造成大量的行讀，這樣我們就分析出來錯誤的根本原因是在客戶的現(xiàn)場環(huán)境中對于 RMTRANSACTIONS 這張 VOLATILE 表沒有找到最優(yōu)的訪問計劃，實際上數(shù)據(jù)分析的結果應該是選用路徑 2 的訪問計劃，這樣索引掃描的結果應該是幾乎為 0 的記錄數(shù)，也就基本沒有任何表掃描。

由于是 VOLATILE 表，此表本身統(tǒng)計信息長期為 0 不具備參考價值，優(yōu)化器有可能會根據(jù)系統(tǒng)的各個條件選取路徑 1 或者路徑 2，我們測試的系統(tǒng)中都選擇了高效的路徑 2，但是客戶的實際系統(tǒng)中還是有一定的可能選擇路徑 1，即使選用路徑 1 這個問題也不一定都能暴漏出來，只有遷移的并發(fā)吞吐達到一定的量級 (比如每秒遷移超過 1000) 才可能會呈現(xiàn)出來，DB2 本身也對這種極少可能發(fā)生的訪問路徑選取異常設計了解決方案。問題分析出來以后，剩下的就是使用 DB2 提供的 OPTPROFILE 的方案去強制為清單 1 的 SQL 指定路徑 2 的索引方案。

下面是建立 OPTPROFILE 的步驟：

1.創(chuàng)建 SYSTOOLS.OPT_PROFILE 表

2.創(chuàng)建 PMR35104.PROF1.xml，包含 SQL 的 GUIDELINE

3.創(chuàng)建文件 profiledata，內容為”PMR35104″,”PROF1″,”PMR35104.PROF1.xml”

4.將 profiledata 裝載到 systools.opt_profile 表中;

5.檢查 SQL 語句是否走了新的索引。

6.檢查 db2exfmt_alan_exfmt_opt.out 文件，查看執(zhí)行計劃是否如清單 3 所示。

清單 3. 調優(yōu)后訪問計劃

從清單 3 左下部分中我們可以看到，查詢的訪問計劃已經(jīng)轉而使用我們希望的主鍵索引和索引 TRAN_TMP_ID_X0 做索引查詢。

由于資源數(shù)據(jù)庫的應用是部署在 WAS 上的，在 DB2 服務端設置完后，需要對 WAS 端進行設置，使得 WAS 連接數(shù)據(jù)庫的應用使用 PMR35104.PROF1。

圖 1. WAS 應用 OPTPROFILE

添加定制屬性：

屬性名：optimizationProfile

屬性值：PMR35104.PROF1

定制完成后，需要重啟 WAS 服務器。

結論：在使用了 DB2 的 OPTPROFILE 的方法之后，進行測試后發(fā)現(xiàn)開啟單個 WAS 集群應用服務器后數(shù)據(jù)庫服務器的 CPU 使用率在 5%左右，4 個應用服務器同時啟動后，CPU 使用率大約在 20%左右，網(wǎng)絡的吞吐量能達到 400-500MB/秒, 遷移數(shù)量每個應用服務器都為 800 筆/秒左右，完全能滿足客戶的業(yè)務需求。

問題二. CM 裝載存在孤兒數(shù)據(jù)

如前文所述，客戶系統(tǒng)中每天白天需要裝載 400 萬圖片項，有 10 臺客戶端上載程序同時工作上傳，每臺客戶機有 10 個進程同時上載，也就是總共有 100 個進程同時上載文檔圖片，并且使用 4 組 WAS ND 集群服務器，每個集群包含 4 個節(jié)點。

在批量上載過程中，每導入幾千萬的數(shù)據(jù)，總會有一些孤兒數(shù)據(jù)產(chǎn)生，經(jīng)過分析，這些孤兒數(shù)據(jù)產(chǎn)生的原因是，產(chǎn)生問題的幾條數(shù)據(jù)，每條數(shù)據(jù)對于同一個上載任務，有時間很近的兩條上載任務向資源服務器發(fā)出請求，雖然由于主鍵約束系統(tǒng)會拒絕其中的一條，但實際進入的一條時間戳會產(chǎn)生不一致，檢驗工具會把這條數(shù)據(jù)標記為孤兒數(shù)據(jù)。

經(jīng)過診斷分析，CM 本身不會對同一條上載記錄做重復上載命令，最終認定是由于 RM 使用集群，IHS 使用安裝時默認的轉發(fā)功能導致，建議將 IHS 上的重新轉發(fā)功能取消。具體表現(xiàn)為同一個請求在一個節(jié)點上執(zhí)行超時(默認為 60 秒)，IHS 可能將該請求轉發(fā)不同的節(jié)點上，而不同節(jié)點上的數(shù)據(jù)信息不一致，導致 CM 報錯并產(chǎn)生臟數(shù)據(jù)(包括孤兒數(shù)據(jù))。對 WAS 的具體修改如下：

修改 IHS 的配置文件 plugin-cfg.xml，將其中的 ServerIOTimeout=”60″ 、PostBufferSize=”64″修改為 ServerIOTimeout=”300″ 、PostBufferSize=”0″。這樣設置表示，IHS 上的請求在 300 秒內沒有收到 WAS 的響應，不會自動進行轉發(fā)，會報超時錯誤。

修改 WAS 應用服務器的 ServerIOTimeout 參數(shù)(讀/寫超時)的值為 0，即讀寫超時時不轉發(fā)請求。

圖 2. WAS 修改讀寫超時

修改 CM 庫數(shù)據(jù)庫 ICMNLSDB 的 ICMSTSYSCONTROL.MAXTXDURATION 字段，默認是 86400(24 小時)，將其修改為較小值，IBM 建議不低于 7200 (2 小時)。該值表示 CM 事務執(zhí)行的間隔等待時間。(update ICMSTSYSCONTROL set MAXTXDURATION = 7200 where LIBRARYSERVERID = 1)

結論：通過優(yōu)化后的性能測試驗證，該設置起效，CM 多線程并發(fā)裝載再沒有出現(xiàn)臟數(shù)據(jù)。 小結 通過本文第 2 部分的介紹，我們可以了解 CM 高吞吐高并發(fā)實例系統(tǒng)中幾個特殊疑難問題的分析和解決方法。