データベースのチューニング:SDK構成ノード

Document created by RSA Information Design and Development on Apr 19, 2018
Version 1Show Document
  • View in full screen mode
 

このトピックでは、データベースに影響を与えるSDK構成ノードについて説明します。各コア サービスには、データベースに関係する追加の構成アイテム(データベースによるデータの格納や取得には影響しない)がいくつかあります。これらの設定は /sdk/config フォルダにあります。

max.concurrent.queries

この設定は、データベースで同時に実行できるクエリ操作の数を制御します。許可する同時クエリ操作の数が多いほど、より多くのユーザにとって全般的な即応性が向上しますが、コア サービスのクエリが高いI/O負荷を要求するようなケースでは、max.concurrent.queriesの値を高くすると、弊害が発生する可能性があります。推奨される値は、システムのCPUコア数に近い値です。そのため、16 CPUコアを搭載したアプライアンスの場合は、32に近い値にする必要があります。集計スレッド用と全般的なシステム応答スレッド用に、値を多少小さくします。ハイブリッド システムの場合(たとえば、DecoderとConcentratorの両方が同じアプライアンスで実行されている場合)は、さらに値を小さくします。最適な値はケースによって異なりますが、通常、16~32に設定すると適切なパフォーマンスが得られます。

max.pending.queries

この設定は、データベースのクエリ エンジンのバックログ サイズを制御します。値を大きくするほど、データベースはより多くの操作を実行キューに入れられるようになります。キューに入ったクエリは待機し、処理が行われません。キューがフルになった場合には、さらにキューを巨大化させるのではなく、システムでエラーを生成する方が効果的です。ただし、レポートなどのバッチ操作を主に実行するシステムでは、サイズの大きいキューを持つことにより、運用がスムーズに行われる場合もあります。

cache.window.minutes

この設定は、多数の同時ユーザがいる場合にクエリの即応性を高めるよう設計されたクエリ エンジンの機能を制御します。キャッシュ ウィンドウの詳細については、「 最適化の手法 」を参照してください。

max.where.clause.cache

Where句キャッシュは、ソートまたはカウント処理のためにサイズの大きな一時データセットを生成するクエリのメモリ消費量を制御します。Where句キャッシュ サイズがオーバーフローした場合、クエリは引き続き機能しますが、処理速度は大幅に下がります。Where句キャッシュが大きすぎる場合は、クエリによって割り当てられるメモリ量が多くなりすぎて、サービスで強制的にスワップが発生したり、メモリ不足になる可能性があります。そのため、この値にmax.concurrent.queriesを掛けた値が、物理RAMのサイズを常に大幅に下回るように設定します。この設定は、数字の後に単位が続く形式、たとえば 1.5 GB のような場合はサイズと見なされます。

max.unique.values

一意の最大値は、SDK値関数で使用できるメモリの量を制限します。SDK値は、一意の値のソートされたリストを生成します。正確な結果を生成するためには、多数のスライスから多数の一意の値をマージする必要がある場合があります。マージされた値のセットをメモリで保持する必要があるので、このパラメータは、マージされた値のセットが使用できるメモリの量に対して制限を設定するために存在します。デフォルト値では、メモリ使用量をRAM合計の約1/10に制限します。

query.level.1.minutes , query.level.2.minutes , query.level.3.minutes

これらの設定は、NetWitness Suite 10.4以前のバージョンで使用できます。

NetWitness Suite 10.4以前では、コア データベースは3つのクエリ優先度レベルをサポートします。各ユーザはいずれかの優先度レベルと関連付けられています。そのため、ユーザ グループの定義においてパフォーマンス チューニングチューニングに関わる項目は3種類あります。これらの設定は、各ユーザのレベルがクエリを実行できる時間の長さを制御します。たとえば、権限の低いユーザほど値を低く設定し、長時間かかるクエリを実行できないよう設定することができます。

query.timeout

この設定は、NetWitness Suite 10.5以降のバージョンで使用できます。

