DB2 パフォーマンス チューニング ロードマップ_PHP チュートリアル
- WBOYオリジナル
- 2016-07-12 09:00:06790ブラウズ
DB2 パフォーマンス チューニング ロードマップ
フー ディンはウェン ホイ様のために牛の縛りを解き、すべてを手で触り、肩に寄りかかり、足で歩き、膝を踏みました。 。 「サンリン」と組み合わさった踊りは「経」との出会いです。 Wen Huijun 氏は、「おい、それはすごいね! これでテクノロジーは終わりなのか?
DB2 と言えば、あまり馴染みがないかもしれない。ほとんどの人は、Oracle、SQLserver、MYSQL、そして MongoDB などの人気のある NOSQL についてはよく知っているだろう。 REDIS など。著者は仕事上 DB2 によく触れるので、ここでは私の理解を述べます。著者自身の限界により、多くの問題の説明は正確である可能性があります。MYSQL が単一のプロセスであることは誰もが知っています。 Windows と Linux ではパフォーマンスが異なります。Windows では、複数のスレッドを持つ単一のプロセスですが、Linux では、(プロセスと同様に) マルチアドレス空間でサービスを提供します。 ) 方法。
<b style="font-family:Arial;font-size:small;line-height:normal;white-space:normal;background-color:#FFFFFF;">Architected around the address space Conceptually, DB2 is a relational database management system. Physically, DB2 is an amalgamation of address spaces and intersystem communication links that, when adequately tied together, provide the services of a relational database management system.</b>
原文
DB2 のこのプロセス処理方法、OVERHEAD は、CICS THREAD、ALLIED ADDRESS SPACE、DATABASE ACCESS THREAD などの多くのサブスレッド分類を導入します。はい、これはいわゆるさまざまな CALL ATTACHEMENT FACILITY の概念も導入しています。実際、これらはすべて DB2 が外部に公開するさまざまな API によるものです。クラスターについては、「DB2 DATA SHARING」を参照してください。
- DB2 の DBMS CLUSTER テクノロジーの簡単な分析
- DBMS-DSG - XCF の初期調査
- DSG CF キャッシュの話
- DSG CF キャッシュの話 1
- DSG CF キャッシュの話 2
- DB2 バッファの原理の紹介
- データベース 設計の理論的根拠
パフォーマンスの見通し
この記事の内容は、システムチューニングの基本スキルを書いた後に整理し、同時にアプリケーションチューニングの部分を追加しています。知識の学習自体も段階的なプロセスです。 まず第一に、パフォーマンスの概念を明確にする必要があります。パフォーマンスとは何ですか? これに対応する英語の単語は、Wikipedia によると、有用なタスクを完了するためにコンピュータが消費する時間とリソースです。したがって、高いパフォーマンスが得られるということは、使用するリソースが少なくなり、作業がより速く完了することを意味します。 パフォーマンスの目標は空洞がないことです、笑
- 現実的です。つまり、現在のテクノロジーでパフォーマンスを達成できます。たとえば、平均トランザクション応答時間は 0.1 が達成可能ですが、0.000001 です。現実的ではありません
- 合理的、合理的です
- 良い、完璧な、この種の空の説明の代わりに、比率、割合、数値などの定量化可能なもの
- 測定可能なものは測定できます
- 日常監視
- オンライン/リアルタイムイベント監視
- 例外監視
总体指导思想
- TOP-DOWN TUNEING
- DEVIDE AND CONQUER
- 二八原则。花80%的时间解决20%的问题，带来80%的收益，即最佳性价比
- 一个前提：当系统运行或是应用出现问题的时候，我们总是假定这是一个由量变到质变的过程[变更除外，这种情况下需要紧急回退]，即我们总是假设系统或是应用在以前是正常的，我们需要一个benchmark.这就给我提供了一个思路，当你没有思路时，你可以和历史数据进行比较，从而发现问题
- 关于定性和定量的问题,相对来说，定性容易，定量有时候还是比较困难的
- 从管理的角度，调优是一个持续改进的过程,应该是一个闭环，即监控发现问题，分析问题，解决问题，而后继续监控
-
一点体会： 其实调优本身也是一个资源配置的问题，在特定的场景之下，如何把有限的资源进行有效的配置，从而达到组织的目的。 整个组织目前拥有的资源，这里只对计算机系统调优而言：
- CPU
- IO
- LOCKING
- STORAGE5. human resource 当然就是你了
- NETWORKING 可忽略
- SYSTEM HARDWARE & OTHER SOFTWARE SUCH AS CICS/ZOS/CFCC
影响这些resource的方式不外乎：
1. got enough 2. not enouth 3. too much 4. inefficient 5. what are the available controls? (fixes)
两大方向
系统调优 应用调优
系统调优
关于系统调优前面已经介绍过了--系统调优的基本功,这里的任务就是如何在总结提炼.那篇文章介绍的更多内容其实对应的是routine monitor，
CICS性能数据收集交易性能数据对应的SMF 类型为110,对应的分析工具CICS PA
SMF Type 110 (subtype0) — CICS Journal Record SMF Type 110 (subtype1) — CICS Monitoring Record SMF Type 110 (subtype2) — CICS Statistics RecordDB2 性能数据收集
DB2 SMF 对应的SMF TYPE 为100,101,102,其中
SMF TYPE=100 DB2 SUBSYSTEM STATISTICSSMF TYPE=101 DB2 ACCOUNTING SMF TYPE=102 ALL OTHERE PERFORMANCE
SMF TYPE=100 的表格如下
| クラス | データ収集 | IFCID |
|---|---|---|
| 1 | 統計データ | 1、2、105、106、202、225 |
| 2 | インストール定義の統計レコード | 152 |
| 3 | デッドロック、ロックエスカレーション、グループバッファプール、データセット、拡張情報、長時間実行されるURの兆候、およびアクティブなログスペース不足 | 172、196、250、258、261、262、313、330 、335、337 |
| 4 | DB2例外条件 | 173,191-195、203-210、235、236、238、267、268、343、402 |
| 5 | DB2 データ共有統計レコード | 254 |
| 6 | ストレージ使用量の詳細 | 225 |
| 7 | DRDA位置統計 | 365 |
| 8 | Data set I/O statistics | 199 |
SMF 本身的结构也是一个树形层级结构,如果打算收取某一类型的trace，你需要关注三个方面，
- TRACE TYPE
- CLASS
- IFCID
这样对应的收取trace的命令就很好理解了
START TRACE(S) CLASS() IFCID(172) DEST(SMF) ---TNODIS TRACESTOP TRACE(S) TNO(XX) recommand defualt trace:start trace(s) c(1,3,5,6,7,8)解读stat
这里首先介绍SMF TYPE=100,由上面的表格，我们可以了解到stat报表包括的大体内容，下面我们逐一介绍，让你对报表有一个大体的了解，有时候自下而上解决不了问题的时候，stat就是一个关键的突破口。 STATISTICS 性能数据收取的时间颗粒度granularity为1分钟，相比较SMF TYPE101，102，它的量是很少。 考虑解读性能数据的重要性，后续单独写一篇来介绍，你放心，绝对值得写一章。 在结束准备工作之前，在向你介绍一个性能数据在一个颗粒度内是如何计数的，主要分为3类：
- SNOPSHOT VALUE--current value 即性能数据收取时间时对应的实时值
- HWK --HIGH WATER MARK 对应的时间颗粒度内的最高水位值
- ACCUMULATE VALUE--累加值，时间颗粒度内一个逐渐累加计数值作者注明确这一点对性能数据解读很重要。