技術情報 - GT.Mアップデートヘルパープロセス
Copyright © 2006 Fidelity National Information Services, Inc.
2006年5月03日
| 改訂履歴 | |
|---|---|
| Revision 1.1 | 2006年5月03日 |
| Revision 1.0 | 2005年9月16日 |
|
GT.Mグループ Fidelity National Information Services, Inc. 2 West Liberty Boulevard, Suite 300 Malvern, PA 19355, United States of America |
GT.M Support: +1 (610) 578-4226 Switchboard: +1 (610) 296-8877 Fax: +1 (484) 595-5101 http://www.fis-gtm.com gtmsupport@fnf.com |
2次系で、プライマリからのトランザクションストリームが処理できる速度を向上させるために、"ヘルパー" プロセスを起動できるようになりました。 mupip replicate –receiver -start は、追加の修飾子の -he[lpers]=[m[,n]] を受け入れ、ここでの m はヘルパープロセスの合計数で、n はリーダー ヘルパープロセス数です。アップデートのプロセスとそのヘルパーのパフォーマンスをチューニングするデータベースファイルのヘッダー内に、追加パラメータがあります。DSEは、これらのパラメータを変更するために使用できます。(D9E10-002497)
GT.M レプリケーションは、トランザクション [1]がプライマリでコミットされ、2次側へTCP接続を介して移送され、2次系でコミットされている、パイプラインとして考えることができます。(スパイク)尖頭的負荷を処理するためにバッファリングがありますが、パイプラインの持続的なスループットは、その最も狭いステージのキャパシティによって制限されています。ボトルネックの最初のステージの場合を除いて、パイプライン内でのトランザクションのバックログには蓄積が存在します。[2] （注）また、スループットを制限するボトルネックが常に存在します。もしボトルネックが存在しなかった場合、スループットは無限になります。
GT.Mは、プライマリからセカンダリへのネットワークを制御することはできませんので、ここでは考慮しません。もしネットワークがボトルネックになっている場合、唯一の解決策は、その容量を増加させることです。
データベースエンジンの中でデーモンを持っていないことは珍しいことですが、データベースにアクセスし、そして、それを管理するために互いに協力している複数のプロセスが存在する場合に、GT.Mデータベースは最高のパフォーマンスを発揮します。GT.Mレプリケーションは、アプリケーションの論理的なデュアルサイト構成で使用されている場合、プライマリでのプロセスは、セカンダリでのプロセスがないの反して、データベースの更新を計算するビジネスロジックを実行する必要があります。従って、もしプライマリでのスループットがビジネスロジックの実行によって制限されている場合、プライマリがボトルネックになり、バックログはないでしょう。一方で、もしプライマリでのスループットがデータベースがデータをコミットできる速度によって制限されている場合は、プライマリの複数のプロセスが、孤独的な更新プロセスでセカンダリより性能を上回ることが考えられます、したがって、バックログのビルドアップを引き起こします。
大雑把に見れば、ビジネスロジックを実行するプライマリの複数のGT.Mプロセスが同一のハードウェア上で。セカンダリで実行するだけの1つのGT.Mプロセスより性能を優ることができる、2つの方法があります：
データベースを更新するために、更新されるべきデータベースブロックは、オペレーティングシステムのバッファに、そして、そこから、GT.Mグローバル·バッファキャッシュに、最初にディスクから読み取る必要があります。プライマリ上で、更新されるグローバル変数はそれらが更新される前にアプリケーションコードによって読み取られる可能性があるので、ビジネスロジックの実行自体は、グローバル·バッファ·キャッシュに更新されるブロックを頻繁もたらすでしょう。
データベースを更新する場合、1つのプロセスによって生成されるデータベースブロックとジャーナルは、最も近代的なオペレーティングシステムのIO並列処理を十分に活用するように、完全に別のプロセスによってディスクに書き込まれる可能性があります。
セカンダリ上での更新プロセスがボトルネックであるそれらの状況については、GT.M V5.0-000は、セカンダリ上のデータベース·スループットを向上するためのヘルパープロセスの概念を実装しています。最大128個のヘルパープロセスがあります。
セカンダリ上で、レシーバサーバプロセスは、プライマリと通信し、レシーバプールに更新レコードのストリームを供給します。更新プロセスは、これらの更新レコードを読み取り、ジャーナルバッファと共有メモリ上のグローバル·バッファ·キャッシュを経由してジャーナルとデータベースファイルに適用します。ヘルパープロセスは、次のように動作します。
リーダーヘルパープロセスは、レシーバプールで更新レコードを読み取り、そして、それがそれらを必要とする時にアップデートプロセスで使用できるように、グローバルバッファキャッシュに更新されるようにブロックをプリフェッチすることを試みます。
ライター·ヘルパープロセスは、オペレーティングシステムのIO並列処理に追加のGT.Mプロセスがプライマリで行う方法を利用するのに役立ちます。
ヘルパープロセスを管理するためのプライマリのインタフェースは、MUPIPです。
レシーバサーバを起動するために使用するコマンド、mupip replicate -receiver -start が追加の修飾子を取り、ヘルパープロセスを開始するために -he[lpers][=m[,n]] を取ります。
もし修飾子を使用しないか、または、もし、-helpers=0[,n] が指定されている場合は、ヘルパープロセスは開始しません。
もし修飾子が使用されていて、しかし、m と n のどちらも指定されていない場合は、ロールのデフォルトの比率でヘルパープロセスのデフォルト数が開始されます。V5.0-000で、ヘルパープロセス全体のデフォルト数は8個で、そのうちの5個はリーダーヘルパーです。
もし修飾子が使用されていて、かつ、mは指定されているが、nが指定されていない場合は、m個のヘルパープロセスが開始され、そのうちの、floor(5*m/8) 個 ( 5*m/8 の床関数の結果の数 )のプロセスはリーダーヘルパーです。
もしmとnの両方が指定されている場合は、m個のヘルパープロセスが開始され、そのうちの n 個がリーダーヘルパーです。もし m<n の場合、mupipは m 個のリーダを開始し、効果的にnをmに減らします。
UNIX / Linux上では、ヘルパープロセスは（psコマンドによって) mupip replicate -updhelper -reader や mupip replicate -updhelper -writer のように報告されます。OpenVMSでは、リーダーは GTMUHR プリフィックスを持ち、ライターは、GTMUHW プリフィックスを持ちます。
通常のレシーバサーバをシャットダウンする replicate -receiver -shutdown は、すべてのヘルパープロセスをシャットダウンします。コマンド mupip replicate -receiver -shutdown -he[lpers] は、動作を継続するためにレシーバサーバと更新プロセスを残しているヘルパープロセスだけをシャットダウンします。
![[注意]](images/note.png) | |
個々のヘルパープロセスは、mupip stop コマンドでシャットダウンできます。フィデリティは、いくつかの予期せぬ異常なイベントの場合以外のアクションのこのコースを推奨しません。 |
mupip replicate -receiver -checkhealth は、オプションの修飾子-he[lpers] を受け入れます。もし-he[lpers] が指定されている場合は、ヘルパープロセスのステータスは、レシーバサーバと更新プロセスのステータスに加えて表示されます。
ヘルパープロセスの動作を制御し、パフォーマンスのための調整が可能なデータベースファイルのヘッダー内に、パラメータの数があります。それが、、、ヘルパープロセスで更新プロセスのパフォーマンスが、広範囲にパラメータ値に非常に敏感ではないと信じられているにもかかわらず、ヘルパープロセスがバランスを取る必要があるので、それぞれの動作環境が異なります。例えば、もしリーダープロセスがグローバル·バッファ·キャッシュにデータベース·ブロックをもたらすのに十分に積極的でない場合、この作業は更新プロセスによって行われますが、反対に、もしリーダープロセスがあまりにも積極的である場合、これらのデータベースブロックに使用するキャッシュブロックは、アップデートストリームより以前にトランザクションをコミットする更新プロセスによって上書きされる可能性があります。[3]
The DSE dump -fileheader -u[pdproc] command can be used to get a dump of the file header including these helper process parameters, and the DSE change -fileheader command can be used to modify the values of these parameters, e.g.:。。。。。 DSE dump -fileheader -u[pdproc] コマンドは、これらヘルパープロセスパラメータを含むファイルヘッダーのダンプを取得するために使用することができ、DSE change -fileheader コマンドは、これらのパラメータ値を変更するために使用することができます、例えば：
scylla ~/demo 5:54pm 1048: dse dump -fileheader -updproc
File /xyz/demo/mumps.dat
Region DEFAULT
File /xyz/demo/mumps.dat
Region DEFAULT
Date/Time 20-MAY-2005 17:54:37 [$H = 60040,64477]
Access method BG Global Buffers 1024
Reserved Bytes 0 Block size (in bytes) 4096
Maximum record size 4080 Starting VBN 129
Maximum key size 255 Total blocks 0x00000065
Null subscripts NEVER Free blocks 0x00000062
Standard Null Collation FALSE Free space 0x00006000
Last Record Backup 0x0000000000000001 Extension Count 100
Last Database Backup 0x0000000000000001 Number of local maps 1
Last Bytestream Backup 0x0000000000000001 Lock space 0x00000028
In critical section 0x00000000 Timers pending 0
Cache freeze id 0x00000000 Flush timer 00:00:01:00
Freeze match 0x00000000 Flush trigger 960
Current transaction 0x0000000000000001 No. of writes/flush 7
Maximum TN 0xFFFFFFFFDFFFFFFF Certified for Upgrade to V5
Maximum TN Warn 0xFFFFFFFF5FFFFFFF Desired DB Format V5
Master Bitmap Size 64 Blocks to Upgrade 0x00000000
Create in progress FALSE Modified cache blocks 0
Reference count 11 Wait Disk 0
Journal State [inactive] ON Journal Before imaging TRUE
Journal Allocation 100 Journal Extension 100
Journal Buffer Size 128 Journal Alignsize 128
Journal AutoSwitchLimit 8388600 Journal Epoch Interval 300
Journal Yield Limit 8 Journal Sync IO FALSE
Journal File: /xyz/demo/mumps.mjl
Mutex Hard Spin Count 128 Mutex Sleep Spin Count 128
Mutex Spin Sleep Time 2048 KILLs in progress 0
Replication State ON Region Seqno 0x0000000000000001
Resync Seqno 0x0000000000000001 Resync trans 0x0000000000000001
Upd reserved area [% global buffers] 50 Avg blks read per 100 records 200
Pre read trigger factor [% upd rsrvd] 50 Upd writer trigger [%flshTrgr] 33
プライマリから受信したアップデートストリーム内のレコードは、グローバル変数に論理的な更新について記述をします。各アップデートは、1つ以上のデータベースブロックの読み込みを意味します。100レコードごとの平均読取りブロック数は、100の更新レコードが読み込まれるデータベース·ブロックの数の見積もり値です。使用する良い値は、グローバル変数のためにディスク上のツリーの平均の高さです。V5.0-000では、デフォルト値は、小さなグローバル変数（1つのインデックスブロックに加えて1つのデータブロック）の良い近似となりうる値は、200です。非常に大規模なデータベースの場合、値は400にまで増加することができます。
The DSE command change -fileheader -avg_blks_read=n sets the value of Avg blks read per 100 Records to n for the current region.、、、、、 DSEコマンド change -fileheader -avg_blks_read=n は、現在の領域に、100レコードごとの平均読取りブロック数の値に n をセットします。
更新プロセスによってそのように要求された時、リーダーヘルパーは、レシーバプールからのレコードによって参照されるグローバル変数を読み込みます。レシーバプールから読み取られたレコード数は次のようになります：
(100-upd_reserved_area)*No_of_global_buffers/avg_blks_read
言い換えれば、これは、使用する更新プロセス用にリザーブされたグローバルバッファの数のおおよその割合（整数値0から100）のフィールドで、そして、リーダーヘルパープロセスは、使用するアップデートプロセス用にグローバルバッファの少なくともこのパーセンテージを残します。V5.0-000で、デフォルト値は50、すなわち、50％、グローバル·バッファは、アップデートプロセス用に予約されており、最大50％がリーダーヘルパープロセスで満たされます。
The DSE command change -fileheader -upd_reserved_area=n sets the value of Upd reserved area to n for the current region.、、、、、 DSEコマンド change -fileheader -upd_reserved_area=n は、現在の領域に、更新用の予約領域の値を n に セットします。
リーダーヘルパーがレシーバプールからの更新レコードの数を読んでいる時、それらのリードは中断します。更新プロセスが、予約領域のアップデート分のプレリード トリガー ファクタの割合を処理する時はいつでも、ジャーナルレコード処理することとグローバル·バッファ·キャッシュにグローバル変数を読み取ることを再開するためにリーダーヘルパープロセスにシグナルを送ります。V5.0-000で、デフォルト値は50です、すなわち、グローバル·バッファの予約領域の更新の50％が、更新プロセスによって処理される時、それらが待機状態だった場合から再開するためには、リーダーヘルパーをトリガします。読み取りを再開するためにリーダーヘルパーへシグナルを送る更新プロセスによって読み取られたレコードの数は次のようになります：
upd_reserved_area*pre_read_trigger_factor*No_of_global_buffers/(avg_blks_read*100)
DSEコマンド change -file_header -pre_read_trigger_factor=n は、現在の領域に、プレリード トリガー ファクタ値を n にセットします。
データベースを管理するためにGT.Mで使用されるパラメータの1つに、フラッシュトリガーがあります。ダーティバッファの数がフラッシュトリガを超えた時、データベース·グローバル·バッファ·キャッシュから、ダーティバッファをフラッシュ開始するまでの、通常のGT.Mプロセスのトリガである、いくつかの条件の1つ。GT.Mプロセスは、通常使用でこの値を動的に調整します。ダーティ グローバル·バッファの数がフラッシュトリガの更新ライタトリガーファクターを超えた時に、ダーティバッファをフラッシュする更新処理自体の必要はない試みでは、ライターヘルパープロセスは、ダーティバッファをディスクにフラッシュすることを開始します。V5.0-000で、デフォルト値は 33、すなわち、33%です。
DSEコマンド change -file_header -upd_writer_trigger_factor=n は、現在の領域に、更新ライター トリガー ファクタ値を n にセットします。
コマンドシンタックス ： UNIXのシンタックス（フラグや修飾子の小文字テキストと"-"）はこの文章全体を通して使われます。VMSは小文字と大文字の両方のテキストを認めます；フラグ/修飾子は、"/" を前にする必要があります。
| |
mとnの両方がOpenVMSで指定されている時に、/helper の値は、 /helper="m,n" のように引用符で囲まれた文字列でなければなりません。 |
リファレンス番号 ： 括弧()で表示されるリファレンス番号は、ソフトウェア強化を突き止めたり、カスタマーサポートの要求するために使用します 。
プラットフォーム識別子 ： 新しい機能やソフトウェアの拡張はすべてのプラットフォームで適用されない場合は、関連のあるプラットフォームがカッコ[ ]で表示されます。
[1] GT.Mトランザクション処理（TSTART / TCOMMIT）の使用、個々のアップデートは、小規模なトランザクションであると考えることができる。
[2] GT.Mレプリケーションの設計は、プライマリがけっしてスローダウンせず、そしてプライマリでのバックログがジャーナルファイル用の空きディスク容量によって完全に制限されていることです。
[3] UNIX / Linux上では少なくとも、システムが使用可能なRAMの量で制約されない限り、おそらくエラーが良いでしょう、もしそれが1つ必要な場合に、積極的であるべき側面では、オペレーティング·システムの統一されたバッファ·キャッシュにあるでしょう。