データベースやintdashサービスのパフォーマンスを最適化したい（インフラ管理者向け）

intdashサーバーのパフォーマンスをチューニングしたい場合は、以下に挙げる推奨設定を参考にしてください。

以下では、intdashが使用するミドルウェアの設定およびintdashの設定のうち、パフォーマンスチューニングに関連するものについてのみ説明します。

PostgreSQLの設定

パフォーマンスチューニングに関連するPostgreSQLのパラメーターを以下に挙げます。各パラメーターの意味に関しては、公式ドキュメント も参照してください。

キャッシュヒット率を高く保つ

  • shared_buffers = メモリサイズの25%～40%

    OSのキャッシュも使用されるので厳密に調整しなくてかまいませんが、おおよそメモリサイズの25%～40%の値にしてください。

WAL(Write Ahead Logging) の生成タイミングを調整する

  • wal_buffers = -1

    WALバッファの容量を設定します。-1 を設定することで、shared_buffers の大きさに合わせて自動調整されるため、-1 にしてください。

ディスクソートが発生しないようにする

  • work_mem = 16MB

    ディスクソートが発生しないよう、ソートを行うのに十分なメモリ容量を設定します。なお、ここで設定するメモリ容量はセッションごとに割り当てられるものであるため、複数のセッションが同時に動作する場合は、この数倍のメモリを消費することになります。

最適なwork_memの値を探すには、trace_sort = on を設定してソートのログを出力し、ディスクソート (external sort) が発生しているかどうかを確認してください。ディスクソートが発生していたら、 work_memを 2 倍 3 倍に大きくしていってください。

チェックポイント間隔を調整する

  • checkpoint_timeout = 30min

    一般的な値である30minとします。

  • checkpoint_completion_target = 0.9

    チェックポイント間隔に対して、どのくらいの割合の時間範囲内に書き込みを完了させるかを設定します。チェックポイントで行われる処理には書き込み以外の処理もあるので、最大でも0.9程度を推奨します。

プランナコストを設定する

  • seq_page_cost = 1.0

  • random_page_cost = 1.0

書き込み先がSSDで、かつ、ランダムアクセス対象のほぼすべてがキャッシュされているような環境では、上記のようにseq_page_cosとrandom_page_costに同程度の値を指定します。これに対し、シーケンシャルアクセスよりランダムアクセスの方が遅いストレージ（HDDなど）を使用している場合は、seq_page_cost より random_page_cost を大きくします。

InfluxDBの設定

パフォーマンスチューニングに関連するInfluxDBのパラメーターを以下に挙げます。InfluxDBの各パラメーターの意味に関しては、公式ドキュメント（ Configure Influx DB OSS ）も参照してください。

データ設定

  • dir = "/data/influxdb/data"

  • wal-dir = "/data2/influxdb/wal"

    実データの書き込み先（dir）とWAL の書き込み先（wal-dir）を指定します。dirとwal-dirは同じディスク上でも問題ありませんが、時系列データベースへの書き込みが全体のパフォーマンスのボトルネックになっている場合、別々のディスクに書き込むようにすることでパフォーマンスが向上します。

  • index-version = "tsi1"

    シャードのインデックスタイプを指定します。InfluxDBのデフォルトであるメモリ内インデックス（inmem）ではなく、ディスクベースのインデックスである時系列インデックスTSI（tsi1）を選択します。

※ index-versionで選択可能な2つのインデックスタイプは以下のとおりです。intdashは計測ごとにシリーズを作成しており、計測が多い場合にシリーズ数の上限に達することがないよう、"tsi1" を推奨しています。

  • TSM Indexes （設定ファイルでの指定はindex-version = "inmem"）

    メモリにのみ保存する方式です。

    • 書き込みスループットが高い
    • クエリ処理が高速
    • CPUリソースの利用量が少ない

  • TSI Indexes （設定ファイルでの指定はindex-version = "tsi1"）

    ホットデータはメモリに、コールドデータはファイルに保存する方式です。

    • RAMの消費が少なく、保持できるシリーズ数についてRAMに起因する上限がない
    • データベースあたりの保存タグ数に上限がない ( "inmem" でも制限の無効化は可能)
    • valueあたりの付与タグ数に上限がない ( "inmem" でも制限の無効化は可能)

