GT.MのIPCリソースを調べる

GT.MのIPCリソースを調べる
前	付録A：GT.MのIPCリソースの使用法	次

GT.Mは、次のようにUNIX IPC（プロセス間通信 Inter Process Communication (IPC) ）リソースを使用します。

各データベース領域では、GT.Mは、制御構造のために、そして、Mロックを実装するするために、共有メモリセグメント（shmat()に割り当てられた）を使用します。ジャーナルデータベースの場合、ジャーナルバッファは、その共有メモリセグメントに存在します。 BGのデータベースアクセスメソッドを使用して、データベース用のグローバルバッファもそこに存在しています。プロセスによってオンラインヘルプシステムの使用は、BGのアクセスメソッドを使用してデータベースファイルを開くことに注意してください。データベースファイルをオープンする最初のプロセスが、共有メモリセグメントを作成し初期化し、そして、終了する最後のプロセスは、通常は、共有メモリセグメントをクリーンアップし削除します。しかし、最後のプロセスの特定の異常終了の下で（例えば、もし kill -KILLで終了されている場合）、その最後のプロセスが、"孤立" した共有メモリセグメント（接続がされていないプロセスでこれらが）の結果を生じる共有メモリセグメントをクリーンアップできない場合があります）。
MMアクセス方式を使うデータベースの領域では、ファイルシステムは、メモリマップのデータベースファイルに追加の共有メモリセグメント（ mmap()で割り当てられている）を管理します。 GT.Mは、この共有メモリを明示的に割り当てません。 UNIXは、GT.Mがデータベースファイルを開いた時に共有メモリセグメントを割り当て、そして、プロセスが終了した時にそれを解放するため、 mmap()によって割り当てられたそのような共有メモリセグメントは、けっして孤立することはありません。
レプリケートするとき、GT.Mは、共有メモリセグメント内のプライマリ上のジャーナルプールを実装しています。2番目では、GT.Mは受信プールの共有メモリセグメントを使用します。
もし1つ以上のプロセスが同時にデータベースファイルを開く場合でさえも、あたえられたデータベースファイル用の共有メモリセグメントを作成するようなGT.Mのオペレーションは、1つのプロセスによってのみ実行する必要があります。 GT.Mは、これらのオペレーションがシングルスレッドであることを保証するパブリックなUNIXセマフォのセットを使用します。 GT.Mは、shmat()で割り当てられた共有メモリセグメントをセットアップし分解するためにパブリックなセマフォの他のセットを使用します。
パブリックなセマフォIDは非ユニークかもしれません。プライベートなセマフォIDは、各データベースに対して常にユニークです。
キーのスタート 0x2b と 0x2cを持つセマフォは、スタートアップとランダウンのセマフォーです。GT.Mプロセスは、データベースへアタッチまたはデータベースからデタッチしている間、それらを使用しています。
IPCリソースにアタッチされているプロセスの数とセマフォの数は、データベースの状態に応じて異なる場合があります。一部の共有メモリ領域は、それら( nattch 列) にアタッチされている0 個のプロセスを持ちます。もしこれらが、GT.Mデータベース領域へ、または、グローバルディレクトリへ対応している場合、それらは GT.M（GT.Mプロセスは ps コマンドで" mumps " として表示）とGT.Mユーティリティプロセスの不適切なプロセスの終了からほとんどの可能性があります；ソースサーバ、レシーバサーバ、または更新プロセス（ mupip "として現れる）；または他のGT.Mユーティリティ (" mupip ", " dse ", または " lke ")。
インスタンスは1つのジャーナルプールをもち、もしリプリケーションインスタンスならば、1つのレシーバプールも持ちます。同じコンピュータシステム上で、複数のインスタンスを実行される可能性があることに注意してください。
シンプルなGT.M オペレーション（つまり、マルチサイトレプリケーションでない）の場合は、ジャーナルプールまたはレシーバプールはありません。

次の演習では、GT.MはマルチサイトのデータベースレプリケーションのコンフィグレーションでIPC資源を利用する方法を示しています。タスクは、2つの異なる場所に2台のサーバ上に複製されたGT.Mデータベースコンフィグレーションを設定することです。

このタスクの手順は次のとおりです。

