大型機(jī)上運(yùn)行的程序作為歷史悠久,應(yīng)用領(lǐng)域廣泛的商業(yè)應(yīng)用程序,一直是用戶關(guān)注的焦點(diǎn)。大型機(jī)應(yīng)用程序的性能問(wèn)題會(huì)導(dǎo)致程序消耗更多的系統(tǒng)資源,這就意味著大型機(jī)系統(tǒng)需要為運(yùn)行這個(gè)程序提供更多的 CPU 時(shí)間。根據(jù)測(cè)算,大型機(jī)上的 CPU 每運(yùn)行一分鐘平均的開(kāi)銷(xiāo)大約是 15 USD,由此可見(jiàn)針對(duì)應(yīng)用程序的性能調(diào)優(yōu)可以幫助用戶提高程序效率,減少程序消耗的 CPU 時(shí)間,推遲由于系統(tǒng)資源不足導(dǎo)致的軟硬件升級(jí)計(jì)劃,有效的降低大型機(jī)的運(yùn)行成本。目前很多大型金融機(jī)構(gòu)的應(yīng)用程序開(kāi)發(fā)中心成立了專(zhuān)門(mén)的部門(mén)對(duì)應(yīng)用程序進(jìn)行性能調(diào)優(yōu)。而 DB2 for z/OS 作為大型機(jī)上絕大多數(shù)應(yīng)用程序最主要的數(shù)據(jù)庫(kù)平臺(tái),針對(duì) DB2 for z/OS 應(yīng)用程序的性能調(diào)優(yōu)就成了每個(gè)用戶關(guān)注的要點(diǎn)。
應(yīng)用程序的性能問(wèn)題最直接的表現(xiàn)為兩點(diǎn):
1. | CPU 時(shí)間過(guò)長(zhǎng) |
2. | WAIT 時(shí)間過(guò)長(zhǎng) |
這兩點(diǎn)也恰恰是分析性能問(wèn)題的出發(fā)點(diǎn) ( 見(jiàn)圖 1) 。
如果性能問(wèn)題表現(xiàn)為 CPU 時(shí)間長(zhǎng),應(yīng)該從應(yīng)用程序代碼和 DB2 執(zhí)行的 SQL 兩方面分析;如果性能問(wèn)題表現(xiàn)為 WAIT 時(shí)間長(zhǎng),則應(yīng)該從 I/O 和 Service Task 兩方面分析,進(jìn)而逐步細(xì)化問(wèn)題產(chǎn)生的原因,進(jìn)而最終定位性能問(wèn)題根源。
工欲善其事,必先利其器。想要快速準(zhǔn)確地發(fā)現(xiàn)、分析并解決問(wèn)題,使用相應(yīng)工具輔助是一種常見(jiàn)的手段。針對(duì)大型機(jī)應(yīng)用程序性能分析,業(yè)界常用的工具有兩類(lèi): 針對(duì)應(yīng)用程序的分析工具和針對(duì) DB2 的分析工具 ( 見(jiàn)圖 2 和 表 1),它們相輔相成,結(jié)合使用可以達(dá)到事半功倍的效果。
名稱(chēng) | 特點(diǎn) | |
---|---|---|
1. 針對(duì)應(yīng)用程序的分析工具 | STROBE | STROBE 和 APA 是同一類(lèi)型的工具,它們記錄了目標(biāo)應(yīng)用程序在訪問(wèn)數(shù)據(jù)庫(kù)、操作系統(tǒng)、文件系統(tǒng)一系列動(dòng)作中與此應(yīng)用程序相關(guān)的性能開(kāi)銷(xiāo) |
APA | ||
2. 針對(duì) DB2 的分析工具 | DB2 PM | OMEGAMON 可以看作是 DB2 PM 的升級(jí)版,它記錄了 DB2 中所有的應(yīng)用的性能開(kāi)銷(xiāo) |
OMEGAMON XE for DB2 |
STROBE 通過(guò)瀏覽器界面發(fā)現(xiàn)并展示性能問(wèn)題,從導(dǎo)致性能問(wèn)題的 2 個(gè)基本點(diǎn) CPU 和 WAIT 出發(fā),快速定位性能問(wèn)題(見(jiàn)圖 3),本文在應(yīng)用性能分析實(shí)例中采用 STROBE 報(bào)表作為樣例。
DB2 PM 以文本的方式展示性能信息,詳細(xì)記錄 DB2 中的各種性能開(kāi)銷(xiāo),為分析 DB2 相關(guān)的性能問(wèn)題提供了最詳盡的分析報(bào)告 ( 見(jiàn)圖 4)。
可能有人會(huì)問(wèn):這些輔助分析工具是必需的嗎?不用任何工具就不能分析大型機(jī)系統(tǒng)的問(wèn)題嗎?答案是:理論上這些輔助工具不是必需的,所有信息都可以在大型機(jī)提供的各種系統(tǒng)數(shù)據(jù)中找到(見(jiàn)表 2)。但是,就像交通工具(汽車(chē),飛機(jī)等)可以方便人們的生活一樣,使用性能分析工具也可以極大地提高性能分析工作的效率。
名稱(chēng) | 作用 | |
---|---|---|
1 | SMF records | 基于 SMF records 可以產(chǎn)生各種 Trace,包括分析 DB2 的 Trace, 用于分析各種性能,負(fù)載方面的問(wèn)題。 |
2 | LOGREC data | 基于 LOGREC data 可以產(chǎn)生 EREP Report,用于分析硬件及系統(tǒng)方面的問(wèn)題,包括 I/O Device , Process failure 等。 |
3 | SYSLOG data | 記錄了 Console 上的信息和操作員使用的命令 |
4 | DUMP | 產(chǎn)生一個(gè) Sequential 的 DUMP File,記錄了系統(tǒng)內(nèi)存中的信息。 |
其實(shí)上述性能分析工具就是對(duì)這些系統(tǒng)提供的信息進(jìn)行包裝和再加工,以一種更友好的方式提供給用戶。如 STROBE 和 OMEGAMON XE for DB2 等工具,它們都是通 Instrumentation Facility Interface (IFI) 來(lái)獲取 DB2 相關(guān)的性能信息,而這些信息也會(huì)被記錄到 SMF records 中。
DB2 for z/OS 應(yīng)用程序性能分析的基本流程 ( 見(jiàn)表 3)
1. 定位問(wèn)題類(lèi)型 | 應(yīng)用程序代碼性能問(wèn)題 | DB2 SQL 性能問(wèn)題 | I/O 性能問(wèn)題 |
2. 分析問(wèn)題原因 | 重復(fù)調(diào)用同一條語(yǔ)句 | 使用 Table Scan 訪問(wèn)方法 | Getpage 數(shù)量太大 |
未能正常使用 CURSOR | Where 語(yǔ)句使用了 Stage 2 的 Predicate | Buffer Pool 不夠大 | |
3. 提出改進(jìn)意見(jiàn) | 根據(jù)問(wèn)題特點(diǎn)提出改進(jìn)意見(jiàn) |
下面就使用 3 個(gè)實(shí)例來(lái)展示如何分析 表 3 中列出的典型問(wèn)題
步驟 1:定位問(wèn)題
通過(guò)性能分析報(bào)告 ( 見(jiàn)圖 5) 可以發(fā)現(xiàn) Module 0800 中的一段代碼 (Line 484 到 Line 514) 在不停地’打開(kāi)’ (OPEN) 和’關(guān)閉’ (CLOSE) 一個(gè)文件,16.95 %的 CPU 時(shí)間都用于執(zhí)行此段代碼。
步驟 2:分析問(wèn)題 -結(jié)合應(yīng)用程序代碼
結(jié)合 Module 0800 的代碼發(fā)現(xiàn)這是由于 OPEN/CLOSE 文件的子程序被一個(gè)外層循環(huán)所不停的調(diào)用導(dǎo)致重復(fù)調(diào)用同一條語(yǔ)句。
步驟 3: 改進(jìn)意見(jiàn)
把 OPEN/CLOSE 兩條語(yǔ)句放在子程序循環(huán)體以外,這樣調(diào)用子程序時(shí)只需要 OPEN/CLOSE 一次就可以。
步驟 1:定位問(wèn)題
通過(guò)性能分析報(bào)告( 見(jiàn)圖 6 )可以發(fā)現(xiàn),單單一條 SELECT 語(yǔ)句 (SQL 530) 消就耗了 12.03% CPU 和 40.07% WAIT。
步驟 2:分析問(wèn)題 - 參考 DB2 Explain 和 DB2 Catalog Statistics
分析 SQL 語(yǔ)句的性能開(kāi)銷(xiāo)就要知道這些消耗是發(fā)生在哪些 SQL 相關(guān)的元素上 ( 見(jiàn) 圖 7)。一條 SQL 語(yǔ)句的 CPU 開(kāi)銷(xiāo)通常由 4 種元素開(kāi)銷(xiāo)構(gòu)成 ( 見(jiàn)表 4),而 I/O 的發(fā)生則是因?yàn)橐』氐挠涗洸辉趦?nèi)存中,需要到磁盤(pán)上取。DB2 最終計(jì)算 SQL 相關(guān)的每一項(xiàng)元素開(kāi)銷(xiāo)的基礎(chǔ)數(shù)據(jù)是來(lái)源于 DB2 CATALOG STATISTICS, 通常對(duì) SQL 性能分析是從 ACCESS PATH 開(kāi)始的,也就是從分析 SQL 的 EXPLAIN OUTPUT 開(kāi)始。
CPU | 開(kāi)銷(xiāo)類(lèi)型 | SQL元素 | 說(shuō)明 |
---|---|---|---|
1. | Base Cost | TABLE 屬性 | 如果 TABLE 是壓縮的,在讀取數(shù)據(jù)時(shí)會(huì)因?yàn)榻鈮嚎s而產(chǎn)生 CPU 開(kāi)銷(xiāo) |
2. | Page Cost | INDEX/DATA PAGES | INDEX 過(guò)濾出來(lái)的結(jié)果集越小,需要訪問(wèn)的 INDEX 以及 DATA PAGES 就越少,這方面的 CPU 開(kāi)銷(xiāo)就越少 |
3. | Scan Cost | INDEX 設(shè)計(jì) /SORT | 如果組成 INDEX 的 COLUMNS 每一個(gè)都有很好的過(guò)濾性,這個(gè) INDEX 需要 SCAN 的 record 數(shù)量就會(huì)比較少,這方面的 CPU 開(kāi)銷(xiāo)就少;SORT 會(huì) SCAN 結(jié)果集并排序,會(huì)消耗大量 CPU |
4. | Row Cost | WHERE 子句 | Where 子句的過(guò)濾性越強(qiáng),最終返回結(jié)果集就越少,CPU 開(kāi)銷(xiāo)就越小 |
圖 6 中 SQL 530 這條 SELECT 性能不好,通常從分析它怎么訪問(wèn) DB2 開(kāi)始,也就是要分析這條 SQL 語(yǔ)句的 ACCESS PATH。相關(guān)的信息都在 DB2 的 EXPLAIN OUTPUT 中。查看 SQL 530 的 EXPLAIN OUTPUT( 見(jiàn)圖 8), 可以發(fā)現(xiàn)此條 SQL 使用了 INDEX SCAN 的方式從 DB2 中取回?cái)?shù)據(jù) (ACCESS TYPE : I),使用的 INDEX 是 IINMBP(ACCESSNAME)。
通過(guò)表 4 可以判斷導(dǎo)致 SQL 530 性能不好的元素是 INDEX IINMBP。由于 DB2 計(jì)算 INDEX 相關(guān)開(kāi)銷(xiāo)是基于 CATALOG STATISTICS,所以接下來(lái)需要查看 CATALOG STATISTICS 中 INDEX 相關(guān)信息 ( 見(jiàn)圖 9)。
從圖 9 中可以發(fā)現(xiàn),SQL 530 選用的 INDEX IINMBP 的第一個(gè) COLUMN(INST_NO) 的 COLCARD 是 1,也就是說(shuō)在這個(gè) COLUMN 上,只有一種值,所以這個(gè) COLUMN 沒(méi)有任何過(guò)濾性。這正是 SQL 530 使用 INDEX SCAN 性能仍然不好的原因。
步驟 3: 改進(jìn)意見(jiàn)
從圖 9 中可以看到,INDEX IINMBP 的第二個(gè) COLUMN(ACCT_NO) 的 COLCARD 是 23350108,這和 Table 的 CARDF 是一樣的,也就是說(shuō)這個(gè) Table 中,ACCT_NO 每個(gè) RECORD 都有不同的值,具有非常好的過(guò)濾性。因此改進(jìn)建議是使用 ALTER 語(yǔ)句改變 INDEX IINMBP 中 COLUMN 的順序?yàn)?IINMBP(ACCT_NO, INST_NO) 。
步驟 1:定位問(wèn)題
通過(guò)性能分析報(bào)告 ( 見(jiàn)圖 10) 可以發(fā)現(xiàn),SQL 1700( 見(jiàn)清單 1) 消耗了 74.99% CPU 和 11.54 的 I/O, 伴隨著 SQL 1700 有超過(guò) 395000 次的 GET PAGE 請(qǐng)求,并且導(dǎo)致了 110376 條記錄被 INSERT 到 WORKFILE 中,最終返回 7001 條結(jié)果。
SELECT SYSIBM.SYSTABLES.NAME FROM SYSIBM.SYSTABLES WHERE ( ( ( SYSIBM.SYSTABLES.NAME IN (SELECT SYSIBM.SYSCOLUMNS.TBNAME FROM SYSIBM.SYSCOLUMNS WHERE SYSIBM.SYSCOLUMNS.TBCREATOR > ‘ ‘ AND TBCREATOR < ‘ Z ’ ) ) ) ) AND SYSIBM.SYSTABLES.TYPE <> ‘ A ’ ORDER BY SYSIBM.SYSTABLES.NAME |
步驟 2:分析問(wèn)題 - 結(jié)合 SQL 語(yǔ)義
通過(guò)表 4 可以判斷導(dǎo)致 SQL 1700 性能不好的元素是 WHERE 子句,WHERE 子句中的 SUB-SELECT 會(huì)產(chǎn)生子結(jié)果集,這個(gè)子結(jié)果集再和外層的 WHERE 條件一一匹配,這樣就產(chǎn)生了一個(gè)很大的最終結(jié)果集,而這些結(jié)果記錄不在內(nèi)存中,就導(dǎo)致了很多的 GET PAGE 請(qǐng)求。結(jié)合 SQL 語(yǔ)義后發(fā)現(xiàn),其實(shí)這個(gè) SUB-SELECT 是不必要的,可以轉(zhuǎn)化成同樣意義的兩個(gè) WHERE 條件,這樣就不會(huì)有子結(jié)果集的產(chǎn)生,和額外的 GET PAGE 請(qǐng)求。
步驟 3: 改進(jìn)意見(jiàn)
改寫(xiě) SQL( 見(jiàn)清單 2)
SELECT NAME FROM SYSIBM.SYSTABLES WHERE CREATOR > ‘ ‘ AND CREATOR < ‘ Z ’ AND TYPE <> ‘ A ’ ORDER BY NAME |
再次運(yùn)行 SQL 1700,通過(guò)性能報(bào)告 ( 見(jiàn)圖 11) 可以發(fā)現(xiàn),改進(jìn)后 SQL 只消耗了 3.35% CPU,并且只有 7001 條記錄被插入 WORKFILE 中,沒(méi)有額外的 GET PAGE 請(qǐng)求。
學(xué)習(xí)
獲得產(chǎn)品和技術(shù)
聯(lián)系客服