低RAM VPS上のDebian 12：MySQLのメモリ不足クラッシュを減らす方法

メモリ容量の少ない Debian 12 VPS で OOM キラーによって MySQL が停止するリスクを軽減するには、原因を特定し、すべてのサービスでメモリを配分し、データベースの同時実行数を制限し、VPS が許可する範囲でスワップ領域を確保する必要があります。InnoDB バッファプールを小さくするだけでは、完全な解決策にはなりません。スワップ領域や OOM 保護設定は、過大なワークロードが継続して実行されることを保証するものではありません。

このガイドは、2026年10月9日に、Debian 12「bookworm」、Linux 6.1、およびOracle MySQL 8.0/8.4のドキュメントを使用して調査されました。以下の設定は、ベンチマーク結果や普遍的な構成ではなく、あくまでも出発点となる例です。変更を加える前にデータベースと構成をバックアップし、ダウンタイムが許容できる場合にデータベースの再起動をスケジュールしてください。

1. MySQL設定をコピーする前にサーバーを特定する

検証済み： Debian 12のdefault-mysql-serverパッケージはMariaDBに依存しています。「MySQL」を実行していると説明されているVPSでも、実際にはMariaDBを実行している場合があり、別のVPSでは別のリポジトリまたはコンテナからOracle MySQLを実行している場合があります。

mysql --version
systemctl status mysql mariadb

最初のコマンドはクライアントを識別するものであり、実行中のサーバーを必ずしも識別するものではありません。データベース管理者アカウントを使用して接続し、次のコマンドを実行してください。

SELECT VERSION(), @@version_comment;

既存の認証方法を使用してください。Debian MariaDB インストールでは、ローカル管理が可能な場合がありますsudo mysql。サーバーのバージョンと実際のサービス名を記録してください。以降のサービス コマンドではmysql.service、 を使用します。必要に応じて に置き換えてくださいmariadb.service。Oracle 専用の変数を MariaDB の設定に追加しないでください。

2. シャットダウンがOOMイベントであったことを確認する

よくある誤解：原因不明のデータベース再起動はすべてメモリ不足による強制終了である。認証エラー、ディスク容量不足、無効な構成、クラッシュ、管理者による再起動などもサービスの中断につながる可能性がある。

sudo journalctl -k -b
sudo journalctl -u mysql.service --since today
sudo journalctl -u systemd-oomd --since today

インシデント発生時刻付近のカーネルメッセージで、メモリ不足状態と強制終了されたプロセスを示すものを探し、それらのメッセージをサービスログと照合してください。パッケージがエラーログをジャーナルではなくファイルに書き込む場合は、データベースのエラーログも確認してください。インシデントが再起動前に発生した場合は、journalctl -k -b -1保持ログが利用可能な場合は、前回の起動時のログを確認してください。履歴ログが欠落している場合は、原因を特定できません。

ユーザー空間マネージャもワークロードを終了させることができます。Debianのsystemd-oomdマニュアルには、カーネルのOOMイベントが発生する前にメモリ負荷に基づいて介入する方法が記載されています。すべてのDebian VPSで使用されていると想定するのではなく、実際にインストールされ、アクティブになっているかどうかを確認してください。

systemdの制限も確認してください。

systemctl show mysql.service \
  -p ControlGroup -p MemoryCurrent -p MemoryHigh \
  -p MemoryMax -p MemorySwapMax

cgroup v2 システムでは、報告された ControlGroup パスを使用してmemory.events、 、memory.max、 およびmemory.swap.maxを の下から読み取ります/sys/fs/cgroup。親 cgroup も確認してください。Linux cgroup v2 のドキュメントには、これらのカウンタと制限について説明されています。ホストに容量があっても、cgroup は許可されたメモリを使い果たす可能性があります。カウンタはoom_kill強制終了を記録しますが、原因を特定するには制限とログと合わせて解釈する必要があります。

3. バッファプールだけでなく、VPS全体を測定する。

free -h
ps -eo pid,comm,rss --sort=-rss
vmstat 1

通常のトラフィック時と障害に関連するジョブの観測データを収集します。 ではfree、空き列だけでなく、利用可能なメモリに注目してください。Debian のフリーマニュアルでは、利用可能なメモリはスワップなしで使用できるメモリの推定値として説明されています。プロセス一覧の RSS 値は KiB 単位です。これらを加算すると、共有メモリが二重にカウントされる可能性があります。