2つの異なるサーバ ( Server_A と Server_B) 上に、 2のデータベース-America (アメリカ)と Brazil (ブラジル) を作成してください、そして、America (アメリカ) はプライマリサイトで Brazil (ブラジル)がセカンダリサイトになるように、マルチサイトデータベースのレプリケーション構成でそれらを配置してください。いずれかのサーバ上には、GT.Mプロセスが存在しないことを確認してください。
Server_Aの中で、そして、America (アメリカ)のデータベースファイルに保持しているディレクトリに、以下のコマンドを与えてください（注意：デフォルトのジャーナルプールのサイズは、64MB、1048576バイトの値ですので、この演習のための1MBのGT.Mの最小サイズ）：
```
$ export gtm_repl_instance=multisite.repl 
$ mupip replicate -instance_create -name=America 
$ mupip set -replication=on -region "*" 
$ mupip replicate -source -start -buf=1048576 -secondary=Server_B:1234 -log=A2B.log -instsecondary=Brazil
```
すぐに、次のコマンドを実行します。
```
$ gtm_dist/ftok mumps.dat multisite.repl
```
このコマンドは、mumps.datとその複製のインスタンス multisite.replのための "パブリック"（システム生成）のIPCキー（基本的にハッシュ値）を生成します。次のようなサンプル出力を生成します。
```
  mumps.dat :: 721434869 [ 0x2b0038f5 ] 
multisite.repl :: 721434871 [ 0x2b0038f7 ]
```

0x2b（16進形式）で始まるキーは、レプリケーションインスタンスファイルの 0x2c によって置き換えられる16進順序の 0x2bより高い、レプリケーションインスタンス America (アメリカ) で使われるセマフォのキーです（ジャーナルプールのためのセマフォ用のGT.Mの標準の接頭辞は0x2cで、および、データベースファイル用は0x2bです）。 ipcs コマンドでこれを観察することができます。

------ Semaphore Arrays --------
key  semid owner perms nsems
0xd74e4524 196608 welsley 660 1
0x2c0038f7 983041 welsley 777 3
0x00000000 1015810 welsley 777 5
0x2b0038f5 1048579 welsley 777 3
0x00000000 1081348 welsley 777 3

注意

同じパブリック ftok を共有する別のファイルシステム内のファイルを期待できます。これは、複数のインストールを持つ大規模システムでは正常な動作ですし、どのような方法であってもGT.Mのオペレーションには影響しません。、GT.Mがセマフォがリソースで1対1のリレーションシップを持つことと、スタートアップ/シャットダウンの操作が比較的まれであること、を想定していないため、したがってリソース間の干渉が最小限あるいはまったく影響を持ちません。しかし、プライベートセマフォは ( 0 キーで)、データベースに対してユニークで、プロセスがアクティブにリソースを使用しているときに、使用されます。

次のコマンドを実行し、インスタンスアメリカの上の 共有メモリのID とプライベートセマフォのIDを書き留めてください。
```
$ mupip ftok mumps.dat
```
このコマンドは、プロセスがすべて"正常"なアクセスを使用する "プライベート"（GT.Mが生成）セマフォを識別します。このコマンドの出力例は、次のようになります。
```
File  ::   Semaphore Id   ::   Shared Memory Id  :: FileId
---------------------------------------------------------------------------------------------------------------
mumps.dat ::  1081348 [0x00108004] :: 2490370 [0x00260002] :: 0xf53803000000000000fe000000000000ffffffd2 
```
今、次のコマンドを実行し、ジャーナルプールの共有メモリとプライベートセマフォIDを書き留めます。
```
$ mupip ftok -jnl multisite.repl
```
このコマンドの出力例は、次のようになります。
```
File   :: Semaphore Id     ::   Shared Memory Id  :: FileId
---------------------------------------------------------------------------------------------------------------
multisite.repl :: 1015810 [0x000f8002]  ::  2457601 [0x00258001] :: 0xf73803000000000000fe000000000000ffffffd2
```
セマフォID1015810 と共有メモリID 2457601は、下記の ipcd -a コマンドの出力例にあることに注意してください。

現在のIPC資源を表示するためにはコマンド ipcs -a を実行してください。このコマンドは、以下の出力を生成します：

------ Shared Memory Segments --------
key  shmid owner perms bytes nattch status
0x00000000 0  root  777 122880 1
0x00000000 2457601 welsley 777 1048576 1
0x00000000 2490370 welsley 777 2633728 1
0x00000000 2523139 welsley 600 393216 2  dest
0x00000000 2555908 welsley 600 393216 2  dest
0x00000000 1048583 welsley 600 393216 2  dest
0x00000000 1081352 welsley 600 393216 2  dest
0x00000000 1114121 welsley 666 376320 2
0xd74e4524 1146890 welsley 660 64528 0
0x00000000 1933323 welsley 666 62500 2
0x00000000 1966092 welsley 666 1960000 2
------ Semaphore Arrays --------
key  semid owner perms nsems
0xd74e4524 196608 welsley 660 1
0x2c0038f7 983041 welsley 777 3
0x00000000 1015810 welsley 777 5
0x2b0038f5 1048579 welsley 777 3
0x00000000 1081348 welsley 777 3
 
