B 最大データ・グループ・サイズの設定

この付録では、監視対象の通信についてより正確なレポートを作成するために、デフォルトの最大データ・ブラウザ・グループ・サイズを増やす方法について詳しく説明します。デフォルトの設定を変更する前に、提供されている情報を慎重に検討することを強くお薦めします。

最大グループ・サイズと圧縮

パフォーマンスを最適化するためには、個々のグループのサイズを無制限に大きくすることはできません。各メイン・グループの表には、最大許容サイズがあります。デフォルトでは300MBです。セッション診断情報の場合、この制限は500MBです。

グループの最大サイズは、圧縮によって管理されます。これは、使用頻度の最も少ないデータをotherグループに移すことで、グループ表内の行数を減らす方法です。たとえば、クライアント-ブラウザ/バージョンのディメンション内の行には、めったに見られないMozilla Firefoxバージョン用の行が少数含まれている場合があります。この場合、表内の行数は、これらの行を単一のother-firefox行に置き換えることで減らします。

必要な情報が定期的に圧縮されているのであれば、グループの最大サイズを増やすことを検討してもよいでしょう。たとえば、必須の個々のページ名やユーザーIDは、otherとしてしか報告されません。概して、この方法は、ネットワーク通信量が多い場合にお薦めします。

最大グループ・サイズの設定

最大グループ・サイズを150%（450MB）よりおおきく設定している場合、データベースをリモート・データベースとして構成することを強くお薦めします。サポートされている最大グループ・サイズは300%（900MB）です。最大グループ・サイズを増やした場合、データ・ブラウザの問合せに対するレスポンス時間は、処理に長くかかる可能性があるので注意してください。

カスタム・ディメンションは、圧縮プロセスに大きな影響を及ぼすので注意が必要です。カスタム・ディメンションの構成を誤ると、圧縮が過剰になる可能性があります。たとえば、製品名（または、同様に選択性の高い属性）は、圧縮処理をゆがめるので、カスタム・ディメンションとして構成しないでください。具体的には、ページ/製品の各組合せは圧縮処理の別々の候補となり、圧縮後にもそのまま表示されるのは、高頻度の組合せのみになります。

現行のデータ・グループ・サイズを確認するには、定義済のRUEI_USERユーザーとして、次のコマンドを発行します。

cop stats %date_filter

date_filterは、グループ・サイズを表示する日付を指定します。今日の日付を指定すると、グループのサイズはまだ大きくなりつつあるため、報告されるサイズは、最終的なサイズを表していない可能性があります。したがって、より正確に最終的なサイズを判断するには、できるだけ遅く問合せを発行することをお薦めします。前の日の日付（たとえば、昨日）を指定すると、報告されるグループ・サイズには、圧縮済のサイズが反映されています。グループの圧縮済のサイズから圧縮されていないサイズを判断するには、約2倍にする必要があります。

コマンドの例と出力のサンプルは、次のようになります。

cop stats %20091110

   DATA ROWS         DATA SIZE
data    desc      data     desc  cube name
----  ------   -------  -------  ----------
705532  565699  300.0 MB  30.0 MB  wg_visit_dy_20091110 (uncompressed)
918028   48727  303.0 MB   4.0 MB  wg_trans_dy_20091110 (uncompressed)
319163 1043110  169.0 MB  96.0 MB  wg_slowurl_dy_20091110 (uncompressed)
937011  222760  439.0 MB  11.0 MB  wg_sesdiag_dy_20091110 (uncompressed)
005411  005320    2.1 MB   0.3 MB  wg_service_dy_20091110 (uncompressed)
834063  126196  315.0 MB  20.0 MB  wg_page_dy_20091110 (uncompressed)
019008  001026    4.0 MB   5.0 MB  wg_kpi_dy_20091110 (uncompressed)
000345  004598    0.8 MB   0.6 MB  wg_keypage_dy_20091110 (uncompressed)
286384  967535  168.0 MB  88.0 MB  wg_failurl_dy_20091110 (uncompressed)
000378  005544    0.4 MB   0.2 MB  wg_failsrv_dy_20091110 (uncompressed)
632973 2175464  363.0 MB 151.0 MB  wg_failpg_dy_20091110 (uncompressed)

この例では、毎日のAllページ（wg_page_dy）と他の2つのグループが最大限度（300MB）に達し、データが圧縮されています。Failedページのグループ（wg_failpg_dy）は、データが300MBを超えているのに、上限の140万行には達していません。

最大グループ・サイズを設定するには、次のコマンドを発行します。

$ su – moniforce
$ sqlplus /@$RUEI_DB_TNSNAME
SQL> update UXS_CONFIG set VALUE='375000000'
        where NAME='cube_max_size';

値は、最大グループ・サイズ（バイト単位）を指定しています。この例では375MBです。

Failed URLs、Failed servicesおよびFailed pagesグループでは、最大グループ・サイズ設定は使用しません。かわりに、event_max_fail設定によってサイズが制御されます。この設定により、グループのメイン・データベース表に5分間に追加できる最大行数を指定します。デフォルトでは5000行です。Slow URLsグループにはevent_max_slow設定が使用され、5分間ごとに記録される最も遅いURLの数を指定します。デフォルトでは5000行です。

event_max_failまたはevent_max_slow設定を変更する場合、daily_max_fail設定も再確認する必要があります。これは、グループの表に入る最大行数を指定します。最大行数は、288 * event_max_failの式から導出されます。デフォルトは140万行です。

例 - 最大グループサイズの増加

メイン・グループ表の最大サイズを900MB（デフォルトの最大サイズの300%）に増やす場合を考えてみましょう。最大の必須データベース記憶域は、表B-1に示すとおりです。

表B-1 デフォルトの必須データベース記憶域

保存データの種類	デフォルトの保存ポリシー	最大グループ・サイズ（%）	期間当たりに必要なDB領域（GB）	合計必須DB領域（GB）
失敗したページ/URL/サービス	15	300%	4.5	67.5
日	32	300%	3	96
月	13	300%	3	39
年	5	300%	3	15
スイート	15	300%	1.5	22.5
追加のオーバーヘッド				10
合計必須DB領域				250

最大グループ・サイズ変更の効果の確認

最大グループ・サイズ設定を増やした後、レポータ・システムのパフォーマンスに対する変更の効果を注意深く再確認することを強くお薦めします。最低丸1日待ってから、System、Status、Data processingの順に選択します。システム・ロードを再確認し、レポータ・システムで、最大グループ・サイズ設定の増加による追加の処理オーバーヘッドを処理できるかどうかを判断します。

重要: データ・グループ・サイズを増やすと、システム全体のパフォーマンスに大きな影響が出る可能性があります。そのため、データ・グループ・サイズへの変更は、慎重に計画し、処理しやすい手順で実行する必要があります。

データベースの最大サイズの管理

デフォルトでは、RUEIデータベースの最大サイズは960GBに制限されています。これは、操作要件を満たすのに十分なサイズです。ただし、最大データベース・サイズに達するようなことがあると、処理は自動的に停止します。この場合、レポータのデータ保存ポリシーを、使用可能なデータベース記憶域のサイズを反映したものに変更するか、最大データベース・サイズを増やすかしないと、処理を続行できません。