検証済み： MySQLは、接続やクエリ関連の割り当てを含め、InnoDBのバッファプールを超えるメモリを割り当てます。これらのコンポーネントについては、 MySQLのメモリ使用量リファレンスに記載されています。構成済みバッファに基づく計算式は、正確な上限値ではなく、あくまで計画上の概算値として扱ってください。

対策：カーネル、Webワーカー、監視、バックアップ、および一時的なデータベース処理のために容量を確保してください。共有VPSでは、調整なしでは、ほとんどのRAMをInnoDBに割り当てるという一般的なアドバイスは適切ではありません。PHPワーカーまたはビルドジョブが利用可能なヘッドルームを消費している場合は、MySQLを繰り返し縮小するのではなく、そのワークロードを調整または移動してください。

4. スワップ領域をRAMの代替としてではなく、バッファとして追加する

状況によります。スワップは一時的な匿名メモリの負荷をある程度吸収できますが、継続的なスワッピングはクエリの速度を著しく低下させる可能性があります。コンテナベースのVPSではスワップが制限される場合があり、MemorySwapMaxホストにスワップ領域があってもサービスによってはスワップの使用が制限されることがあります。

swapon --show
free -h
df -h /
findmnt -no FSTYPE /

スワップ領域が存在しない場合、プロバイダがそれを許可し、かつ十分なディスク容量がある場合は、以下の手順でext4などの適切なローカルファイルシステム上に1GiBのスワップファイルを作成します。/swapfileが既に存在する場合は、この手順を実行しないでください。まず、ファイルシステム固有の要件を確認してください。Btrfsでは、適切なコピーオンライト方式のスワップファイル設定が必要です。

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

アクティベーションが成功した後のみ、このエントリを一度だけ追加してください/etc/fstab。

/swapfile none swap sw 0 0

Debianのswaponマニュアルには、スワップファイルの制約について記載されています。VPS環境でアクティベーションが拒否された場合は、プロバイダにサポートされているスワップについて問い合わせるか、プランのメモリを増やしてください。失敗した設定をそのままにしないでください。

「スワップネスをゼロに設定する」という設定をOOM対策としてコピーしないでください。カーネルVMのドキュメントでは、スワップネスはメモリ解放コストの優先順位として定義されています。メモリを生成したり、データベースのメモリ制限を課したりするものではありません。最初は変更せずに、動作を測定してください。

5. 控えめなデータベースのベースラインを設定する

例として、InnoDBワークロードが小さく、アプリケーションワーカーが数個ある1GiBのVPSを考えてみましょう。以下の値は評価対象となる候補値であり、このワークロードが適合することを示す証拠ではありません。

[mysqld]
innodb_buffer_pool_size=128M
max_connections=20
tmp_table_size=16M
max_heap_table_size=16M

サーバーオプションは、インストール時に同梱されている設定ファイルに記述してください。Oracle MySQL パッケージには が含まれている場合があります。Debian /etc/mysql/mysql.conf.d/MariaDB では一般的に が使用されます/etc/mysql/mariadb.conf.d/。既存の include ディレクティブを確認し、バックアップを作成してください。MySQL のオプションファイルに関するドキュメントには、サーバーオプショングループとファイルの取り扱いについて説明されています。

128 MiBのバッファプールはキャッシュを制限するものであり、データベース全体のメモリを制限するものではありません。複数のアプリケーションインスタンスがそれぞれプールを保持している場合、接続制限を20に設定すると制限が厳しすぎる可能性があります。逆に、20件の同時実行の重いクエリはVPSに過負荷をかける可能性があります。アプリケーションプールの合計数を、管理アクセス用の余裕を残しつつ、想定されるサーバー制限以下に抑え、拒否された接続を監視してください。

上記の共通変数はMariaDBのシステム変数リファレンスにも記載されていますが、一時テーブルの動作は製品とバージョンによって異なります。制約のあるマシンで一般的なパフォーマンス改善策として、グローバルソート、結合、または読み取りバッファを増やすことは避けてください。

6. 一時テーブルと並行処理を同時に制御する

よくある誤解：この設定によりtmp_table_size=16M、すべてのクエリメモリが16MiBに制限される。そうではありません。複数のセッション、複数の一時テーブル、およびその他の実行メモリ割り当てが共存できます。

