高負荷時のチューニング（環境変数）

システム（コンテナ）は動作しているのに、高負荷で応答が遅い・一部が失敗する、といった場合の原因と、環境変数による調整の指針を示します。

前提として、まずコンテナが停止している / コンテナが異常・再起動を繰り返すと、ホストサーバのリソース状況の確認（CPU・メモリ・ディスクの逼迫）を除外してください。リソースに余裕があるのに遅い・失敗する場合に、本ページの調整が有効なことがあります。

各環境変数の既定値・詳細は環境変数リファレンスを参照してください。本ページは「どの症状でどの変数を調整するか」の導線です。設定の反映方法は構成ごとの構築ガイドに従ってください。

データベース接続数の上限超過（too many clients already）

画面や REST-API が 500 エラーになり、ログに次のエラーが記録されます。DB への新規接続が拒否され、処理が失敗します。

FATAL: sorry, too many clients already

同時に必要な DB 接続数が、接続先 PostgreSQL の最大接続数を超えています。必要な接続数はおおむね次の合計です。

標準シングル構成（内部 postgres）: POSTGRES_MAX_CONNECTIONS（既定 100）を引き上げます。同時 K 件のブロッキング要求（.wait / .recv 等）を捌く目安は K + 約 15。UWSGI_PROCESSES × UWSGI_THREADS を大きくする場合は連動して引き上げてください。
外部DBシングル構成・Swarmクラスタ構成: POSTGRES_MAX_CONNECTIONS は無効です。接続先 DB サーバ側の max_connections を同様に見積もってください。

POSTGRES_WORK_MEM × 同時接続数でメモリ使用量が膨らむため、接続数とあわせてホストの空きメモリにも注意してください（環境変数リファレンス）。

コンテナやホストのリソースは正常なのに、高負荷時に画面・API 全体の応答が遅くなる、または返らなくなります。ジョブフローの .wait / .recv を画面・API（HTTP）経由で多用しているときに顕著です。

同時に処理できる HTTP リクエスト数は UWSGI_PROCESSES × UWSGI_THREADS です。待ち中心の処理（.wait / .recv など）が Web ワーカを長時間占有すると、この枠を使い切り、他の画面・API まで応答できなくなります。

待ち中心の処理が原因なら UWSGI_THREADS（スレッド数） を増やします。CPU を使い切る処理が原因なら UWSGI_PROCESSES（プロセス数） を増やします。
スレッドを増やす場合は UWSGI_THUNDER_LOCK を true にすることを推奨します（accept が公平化され、スレッドを増やした効果が出やすくなります）。
同時処理数を上げると DB 接続も増えるため、データベース接続数の上限超過の見積り（POSTGRES_MAX_CONNECTIONS ≧ K + 約 15）も連動して見直してください。

UWSGI_HARAKIRI（処理時間のハードリミット）は既定で無効です。有効化する場合は全 HTTP リクエストが対象になるため、想定最長時間かつ上記タイムアウトの長い方以上の値にしてください。
なお、nginx の「upstream timed out」が kompira コンテナの停止・過負荷に起因する場合は、タイムアウト延長ではなく nginx の原因と対処を参照してください。本項は「処理自体が正当に長い」場合の調整です。