文 | 劉漢檳

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

前言

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

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

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

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

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

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

清單 1. 造成 CPU100%問(wèn)題的 SQL

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

清單 2. 調(diào)優(yōu)前訪問(wèn)計(jì)劃

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

主鍵索引包含 (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 內(nèi)動(dòng)態(tài) SQL 語(yǔ)句的寫(xiě)法，訪問(wèn)執(zhí)行計(jì)劃可能使用兩種路徑，路徑 1 就是現(xiàn)在清單 2 中使用的索引 TRAN_ID_X1，路徑 2 就是在或 (or) 條件中使用主鍵索引和索引 TRAN_TMP_ID_X0。

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

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

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

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

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

下面是建立 OPTPROFILE 的步驟：

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

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

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

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

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

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

清單 3. 調(diào)優(yōu)后訪問(wèn)計(jì)劃

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

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

圖 1. WAS 應(yīng)用 OPTPROFILE

添加定制屬性：

屬性名：optimizationProfile

屬性值：PMR35104.PROF1

定制完成后，需要重啟 WAS 服務(wù)器。

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

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

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

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

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

修改 IHS 的配置文件 plugin-cfg.xml，將其中的 ServerIOTimeout=”60″ 、PostBufferSize=”64&Prime;修改為 ServerIOTimeout=”300″ 、PostBufferSize=”0″。這樣設(shè)置表示，IHS 上的請(qǐng)求在 300 秒內(nèi)沒(méi)有收到 WAS 的響應(yīng)，不會(huì)自動(dòng)進(jìn)行轉(zhuǎn)發(fā)，會(huì)報(bào)超時(shí)錯(cuò)誤。

修改 WAS 應(yīng)用服務(wù)器的 ServerIOTimeout 參數(shù)(讀/寫(xiě)超時(shí))的值為 0，即讀寫(xiě)超時(shí)時(shí)不轉(zhuǎn)發(fā)請(qǐng)求。

圖 2. WAS 修改讀寫(xiě)超時(shí)

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

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