NetWitness Suite 10.5以降では、クエリ レベルが、ユーザ アカウントごとのクエリ タイムアウトで置き換えられています。信頼関係接続の場合、これらのタイムアウトはNetWitness Suiteサーバで構成されます。コア サービスのアカウントについては、各アカウントに、 query.timeout と呼ばれる新しい構成ノードがあります。これは、各クエリが実行できる最長時間(分単位)です。この値をゼロに設定すると、コア サービスではクエリ タイムアウトが実施されません。

max.where.clause.sessions

この設定は、NetWitness Suite 10.5以降のバージョンで使用できます。

この設定により、単一のクエリでスキャンできるセッション数に制限が課されます。たとえば、ユーザがデータベースからすべてのメタを選択すると、クエリのセッション読み取り数がこの構成値に達したときに、データベースによって結果の処理が停止されます。値0はこの制限を無効化します。

クエリを完全に処理するのに必要なセッション数は、そのクエリのWHERE句と一致するセッションの数と同じです。これは、where句のすべての用語に適切なインデックスが作成されていることを前提としています。where句にインデックスが作成されていない用語がある場合、データベースは、さらに多くのセッションとメタを読み取る必要があり、この制限に到達するのが早まります。

max.query.groups

この設定は、NetWitness Suite 10.5以降のバージョンで使用できます。

この設定により、単一のクエリで収集される一意のグループの数に制限が課されます。たとえば、クエリに含まれるgroup by句に複数のメタがあり、一意の値が多数含まれていると、そのクエリに必要なメモリ容量は、サーバ上で使用できるRAM容量を簡単に上回る可能性があります。したがって、この制限は、メモリ不足の発生を防ぐために存在します。

値0を設定すると、この制限が無効になります。

packet.read.throttle

これは、パケット データベースへのアクセスに影響を及ぼす、Decoder専用の設定です。packet.read.throttleが0より大きな値に設定されている場合、Decoderは、パケット データベースでパケット競合を検出したときに、パケット読み取りのスロットリングを試みます。この値が大きいほど、スロットリングが大きくなります。変更は即座に有効になります。

cache.dir , cache.size

すべてのNetWitness Suiteコア サービスで、デバイスから抽出されたrawコンテンツの小さなファイル キャッシュが保持されます。これらのパラメータは、このキャッシュの場所(cache.dir)とサイズ(cache.size)を制御します。

parallel.values

この設定は、NetWitness Suite 10.5以降のバージョンで使用できます。

この設定により、SDK値演算を並列に実行できます。この値を0に設定すると、並列実行は無効化されます。0より大きい値に設定した場合は、その値が、各SDK値演算が実行されるときに作成されるスレッドの数になります。最大値は、プロセスの開始時に利用できる論理CPUの数です。

同時ユーザの数が少ない場合は、parallel.valuesに大きい値を設定すると、より複雑な調査をより短時間で実行できます。同時ユーザの数が多い場合は、小さい値を設定する方が、多くの独立したSDK値演算を同時に実行できます。

parallel.query

この設定は、NetWitness Suite 10.5以降のバージョンで使用できます。

この構成は、最大値が論理CPU数である点で、parallel.values設定と似ています。parallel.queryに特定の値を設定する場合は、使用可能なリソースを常時超過することなくCPUの使用率を最大化できるように、同時ユーザ数を考慮に入れる必要があります。

同時ユーザや同時クエリの数が少ない場合は、parallel.queryに大きい値を設定すると、より複雑なクエリをより短時間で実行できます。同時ユーザや同時クエリの数が多い場合は、小さい値を設定する方が、多くの独立したSDKクエリ演算を同時に実行できます。

クエリ演算は、メタ データベースの読み取りレートレートによって制限されるため、parallel.queryを4より大きい値に設定しても、デフォルト値の0\の場合より結果が大幅に良くなる可能性はありません。parallel.queryに使用する最適な数値は、接続されているストレージのタイプによって異なります。parallel.queryにさまざまな値を試して、お使いのストレージ システムに最適な結果を判断してください。

You are here
Table of Contents > 詳細なデータベース構成 > SDK構成ノード

Attachments

    Outcomes