Threading limits

Threading limits#

AIDBは、ローカルモデル推論とネットワーク/ボリュームI/Oを内部スレッドプールで実行します。デフォルトでは、ホストで使用可能なCPUの数から自分自身のサイズを調整します。他のワークロードと共有するデータベースサーバー、またはリソースに制限のある小さなコンテナなどでは、バインドされていないスレッドプールが与えたいよりも多くのCPUを消費する可能性があります。

2つのパラメーターは、制限する必要がある作業の種類に応じて、これらのスレッドプールを独立してキャップします。

ローカルモデル推論スレッド#

promoteb.max_threads は、AIDBがローカルモデルの推論に使用するCPUスレッドプールをキャップします—両方のランタイムCandle bert_local 、clip_local 、t5_local 、llama_instruct_local およびllama.cpp llamacpp_generate 、llamacpp_embeddings 。ローカルプロバイダーの完全なリストについては、 Local models を参照してください。

一般にスレッドが多いほど、推論が速くなりますが、CPU使用率が高くなります。多くの同時パイプラインを実行しているホスト、またはCPU割り当てが小さいホストでは、無制限のプールは他のバックエンドのCPU時間を枯渇させる可能性があります。

デフォルトの0 は、使用可能なCPUの半分を使用します。キャップするように特定の数値を設定します。

SET aidb.max_threads = 4;

非同期I/Oスレッド#

quietb.max_io_threads は、 AIDBの非同期I/Oスレッドプールをキャップします。HTTP OpenAI互換エンドポイント、NVIDIA NIM、Gemini、およびOpenRouterを介してリモートモデルプロバイダーを呼び出すために使用され、PGFSバッキングボリュームに対するボリューム/オブジェクトストアI/Oに使用されます。

これは、ローカルモデル推論とは別のリソースです。CPUバウンドの計算ではなく、ネットワークとファイルI/Oの同時実行性を制御します。多くの同時外部API呼び出しを行うパイプライン、または一度に多くのオブジェクトに触れるボリュームスキャンは、制限されたネットワーク帯域幅またはファイル記述子を持つホストで必要なより多くの同時I/Oを開く可能性があります。

デフォルトの0 は、 TOKIO_WORKER_THREADS 環境変数が設定されている場合、それ以外の場合は、CPUごとに1つのスレッド、基になるTokioランタイムの独自のデフォルトにフォールバックします。キャップするように特定の数値を設定します。

SET aidb.max_io_threads = 4;

変更を適用する方法#

どちらのパラメーターも、同じ3つの設定方法を受け入れます。

  • セッションごと 、SET を使用すると —そのバックエンドにのみにすぐに適用されます。ロールアウトする前に制限をテストするのに役立ちます。

  • 接続ごと 、接続文字列またはPGOPTIONS で-c aidb.max_threads=4 を使用します。

  • インスタンス全体 、ALTER SYSTEM SET aidb.max_threads = 4; の後にSELECT pg_reload_conf(); を使用するか、postgresql.conf を直接編集してリロードSIGHUP )。これは、再起動せずにすべてのバックエンドとバックグラウンドワーカーに伝播します。

例、共有ホストでインスタンス全体の両方をキャップするには

ALTER SYSTEM SET aidb.max_threads = 4;
ALTER SYSTEM SET aidb.max_io_threads = 4;
SELECT pg_reload_conf();

パラメーターリファレンスタイプ、デフォルト、範囲については、 スレッド制限 を参照してください。

目次