TSMエンジンの設定

  • cache-max-memory-size = メモリサイズの半分

  • cache-snapshot-memory-size = cache-max-memory-sizeの1/40

  • cache-snapshot-write-cold-duration = "10m"

    InfluxDBのデフォルト値である"10m"で問題ありません。

  • compact-full-write-cold-duration = "4h"

    InfluxDBのデフォルト値である"4h"で問題ありません。積極的に圧縮を行いたい場合は期間を短くしてください。

  • max-concurrent-compactions = CPUコア数-1

  • compact-throughput = "48m"

    InfluxDBのデフォルト値である"48m"で問題ありません。

  • compact-throughput-burst = "48m"

    InfluxDBのデフォルト値である"48m"で問題ありません。

インメモリ（inmem）インデックス設定

※ index-version = "inmem"とした場合は、こちらの設定が必要です。

  • max-series-per-database = 1000000

    基本的に、InfluxDBのデフォルト値である1000000を推奨します。

  • max-values-per-tag = 0

    無制限を表す0を推奨します。

TSI（tsi1）インデックス設定

※ index-version = "tsi1"とした場合は、こちらの設定が必要です。

  • max-index-log-file-size = "1m"

    influxDBのデフォルト値である"1m"を推奨します。

  • series-id-set-cache-size = 100

    influxDBのデフォルト値である100を推奨します。

SHARD DURATIONの設定

データベースごとにシャードの長さを設定することが可能です。基本的にデフォルトのままで構いません。データ量が多く、圧縮コストの増加によりRAMが逼迫する場合は、1h～12hの値を設定することを推奨します。

SHARD DURATIONを変更する場合、InfluxDBに直接ログインしてクエリを実行するか、InfluxDBのHTTP API経由でクエリを実行します。database名がintdash （デフォルト）のとき、SHARD DURATIONを1hに変更するクエリは以下のようになります。

ALTER RETENTION POLICY "default" ON "intdash" DURATION INF SHARD DURATION 1h REPLICATION 1 DEFAULT

database名がintdash （デフォルト）の場合、現在の設定値は以下のクエリにより確認することができます：

USE intdash
SHOW RETENTION POLICIES

シャードを長くすると、アクセスが非圧縮のアクティブ/「ホット」シャードに集中することにより、読み取りおよび書き込みのパフォーマンスの向上が期待されます。

ただし、シャードを長くすると、圧縮が行われる頻度が低くなるものの1回の圧縮のコストは高くなるため、性能の低下やRAMの枯渇を招く可能性があります。

intdashのMeasurement serviceの設定

パフォーマンスチューニングに関連するMeasurement serviceのパラメーターを以下に挙げます。

[[tsdb-searchers]]
  [tsdb-searchers.influx]
    chunk-size = 10000 # 大きなデータポイントを多く扱う場合100～300に
    timeout-seconds = 3600 # 3600 よりも大きく864000000程度まで

1データポイントあたりのサイズが大きいデータ（動画等）を多く扱う場合、chunk-sizeの値をデフォルトよりも小さな値（100～300程度）にすることで、データ読み込みのパフォーマンスが向上します。
また、1データポイントあたりのサイズが大きく、かつ、1計測あたりの時間が長い計測（目安として1hを超える）が多い場合、timeout-secondsの値を大きくする（時系列データベースからの読み込みのタイムアウト時間を長くする）ことでデータの読み込みが安定します。

intdashのBroker serviceの設定

パフォーマンスチューニングに関連するBroker serviceのパラメーターを以下に挙げます。

[v1-broker]
  store-chan-buffer-size = 再送が頻発する場合、デフォルト16384を2倍または4倍に

エッジからバースト的にアップストリームが行われて再送が頻発する環境の場合、store-chan-buffer-size を大きくすることで（2倍または4倍）、再送の頻度が減り、アップストリームにより受信したデータの保存処理性能が向上する可能性があります。