このトピックでは、データベースに影響を与える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のような場合はサイズと見なされます。
query.level.1.minutes、query.level.2.minutes、query.level.3.minutes
これらの設定は、Security Analytics 10.4以前のバージョンで使用できます。
Security Analytics 10.4以前では、データベースは3つのクエリー優先度レベルをサポートします。各コア ユーザーはいずれかの優先度レベルと関連付けられています。そのため、ユーザー グループの定義においてパフォーマンス チューニングに関わる項目は3種類あります。これらの設定は、各ユーザーのレベルがクエリーを実行できる時間の長さを制御します。たとえば、権限の低いユーザーほど値を低く設定し、長時間かかるクエリーを実行できないよう設定することができます。
query.timeout
この設定は、Security Analytics 10.5以降のバージョンで使用できます。
Security Analytics 10.5以降では、クエリー レベルが、ユーザー アカウントごとのクエリー タイムアウトで置き換えられています。信頼関係接続の場合、これらのタイムアウトはSecurity Analyticsサーバで構成されます。コア サービスのアカウントについては、各アカウントに、query.timeoutと呼ばれる新しい構成ノードがあります。これは、各クエリーが実行できる最長時間（分単位）です。この値をゼロに設定すると、コア サービスではクエリー タイムアウトが実施されません。
max.where.clause.sessions
この設定は、Security Analytics 10.5以降のバージョンで使用できます。
この設定により、単一のクエリーでスキャンできるセッション数に制限が課されます。たとえば、ユーザーがデータベースからすべてのメタを選択すると、クエリーのセッション読み取り数がこの構成値に達したときに、データベースによって結果の処理が停止されます。値0はこの制限を無効化します。
クエリーを完全に処理するのに必要なセッション数は、そのクエリーのWHERE句と一致するセッションの数と同じです。これは、where句のすべての用語に適切なインデックスが作成されていることを前提としています。where句にインデックスが作成されていない用語がある場合、データベースは、さらに多くのセッションとメタを読み取る必要があり、この制限に到達するのが早まります。
max.query.groups
この設定は、Security Analytics 10.5以降のバージョンで使用できます。
この設定により、単一のクエリーで収集される一意のグループの数に制限が課されます。たとえば、クエリーに含まれるgroup by句に複数のメタがあり、一意の値が多数含まれていると、そのクエリーに必要なメモリ容量は、サーバ上で使用できるRAM容量を簡単に上回る可能性があります。したがって、この制限は、メモリ不足の発生を防ぐために存在します。
値0を設定すると、この制限が無効になります。
packet.read.throttle
これは、パケット データベースへのアクセスに影響を及ぼす、Decoder専用の設定です。packet.read.throttleが0より大きな値に設定されている場合、Decoderは、パケット データベースでパケット競合を検出したときに、パケット読み取りのスロットリングを試みます。この値が大きいほど、スロットリングが大きくなります。変更は即座に有効になります。
cache.dir、cache.size
すべてのSecurity Analytics Coreサービスで、デバイスから抽出されたrawコンテンツの小さなファイル キャッシュが保持されます。これらのパラメーターは、このキャッシュの場所（cache.dir）とサイズ（cache.size）を制御します。
parallel.values
この設定は、Security Analytics 10.5以降のバージョンで使用できます。
この設定により、SDK値演算を並列に実行できます。この値を0に設定すると、並列実行は無効化されます。0より大きい値に設定した場合は、その値が、各SDK値演算が実行されるときに作成されるスレッドの数になります。最大値は、プロセスの開始時に利用できる論理CPUの数です。
同時ユーザーの数が少ない場合は、parallel.valuesに大きい値を設定すると、より複雑な調査をより短時間で実行できます。同時ユーザーの数が多い場合は、小さい値を設定する方が、多くの独立したSDK値演算を同時に実行できます。
parallel.query
この設定は、Security Analytics 10.5以降のバージョンで使用できます。
この構成は、最大値が論理CPU数である点で、parallel.values設定と似ています。parallel.queryに特定の値を設定する場合は、使用可能なリソースを常時超過することなくCPUの使用率を最大化できるように、同時ユーザー数を考慮に入れる必要があります。
同時ユーザーや同時クエリーの数が少ない場合は、parallel.queryに大きい値を設定すると、より複雑なクエリーをより短時間で実行できます。同時ユーザーや同時クエリーの数が多い場合は、小さい値を設定する方が、多くの独立したSDKクエリー演算を同時に実行できます。
クエリー演算は、メタ データベースの読み取りレートによって制限されるため、parallel.queryを4より大きい値に設定しても、デフォルト値の0の場合より結果が大幅に良くなる可能性はありません。parallel.queryに使用する最適な数値は、接続されているストレージのタイプによって異なります。parallel.queryにさまざまな値を試して、お使いのストレージ システムに最適な結果を判断してください。