------ Message Queues --------
key  msqid owner perms used-bytes messages

n はマルチサイトレプリケーション構成でGT.MのIPCリソースを計算するための領域の数で、次の式を使います：

IPCs = (n regions * (1 shm/region + 1 ftok sem/region + 1 private sem/region)) 
+ 1 sem/journal-pool + 1 sem/receiver-pool

この場合、America(アメリカ) は、1つの領域を持ち、レシーバプールはありません。

1 region * 3 IPCs/region + 1 IPC/journal-pool = 4 IPCs

したがって、GT.Mによって利用される合計のIPCは、 America (アメリカ)のインスタンスは1領域を持っていると仮定し、それは、4 [1 * 3 + 1 +0] です。 America(アメリカ)のためのレシーバのプールが存在しないことに注意してください。

	注意
	`MUPIP RECOVER` オペレーションでは、IPCリソースの総数は、`3n` です（ジャーナルプールまたはレシーバプールが存在しないため）、 n は領域の数です。

今すぐ、 Server_B に接続し Brazil(ブラジル)のデータベースファイルを保持しているディレクトリで、次のコマンドを与えてください：
```
$ export gtm_repl_instance=multisite1.repl 
$ mupip replicate -instance_create -name=Brazil $ mupip rundown -region "*"
$ mupip set -journal="enable,before,on" -replication=on -region "*"
$ mupip replicate -source -start -passive -buf=1048576 -log=B2dummy.log -inst=dummy 
$ mupip replicate -receive -start -listenport=1234 -buf=1048576 -log=BFrA.log
```
すぐに、次のコマンドを実行します：
```
$gtm_dist/ftok mumps.dat multisite1.repl
```
このコマンドは、 mumps.dat の "パブリック"（システムによって生成）IPCキーと、そのレプリケーションインスタンス multisite1.replを生成します。次のようなサンプル出力を生成します。
```
  mumps.dat :: 722134735 [ 0x2b0ae6cf ]
multisite1.repl :: 722134737 [ 0x2b0ae6d1 ]
```
ipcs -a コマンドの出力の中の 0x2b で始まるキーは、レプリケーションインスタンス Brazil (ブラジル)上のデータベースファイルのセマフォのパブリック IPCキーであることに、注意してください。
その後、次のコマンドを実行し、 共有メモリ ID と、インスタンス Brazil (ブラジル)上のプライベートセマフォIDを書き留めてください。
```
$ mupip ftok mumps.dat
```
このコマンドは、プロセスがすべて"正常"なアクセスを使用する "プライベート"（GT.Mが生成）セマフォを識別します。このコマンドの出力例は、次のようになります。
```
File :: Semaphore Id  :: Shared Memory Id :: FileId
--------------------------------------------------------------------------------------------------------------
mumps.dat :: 327683 [0x00050003] :: 11665410 [0x00b20002]:: 0xcfe63400000000000a0000000000000000000000
```
今、次のコマンドを実行し、ジャーナルプールの共有メモリとプライベートセマフォIDを書き留めます。
```
$ mupip ftok -jnl multisite1.repl
```
このコマンドの出力例は、次のようになります。
```
File  :: Semaphore Id  :: Shared Memory Id :: FileId
---------------------------------------------------------------------------------------------------------------
multisite1.repl :: 262145 [0x00040001] :: 11632641[0x00b18001]:: 0xd1e63400000000000a0000000000000000000
```
セマフォID 262145 と共有メモリID 11632641 は、下記の ipcd -a コマンドの出力例にあることに注意してください。

今、Brazil (ブラジル) のIPCリソースを表示するためにコマンド ipcs -a を実行してください。

このコマンドは、以下のサンプル出力を生成します。

------ Shared Memory Segments --------
key  shmid owner perms bytes nattch status
0x00000000 11632641 gtmuser 777 1048576 3
0x00000000 11665410 gtmuser 777 2629632 2
0x00000000 11698179 gtmuser 777 1048576 2
------ Semaphore Arrays --------
key  semid owner perms nsems
0x2c0ae6d1 229376 gtmuser 777 3
0x00000000 262145 gtmuser 777 5
0x2b0ae6cf 294914 gtmuser 777 3
0x00000000 327683 gtmuser 777 3
0x00000000 360452 gtmuser 777 5
------ Message Queues --------
key  msqid owner perms used-bytes messages

Brazil (ブラジル)は 1つの地域を持ち、そのレシーバサーバは、America (アメリカ)をリッスンしていて、従って、、GT.M IPC リソースを計算する式ごとにつき、GT.Mによって利用される合計のIPCは：[1 * 3 + 1 + 1] です。

前	上	次
付録A：GT.MのIPCリソースの使用法	ホーム	gmtsecshr