MySQL の max_connections を決める考え方

max_connections は MySQL が同時に受け付けるクライアント接続の最大数を制限するパラメータです。小さすぎると接続エラーが発生し、大きすぎるとメモリ不足を招きます。適切な値の決め方を解説します。

現在の設定を確認する

SHOW VARIABLES LIKE 'max_connections';

デフォルトは 151 です。小〜中規模のアプリケーションならこれで足りることも多いですが、アクセスが増えると不足します。

接続エラーの確認

max_connections に達すると、新しい接続は拒否されます。この状況が発生したかどうかは以下で確認できます。

SHOW STATUS LIKE 'Connection_errors_max_connections';

0 より大きい値なら、接続上限に達したことがあるということです。

現在の接続数を把握する

適切な値を決めるには、まず現状を把握します。

SHOW STATUS LIKE 'Max_used_connections';
SHOW STATUS LIKE 'Threads_connected';

Max_used_connections が max_connections に近い値なら、上限引き上げを検討すべきです。

計算の考え方

max_connections を決める際は、以下の要素を考慮します。

接続あたりのメモリ消費

各接続は、いくつかのセッションバッファを確保します。

これらの合計 × max_connections が、最悪ケースで必要なメモリ量です。実際には全接続が同時に全バッファを使うわけではありませんが、上限の目安にはなります。

設定例

典型的な設定例を挙げます。

[mysqld]
# 小規模（アプリサーバー2台 × プール20）
max_connections = 100

# 中規模（アプリサーバー5台 × プール30）
max_connections = 200

# 大規模（アプリサーバー10台 × プール50）
max_connections = 600

あくまで目安であり、実際の負荷パターンに合わせて調整してください。

動的に変更する

再起動せずに変更することも可能です。

SET GLOBAL max_connections = 300;

ただし、これは一時的な変更で、再起動すると設定ファイルの値に戻ります。恒久的に変更するなら my.cnf も更新してください。

コネクションプールとの関係

アプリケーション側のコネクションプール設定と整合性を取ることが重要です。

理想的には、全アプリサーバーの最大プールサイズの合計 + 余裕分 が max_connections 以下になるように設計します。

wait_timeout との組み合わせ

アイドル接続が長時間残っていると、接続枠を無駄に消費します。

SHOW VARIABLES LIKE 'wait_timeout';

デフォルトは 28800 秒（8時間）です。Web アプリケーションの場合、もっと短く設定することが多いです。

[mysqld]
wait_timeout = 600  # 10分
interactive_timeout = 600

短くしすぎると、正当な接続まで切断されるので注意が必要です。

監視のポイント

以下の指標を継続的に監視しましょう。

ピーク時に max_connections の 80% を超えるようなら、増量を検討するタイミングです。

まとめ

max_connections は大きければ良いというものではありません。実際の利用パターンに合わせて、適切な値を見極めることが大切です。