JP1/Performance Management - Agent Option for HiRDB
ディスク占有量は,パフォーマンスデータを収集するレコード数によって変化します。
PFM - Agent for HiRDBのディスク占有量の見積もりについて説明します。
- <この項の構成>
- (1) システム全体のディスク占有量
- (2) Storeデータベース(Storeバージョン1.0)のディスク占有量
- (3) Storeデータベース(Storeバージョン2.0)のディスク占有量
(1) システム全体のディスク占有量
システム全体のディスク占有量の見積もり値を次の表に示します。
表A-3 システム全体のディスク占有量
PFM - Agent for HiRDBの状態 ディスク占有量(単位:メガバイト) Windows Windows Server 2003(IPF) HP-UX HP-UX(IPF) Solaris AIX Linux(x86),Linux(x64) Linux(IPF) インストール時※1 15 20 35 55 40 100 35 35 初期状態での運用※2 25 30 45 65 50 110 45 45 運用時 a+b a+b a+b a+b a+b a+b a+b a+b
- (凡例)
- a:インスタンスごとのディスク占有量の和。
- b:インストール時のディスク占有量。
- 一つのインスタンスのディスク占有量の算出式を次に示します。
- Σ(c + d + e + f + 18)
- この算出式の合計(Σ)はHiRDBシステムを構成するホストごとに計算します。HiRDB/パラレルサーバの場合,システムマネジャが稼働するホストとそれ以外の各ホストについて上記算出式でディスク占有量を算出します。
- 算出式中のc,d,e,fは,システムマネジャが稼働するホストとシステムマネジャが稼働しないホストで異なります。
- 各値については,次に示す(1),(2)を参照してください。
- (1)システムマネジャが稼働するホストの一つのインスタンスのディスク占有量を算出する場合
- c:Storeデータベースのディスク占有量。Storeデータベースのディスク占有量については,「(2) Storeデータベース(Storeバージョン1.0)のディスク占有量」または「(3) Storeデータベース(Storeバージョン2.0)のディスク占有量」を参照してください。
- d:PI_SSYSレコードの収集時に作成されるワークファイルのディスク占有量。
- dの算出式を次に示します。HiRDBシステムを構成する各ユニットについて計算し,全ユニットの中での最大値をdの値とします。
- ↑0.03*取得回数※3*該当するユニットに含まれるサーバ数↑
- PI_SSYSレコードを収集しない場合は0を設定してください。
- e:PI_RDFSレコードまたはPI_RDFLレコードの収集時に作成されるワークファイルのディスク占有量。
- eの算出式を次に示します。HiRDBシステムを構成する各ユニットについて計算し,全ユニットの中での最大値をeの値とします。
- ↑0.01*シンクポイント発生回数※4↑
- PI_RDFSレコード,PI_RDFLレコードのどちらも収集しない場合は0を設定してください。
- f:PI_SSYSレコード,PI_RDFSレコード,またはPI_RDFLレコードの収集時に作成されるワークファイルのディスク占有量。
- fの算出式を次に示します。HiRDBシステムを構成する各ユニットについて計算し,全ユニットの中での最大値をfの値とします。
- ↑該当するユニットのpd_stj_file_sizeオペランドの値/1024↑*2
- PI_SSYSレコード,PI_RDFSレコード,PI_RDFLレコードのどれも収集しない場合は0を設定してください。
- (2)システムマネジャが稼働しないホストの一つのインスタンスのディスク占有量を算出する場合
- c:0を設定してください。
- d:PI_SSYSレコードの収集時に作成されるワークファイルのディスク占有量。
- dの算出式を次に示します。該当するホスト上で稼働する各ユニットについて計算し,該当するホスト上で稼働する全ユニットの中での最大値をdの値とします。
- ↑0.03*取得回数※3*該当するユニットに含まれるサーバ数↑
- PI_SSYSレコードを収集しない場合は0を設定してください。
- e:PI_RDFSレコードまたはPI_RDFLレコードの収集時に作成されるワークファイルのディスク占有量。
- eの算出式を次に示します。該当するホスト上で稼働する各ユニットについて計算し,該当するホスト上で稼働する全ユニットの中での最大値をeの値とします。
- ↑0.01*シンクポイント発生回数※4↑
- PI_RDFSレコード,PI_RDFLレコードのどちらも収集しない場合は0を設定してください。
- f:PI_SSYSレコード,PI_RDFSレコード,またはPI_RDFLレコードの収集時に作成されるワークファイルのディスク占有量。
- fの算出式を次に示します。該当するホスト上で稼働する各ユニットについて計算し,該当するホスト上で稼働する全ユニットの中での最大値をfの値とします。
- ↑該当するユニットのpd_stj_file_sizeオペランドの値/1024↑*2
- PI_SSYSレコード,PI_RDFSレコード,PI_RDFLレコードのどれも収集しない場合は0を設定してください。
- 注※1
- インストール時にはプログラム本体容量の2倍分のディスク容量が必要となります。
- 注※2
- System Summary Record(PI_PI)レコードおよびServer Lock Control Status(PI_LKST)レコードだけを収集する設定になっているPFM - Agent for HiRDBのインスタンスが,一つだけセットアップされている場合のことを示します。
- 注※3
- 取得回数は以下の算出式で計算します。
- ↑PI_SSYSレコードの収集間隔[秒]/(pdstbeginコマンドの-mオプションに指定した値*60)↑
- 注※4
- シンクポイント発生回数は以下の算出式で計算します。
- ↑PI_RDFLレコードの収集間隔[秒]/該当するHiRDBユニットに含まれる各サーバのシンクポイント間隔の最小値[秒]↑と↑PI_RDFSレコードの収集間隔[秒]/該当するHiRDBユニットに含まれる各サーバのシンクポイント間隔の最小値[秒]↑で大きい値の方
(2) Storeデータベース(Storeバージョン1.0)のディスク占有量
(a) 見積もり式
Storeデータベースでは,各レコードは,レコードタイプごとに一つのファイルに格納されます。Storeデータベースのディスク占有量について,レコードタイプごとに次の表に示します。
- 注意
- パフォーマンスデータがStoreデータベースに格納される際,幾つかのフィールドが追加されます。追加されるフィールドは,ディスク占有量に含まれるため,新たに容量を見積もる必要はありません。
・各レコードに共通して追加されるフィールド
各レコードに共通して追加されるフィールドを次の表に示します。
・PIレコードタイプのデータを要約する際に追加されるフィールド
PFM - View名 PFM - Manager名 説明 Agent Host DEVICEID PFM - Agentが動作しているホスト名。 Agent Instance PROD_INST PFM - Agentのインスタンス名。 Agent Type PRODID PFM - AgentのプロダクトID。 Date DATE レコードが作成された日(グリニッジ標準時)。 Date and Time DATETIME Date(DATE)とTime(TIME)フィールドの組み合わせ。 Drawer Type DRAWER_TYPE PIレコードタイプのレコードの場合,データが要約される区分(分,時,日,週,月,年)。 GMT Offset GMT_ADJUST グリニッジ標準時とローカル時間の差(秒単位)。 Time TIME レコードが作成された時刻(グリニッジ標準時)。
PFM - View名やPFM - Manager名の末尾に,次に示す文字列が付加されているフィールドが該当します。PIレコードタイプのデータを要約する際に追加されるフィールドを次の表に示します。
・jpcctrl dumpコマンドで,Storeのデータベースに格納されているデータをエクスポートする際に追加されるフィールド
PFM - View名 PFM - Manager名 説明 PFM - View名(Total) PFM - Manager名_TOTAL フィールドの合計値。 PFM - View名(Total) PFM - Manager名_TOTAL_SEC フィールドの合計値(utime型の場合)。 PFM - View名(Max) PFM - Manager名_HI フィールドの最大値。 PFM - View名(Min) PFM - Manager名_LO フィールドの最小値。
jpcctrl dumpコマンドで,Storeのデータベースに格納されているデータをエクスポートすると,次のフィールドが出力されます。これらのフィールドもStoreデータベースに格納される際,追加されるフィールドです。これらのフィールドは,PFM - Agent for HiRDBが内部で使用するフィールドであるため,運用で使用しないでください。
- レコードID_DATE_F
- レコードID_DEVICEID_F
- レコードID_DRAWER_TYPE_F
- レコードID_DRAWER_COUNT
- レコードID_DRAWER_COUNT_F
- レコードID_INST_SEQ
- レコードID_PRODID_F
- レコードID_PROD_INST_F
- レコードID_RECORD_TYPE
- レコードID_RECORD_TYPE_F
- レコードID_SEVERITY
- レコードID_SEVERITY_F
- レコードID_TIME_F
- レコードID_UOWID
- レコードID_UOWID_F
- レコードID_UOW_INST
- レコードID_UOW_INST_F
- レコードID_PFM - Manager名_COUNT
- レコードID_PFM - Manager名_SEC
- レコードID_PFM - Manager名_MSEC
- jpcctrl backupコマンドまたはjpcctrl dumpコマンドを実行する場合,バックアップファイルまたはエクスポートファイルには,次の表で算出した容量の約2倍のディスク容量が必要となります。
表A-4 レコードタイプごとのStoreデータベースのディスク占有量
レコードタイプ ディスク占有量の見積もり式(単位:バイト) PIレコードタイプ X1+.....+Xm+3,500*m PDレコードタイプ Y1+.....+Yn+700*n
- (凡例)
- X:PIレコードタイプのレコードで履歴データを収集する各レコードのディスク占有量
- Xの算出式を次に示します。
- X={b*c+(a+1,900)*{(b*c)/(65,250-a)+1}※1}*d*1.5
- Y:PDレコードタイプのレコードで履歴データを収集する各レコードのディスク占有量
- Yの算出式を次に示します。
- Y={b*e+(a+1,900)*{(b*c)/(65,250-a)+1}※1*(e/c)※2}*1.5
- m:PIレコードタイプのレコードで履歴データを収集するレコード数
- n:PDレコードタイプのレコードで履歴データを収集するレコード数
- a:履歴データを収集する各レコードの固定部のサイズ。各レコードの固定部のサイズについては,「6. レコード」のレコードサイズを参照してください。
- b:履歴データを収集する各レコードの可変部のサイズ。各レコードの可変部のサイズについては,「6. レコード」のレコードサイズを参照してください。
- c:履歴データを収集する各レコードのインスタンス数(単数インスタンスレコードの場合は1)
- d:履歴データを収集する各レコードの保存レコード数※3
- e:履歴データを収集する各レコードの保存レコード数※4
- 注※1
- {(b*c)/(65,250-a)+1}の計算結果は,小数点以下を切り捨ててください。
- 注※2
- (e/c)の計算結果は,小数点以下を切り捨ててください。
- 注※3
- PIレコードタイプのレコードの場合,収集したデータがある一定の区分(時,日,週,月,および年単位)に自動的に要約されるので,分,時,日,週,月,および年の部分の保存レコード数を考慮して計算する必要があります。デフォルトの保存期間と保存レコード数を次の表に示します。
データの種類 保存期間 保存レコード数
(収集間隔が1分の場合)分単位 1日 1,440 時単位 7日 168 日単位 1年 366 週単位 1年 52 月単位 1年 12 年単位 制限なし (収集年数)*1
- 注※4
- 保存レコード数については,「付録F.1 Agent Storeサービスのプロパティ一覧」を参照してください。
(b) 見積もり例
PFM - Agent for HiRDBのStoreデータベース(Storeバージョン1.0)の見積もりについて,具体例を用いて説明します。
●ディスク占有量
PI_RDSTおよびPD_SVSTレコードを収集する設定にした場合を例に挙げて説明します。
PI_RDSTレコードの見積もりについて説明します。「(2)(a) 見積もり式」のディスク占有量の見積もり式の,m,n,a〜fの値を調べます。
PI_RDSTレコードの見積もりについて説明します。
m=1
a=681バイト
b=228バイト
c=今回は10とする
PI_RDSTレコードの収集間隔を600秒,年単位の収集年数を2年として,リテンションの設定が表A-4の注※3のとおりである場合。
d=(1,440+168+366+52+12+2*1)*(60/600)*10(cの値)
=2,040レコード
以上から,PI_RDSTレコードの見積もりは次のようになります。
X+3,500*m={228*10+(681+1,900)*{(228*10)/(65,250-681)+1}}*2,040*1.5+3,500*1 ={2,280+2,581*1}*3,060+3,500 =4,861*3,060+3,500 =14,878,160(バイト)=約14.2MB次に,PD_SVSTレコードの見積もりについて説明します。
n=1
a=681
b=105
c=今回は3とする
PD_SVSTレコードの収集間隔を600秒にして,7日分のデータを保存した場合。
e=(86,400/600)*7*3(cの値)
=3,024レコード
なお,PD_SVSTレコードのリテンションの設定のデフォルトは1,000レコードなので,Product Detail - SVSTの値を3,024以上に設定する必要があります。
以上から,PD_SVSTレコードの見積もりは次のようになります。
Y+700*n={105*3,024+(681+1,900)*{(105*3)/(65,250-681)+1}*(3,024/3)}*1.5+700*1 ={317,520+2,581*1*1,008}*1.5+700 =2,919,168*1.5+700 =4,379,452(バイト)=約4.2MBしたがって,必要なディスク占有量はPI_RDST+PD_SVST=約18.4MBとなります。
(3) Storeデータベース(Storeバージョン2.0)のディスク占有量
Storeデータベース(Storeバージョン2.0)のディスク占有量について説明します。
(a) 見積もり式
ディスク占有量,ファイル数,ディレクトリ数,およびStoreサービスがオープンするファイル数の見積もりについて説明します。
●ディスク占有量
Storeデータベースのディスク占有量は,レコードタイプごとのディスク占有量の総和となります。PIレコードタイプについては,さらに要約区分ごとのディスク占有量の総和となります。
- レコードタイプごとのディスク占有量Xの見積もり式(単位:バイト)
X={(e+2)*f+(d+60)*{((e+2)*f)/(65,250-d)+1}※1}*a/b*(c+1)*1.1- a:レコードタイプ,要約区分ごとに値が異なります。表A-5を参照してください。
- b:レコードタイプ,要約区分ごとに値が異なります。表A-5を参照してください。※2
- c:履歴データの保存期間設定値※3。レコードタイプ,要約区分ごとに指定する単位が異なります。単位については表A-5を参照してください。
- d:履歴データを収集する各レコードの固定部のサイズ。各レコードの固定部のサイズについては,「6. レコード」のレコードサイズを参照してください。
- e:履歴データを収集する各レコードの可変部のサイズ。各レコードの可変部のサイズについては,「6. レコード」のレコードサイズを参照してください。
- f:履歴データを収集する各レコードのインスタンス数(単数インスタンスレコードの場合は1)。インスタンス数が2以上の場合,4の倍数に丸め込みます。例えばインスタンス数が2の場合は,f=4となります。インスタンス数が13の場合は,f=16となります。インスタンス数が1の場合は,f=1となります。
表A-5 a,b,およびcに設定する値
レコードタイプ 要約区分 a b c PI 分 1,440 1+(g-1)/60※2 保存期間(単位:日) 時 24 1+(g-1)/3,600※2 保存期間(単位:日) 日 7 1+(g-1)/86,400※2 保存期間(単位:週) 週 1 1+(g-1)/604,800※2 保存期間(単位:週) 月 1 1+(g-1)/2,592,000※2 保存期間(単位:月) 年 1 1+(g-1)/31,622,400※2 10(固定値) PD − 1,440 g/60 保存期間(単位:日)
- (凡例)
- g:履歴データの収集インターバル設定値(単位:秒)
- −:該当しない
- 注※1
- {((e+2)*f)/(65,250-d)+1}の計算結果は,小数点以下を切り捨ててください。
- 注※2
- PIレコードタイプのbの計算結果は,小数点以下を切り捨ててください。
- 注※3
- Storeバージョン2.0の場合のデフォルトの保存期間と保存レコード数を次の表に示します。
表A-6 デフォルトの保存期間と保存レコード数(Storeバージョン2.0の場合)
レコードタイプ データの種類 保存期間 保存レコード数
(収集間隔が1分の場合)PI 分単位 1日 1,440 時単位 7日 168 日単位 54週 378 週単位 54週 54 月単位 12月 12 年単位 10年 (収集年数)*1 PD − 10日 14,400
- (凡例)
- −:該当しない
●ファイル数
Storeデータベースで作成されるファイル数Nの見積もり式を次に示します。
N=20+2*( (A11+A12+...+A1m+m)+ (A21+A22+...+A2m+m)+ (A31+A32+...+A3m+m)+ (A41+A42+...+A4m+m)+ (A51+A52+...+A5m+m)+ (11*m)+ (B1+B2+...+Bn+n) )m:PIレコードで収集しているレコードの数
n:PDレコードで収集しているレコードの数
A11〜A1m:PIレコードタイプのレコードごとの分のレコードの保存期間設定値(単位:日)
A21〜A2m:PIレコードタイプのレコードごとの時のレコードの保存期間設定値(単位:日)
A31〜A3m:PIレコードタイプのレコードごとの日のレコードの保存期間設定値(単位:週)
A41〜A4m:PIレコードタイプのレコードごとの週のレコードの保存期間設定値(単位:週)
A51〜A5m:PIレコードタイプのレコードごとの月のレコードの保存期間設定値(単位:月)
B1〜Bn:PDレコードタイプのレコードごとの保存期間設定値(単位:日)
●ディレクトリ数
Storeデータベースで作成されるディレクトリ数Nの見積もり式を次に示します。
N=25+2*((A1max)+(A2max)+(A3max)+(A4max)+(A5max)+11+(Bmax))A1max:PIレコードタイプで収集しているレコードの要約区分が「分」のデータの保存期間設定値の最大値(単位:日)
A2max:PIレコードタイプで収集しているレコードの要約区分が「時」のデータの保存期間設定値の最大値(単位:日)
A3max:PIレコードタイプで収集しているレコードの要約区分が「日」のデータの保存期間設定値の最大値(単位:週)
A4max:PIレコードタイプで収集しているレコードの要約区分が「週」のデータの保存期間設定値の最大値(単位:週)
A5max:PIレコードタイプで収集しているレコードの要約区分が「月」のデータの保存期間設定値の最大値(単位:月)
Bmax:PDレコードタイプのレコードごとの保存期間設定値の最大値(単位:日)
●Storeサービスがオープンするファイル数
Storeサービスがオープンするファイル数Nの見積もり式を次に示します。
N=20+2*(6*m+n)m:PIレコードで収集しているレコードの数
n:PDレコードで収集しているレコードの数
(b) 見積もり例
PFM - Agent for HiRDBのStoreデータベース(Storeバージョン2.0)の見積もりについて,具体例を用いて説明します。
●ディスク占有量
PI_RDSTおよびPD_SVSTレコードを収集する設定にした場合を例に挙げて説明します。
PI_RDSTレコードの見積もりについて説明します。「(3)(a) 見積もり式」のディスク占有量の見積もり式の,a〜gの値を調べます。
d=681バイト
e=228バイト
f=今回は12とする
g=今回は600秒とする
次に,分レコード,時レコードなどそれぞれの計算を行います。
- 分レコード
- a=1,440
- b=1+(600-1)/60=10.98・・・=10(小数点以下切り捨て)
- c=今回は3日とする
- 見積もり式を次に示します。
X(分)={(228+2)*12+(681+60)*{((228+2)*12)/(65,250-681)+1}}*1,440/10*(3+1)*1.1 ={2,760+741*1}*633.6 =3,501*633.6 =2,218,233.6(バイト)=約2.2MB
- 時レコード
- a=24
- b=1+(600-1)/3,600=1.16・・・=1(小数点以下切り捨て)
- c=今回は3日とする
- 見積もり式を次に示します。
X(時)={(228+2)*12+(681+60)*{((228+2)*12)/(65,250-681)+1}}*24/1*(3+1)*1.1 ={2,760+741*1}*105.6 =3,501*105.6 =369,705.6(バイト)=約0.4MB
- 日レコード
- a=7
- b=1+(600-1)/86,400=1.00・・・=1(小数点以下切り捨て)
- c=今回は1週とする
- 見積もり式を次に示します。
X(日)={(228+2)*12+(681+60)*{((228+2)*12)/(65,250-681)+1}}*7/1*(1+1)*1.1 ={2,760+741*1}*15.4 =3,501*15.4 =53,915.4(バイト)=約0.06MB
- 週レコード
- a=1
- b=1+(600-1)/604,800=1.00・・・=1(小数点以下切り捨て)
- c=今回は1週とする
- 見積もり式を次に示します。
X(週)={(228+2)*12+(681+60)*{((228+2)*12)/(65,250-681)+1}}*1/1*(1+1)*1.1 ={2,760+741*1}*2.2 =3,501*2.2 =7,702.2(バイト)=約0.008MB
- 月レコード
- a=1
- b=1+(600-1)/2,592,000=1.00・・・=1(小数点以下切り捨て)
- c=今回は1か月とする
- 見積もり式を次に示します。
X(月)={(228+2)*12+(681+60)*{((228+2)*12)/(65,250-681)+1}}*1/1*(1+1)*1.1 ={2,760+741*1}*2.2 =3,501*2.2 =7,702.2(バイト)=約0.008MB
- 年レコード
- a=1
- b=1+(600-1)/31,622,400=1.00・・・=1(小数点以下切り捨て)
- c=10(固定)
- 見積もり式を次に示します。
X(年)={(228+2)*12+(681+60)*{((228+2)*12)/(65,250-681)+1}}*1/1*(10+1)*1.1 ={2,760+741*1}*12.1 =3,501*12.1 =42,362.1(バイト)=約0.05MB以上から,PI_RDSTレコードの見積もりは次のようになります。
X(合計)=X(分)+X(時)+X(日)+X(週)+X(月)+X(年) =2.726MB =約2.8MB次に,PD_SVSTレコードの見積もりについて説明します。
a=1,440
b=600/60=10
c=今回は7日とする
d=681バイト
e=105バイト
f=今回は4とする
g=今回は600秒とする
見積もり式を次に示します。
X={(105+2)*4+(681+60)*{((105+2)*4)/(65,250-681)+1}}*1,440/10*(7+1)*1.1 ={428+741*1}*1,267.2 =1,169*1,267.2 =1,481,356.8(バイト)=約1.5MBしたがって,必要なディスク占有量はPI_RDST+PD_SVST=約4.3MBとなります。
●ファイル数
PI_GBUF,PI_RDST,PD_CNSTおよびPD_SVSTレコードを収集する場合を例に挙げて説明します。「(3)(a) 見積もり式」のファイル数の見積もり式の可変値を調べます。
m=2
n=2
A11〜A1m=今回は3日とする
A21〜A2m=今回は3日とする
A31〜A3m=今回は1週とする
A41〜A4m=今回は1週とする
A51〜A5m=今回は1か月とする
B1〜Bn=今回は10日とする
Storeデータベースで作成されるファイル数Nの見積もり式を次に示します。
N=20+2*{ {3(PI_GBUFレコード分)+3(PI_RDSTレコード分)+2}+ {3(PI_GBUFレコード分)+3(PI_RDSTレコード分)+2}+ {1(PI_GBUFレコード分)+1(PI_RDSTレコード分)+2}+ {1(PI_GBUFレコード分)+1(PI_RDSTレコード分)+2}+ {1(PI_GBUFレコード分)+1(PI_RDSTレコード分)+2}+ (11*2)+ {10(PD_CNSTレコード分)+10(PD_SVSTレコード分)+2} } =20+2*{8+8+4+4+4+22+22} =164●ディレクトリ数
PI_GBUF,PI_RDST,PD_CNSTおよびPD_SVSTレコードを収集する場合を例に挙げて説明します。「(3)(a) 見積もり式」のディレクトリ数の見積もり式の可変値を調べます。
A1max=今回は3日とする(考え方:PI_GBUFレコードが2日,PI_RDSTレコードが3日の場合は3日となります)
A2max=今回は3日とする
A3max=今回は1週とする
A4max=今回は1週とする
A5max=今回は1か月とする
Bmax=今回は10日とする(考え方:PD_CNSTレコードが10日,PD_SVSTレコードが8日の場合は10日となります)
Storeデータベースで作成されるディレクトリ数Nの見積もり式を次に示します。
N=25+2*(3+3+1+1+1+11+10) =85●Storeサービスがオープンするファイル数
PI_GBUF,PI_RDST,PD_CNSTおよびPD_SVSTレコードを収集する場合を例に挙げて説明します。「(3)(a) 見積もり式」のStoreサービスがオープンするファイル数の見積もり式の可変値を調べます。
m=2
n=2
Storeデータベースがオープンするファイル数Nの見積もり式を次に示します。
N=20+2*(6*2+2) =48
All Rights Reserved. Copyright (C) 2006, 2008, Hitachi, Ltd.
All Rights Reserved. Copyright (C) 2006, 2008, Hitachi Software Engineering Co., Ltd.