Oracle MySQL 8.4の場合、追加の参考例として以下の例が挙げられます。

temptable_max_ram=64M
temptable_max_mmap=0

製品サポートを確認した後でのみ、既存の[mysqld]グループ内にこれらを追加してください。これらは、TempTable エンジンの共有 RAM しきい値とメモリマップド一時ファイルの使用を制御します。mysqld プロセス全体またはすべてのスレッドローカル割り当てを制限するものではありません。しきい値を低く設定すると、より多くの処理がディスクに書き込まれる可能性があります。

MySQL 8.4 の一時テーブルのドキュメントには、これらの制限について説明されています。MySQL 8.0 ではバージョンによって動作が異なります。8.0.23temptable_max_mmapで導入され、tmp_table_size8.0.28 で個別の一時テーブル制限となりました。同じ設定を適用する前に、 MySQL 8.0 のリファレンスを参照してください。これらの Oracle 固有のオプションを MariaDB にコピーしないでください。

対策：重複するレポートクエリ、バックグラウンドワーカー、バックアップジョブ、インポートジョブを制限してください。特定の操作で負荷が高まった場合は、クエリプランとインデックスを確認してください。負荷の高い処理をピーク時のトラフィックから外すことで改善できます。それでも通常の同時実行需要が容量を超える場合は、RAMの増設またはデータベースの分離が適切な次のステップとなります。

7. 変更を検証し、意図的に再起動する

このオプションをサポートするOracle MySQLバージョンでは、再起動する前に設定を確認してください。

sudo mysqld --validate-config

デフォルト構成検出を使用しない場合は、サービスと同じデフォルトファイルパスと関連する起動引数を使用してください。MySQLの検証リファレンスには、検証ではすべてのサブシステムが初期化されるわけではないと記載されています。検証に合格しても、ワークロード容量テストにはなりません。MariaDBがこのOracleオプションをサポートしていると想定しないでください。

計画された時間帯に実際のサービスを再起動し、起動状況を確認して有効な値を照会します。

sudo systemctl restart mysql.service
systemctl status mysql.service
sudo journalctl -u mysql.service --since today

SHOW GLOBAL VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','max_connections','tmp_table_size',
 'max_heap_table_size','temptable_max_ram','temptable_max_mmap');
SHOW GLOBAL STATUS WHERE Variable_name IN
('Threads_connected','Threads_running','Max_used_connections');

サポートされていない変数は結果に表示されません。新しいファイルが優先されたと決めつけるのではなく、意図した設定を確認してください。変更が原因で起動に失敗した場合は、保存した設定を復元するか、新しい上書き設定のみを削除してから再起動してください。診断のためにエラーの詳細を保存してください。

8. 代表負荷における成功の定義

free -h
vmstat 1
cat /proc/pressure/memory

変更前と変更後の同じトラフィックとスケジュールされたジョブを比較します。新しい OOM イベント、データベースの再起動、使用可能なメモリ、接続拒否、スワップ アクティビティ、クエリのレイテンシを追跡します。 ではvmstat、継続的なスワップ イン/スワップ アウトは調査に値します。Debian vmstat マニュアルでは、最初のレポートは起動以降のアクティビティの平均を表し、後続のレポートは現在のレートを示すと説明されています。

カーネルのPSIリファレンスには、圧力ストール測定について記載されています。メモリストール時間を長くすることで、強制終了される前に問題が明らかになる場合があります。システムが10分間アイドル状態を維持できたとしても、次のバックアップやトラフィックの急増が安全であるとは限りません。

問題を悪化させる可能性のある誤解

Debianのsystemdリソース制御マニュアルには、ユニット内でOOM処理を呼び出すことができると説明されていますMemoryMax。プロバイダやコンテナの制限を安易に解除しないでください。アプリケーションには、これらの制限に適合するメモリ予算が必要であり、あるいは制限の容量変更には承認が必要です。

この特定のワークロードが確実に動作することを保証する、検証済みの最小VPSサイズはありません。実用的なスループットを得るために継続的なスワッピングが必要な場合、スケジュールされたジョブが依然として強制終了を引き起こす場合、またはキャッシュが小さいためにレイテンシが許容できない場合は、構成を容量の代替として扱うのをやめてください。RAMを増設するか、アプリケーションの同時実行数を減らすか、データベースを別のサービスに移行してください。