メモリ不足のVPSでDebian 12を動作させ、MySQLをダウンさせる際にメモリ不足によるクラッシュを起こさない方法

メモリ容量の少ないVPSでもDebian 12とデータベースは動作しますが、安定性はMySQLのキャッシュ設定だけでなく、ワークロード全体に依存します。利用可能なメモリが不足すると、Linuxはメモリ不足（OOM）キラーを起動し、システム全体を保護するためにプロセスを強制終了することがあります。そのプロセスがデータベースである場合、症状はランダムなクラッシュのように見えることがあります。実際的な目標は、持続的なメモリ負荷を防ぎ、カーネルが実際にどのプロセスを強制終了したのかを確認することです。OOMイベントが絶対に発生しないことを保証するチューニング設定はありません。

Debian 12はMySQL、それともMariaDBを実行していますか？

設定を変更する前にサーバーを確認してください。Debian 12 (Bookworm) はデフォルトdefault-mysql-serverパッケージとして MariaDB を使用します。Oracle MySQL は別のインストールパスです。Debian のパッケージ情報には、MariaDB がそのメタパッケージのサーバー依存関係として記載されています。実行してください。

mariadb --version
mysql --version
dpkg-query -W -f='${Package} ${Version}\n' mariadb-server mysql-community-server 2>/dev/null

インストールされているサービスがMariaDBの場合のみ、以下のMariaDBの手順を使用してください。Oracle MySQLは多くの場合、互換性のあるオプション名を使用していますが、パッケージ構成、サービス名、利用可能な変数、デフォルト値は異なる場合があります。インストールされているMySQLの正確なリリースについては、マニュアルを参照してください。

主な参考資料: Debian Bookworm の default-mysql-server パッケージおよびMySQL 8.0 のメモリ使用マニュアル。

OOM（メモリ不足）によってデータベースがクラッシュしたかどうかは、どうすればわかりますか？

まず、カーネルのメモリ不足による強制終了と、データベースエラー、サービスの再起動、再起動、ディスクの問題を区別します。Debianでは、journalctlsystemdのジャーナルを読み込みます。現在のブートを検索し、MariaDBのサービスログを調べます。

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process'
sudo journalctl -u mariadb -b --no-pager -n 100
sudo systemctl status mariadb --no-pager

カーネルログに名前が記録されている場合mariadbd、またはmysqldOOMメッセージの後に記録されている場合は、メモリキルが発生した証拠となります。該当するエントリがない場合は、サービスのエラーログとプロバイダの再起動履歴または監視履歴を確認してください。ジャーナリングが永続的でない場合、再起動後にログが利用できなくなる可能性があり、マネージドVPSプロバイダはホストの診断情報の一部のみを公開している場合があります。

サーバーがアイドル状態にある時だけでなく、代表的なトラフィックが発生している時にもベースラインを取得してください。

free -h
swapon --show
vmstat 1
ps -eo pid,comm,rss,%mem --sort=-rss | head

ではvmstat、siとso列を監視して、継続的なスワップインとスワップアウトのアクティビティを確認してください。ゼロ以外のスワップ割り当て自体は問題を証明するものではありません。継続的なスワップと遅い応答時間が同時に発生している場合は、メモリ不足を示しています。Linux では、メモリを十分に解放できない場合の最終手段として OOM 処理が文書化されています。Linuxカーネルのメモリ管理の概念と Debian のjournalctl マニュアルを参照してください。

チューニング前に何を測定すべきですか？

合計RAM、現在のスワップ使用量とピーク時のスワップ使用量、最大の常駐プロセス、データベース接続数、およびWebアプリケーションの通常のピークを記録します。データベースは、Debian、Webサーバー、アプリケーションワーカー、監視エージェント、およびファイルシステムキャッシュとメモリを共有します。VPSでは、コンテナまたはcgroupのメモリ制限がホストの物理RAMよりも低くなる場合もあります。データベースキャッシュのサイズは、ホストの合計よりも大きいメモリ制限ではなく、サービスから見えるメモリ制限に合わせてください。

MariaDBの場合、現在のメモリ関連設定と接続ピークを調べます。

sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size'); SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"

InnoDB のバッファ プールは、テーブル ページとインデックス ページをキャッシュします。同時実行処理が増加すると、接続制限とクエリ バッファによってメモリ需要が増加する可能性があります。すべての接続バッファがmax_connections常に完全に割り当てられているかのように、各接続のバッファを乗算することは避けてください。ただし、接続上限が非常に高い場合は、バースト時にリスクとなることを考慮してください。MariaDB のメモリ ガイドでは、グローバル キャッシュ、接続ごとのバッファ、およびエンジン設定をまとめてサイズ設定することを推奨しており、特にアプリケーション接続プールについて言及しています。MariaDBのメモリ割り当てガイドと、接続数が多すぎる場合の処理​​ガイドを参照してください。

小規模なVPS上でMariaDBを適切なサイズにするにはどうすればよいでしょうか？

変更は一度に1つずつ行い、元の設定のコピーを保持し、メンテナンス期間中に再起動がユーザーに影響するかどうかをテストしてください。Debianに同梱されているMariaDBの設定ファイルは通常、以下のディレクトリに含まれています/etc/mysql/mariadb.conf.d/。編集する前に、インストール環境の有効なインクルードディレクトリを確認してください。小さなドロップインファイルは、ベンダーのメインファイルを置き換えるよりも簡単に削除できます。

sudo cp -a /etc/mysql/mariadb.conf.d /root/mariadb.conf.d.backup
sudoedit /etc/mysql/mariadb.conf.d/90-low-memory.cnf

約1 GiBのRAMを搭載した共有VPSの場合、以下はあくまでも慎重な初期設定例であり、普遍的に安全なプロファイルではありません。測定された最大メモリ使用量、データベースサイズ、ワークロード、およびオペレーティングシステムとアプリケーションに割り当てられているRAMに基づいて、値を増減してください。

[mariadb]
innodb_buffer_pool_size = 192M
max_connections = 30
tmp_table_size = 16M
max_heap_table_size = 16M

MariaDBは起動時にオプションファイルから設定を読み込みます。お使いのバージョンでサポートされているセクション名と有効な値を確認してください。このファイルの読み込みに失敗した場合は、ドロップインを削除してジャーナルを確認してください。データベースの再起動は既存の接続を中断するため、適切なスケジュールで実行してください。

sudo systemctl restart mariadb
sudo systemctl is-active mariadb
sudo journalctl -u mariadb -b --no-pager -n 80
sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections;"

安定性とサービス品質の両方の観点から結果を判断してください。バッファプールを小さくすると、キャッシュヒットが減り、ディスク読み取りが増える可能性があります。max_connectionsただし、小さくしすぎると、「接続数が多すぎます」エラーが発生する場合があります。Max_used_connections設定済みの制限値と比較し、アプリケーションプールのサイズを確認してから、再度制限値を変更してください。通常のピークトラフィック時にデータベースが停止したり、ディスクスワッピングが継続して発生し応答時間が悪化する場合は、より大きなRAMティアに移行するか、データベースとアプリケーションを分離してください。

スワップはメモリ不足によるクラッシュを防ぐことができるか？

スワップは、Linuxにおいて一部のメモリページを移動するための低速な場所を提供し、一時的な負荷のピークを吸収することができます。高速なRAMを追加したり、メモリリークを修正したり、容量不足のVPSを持続的なワークロードに適したものにしたりするものではありません。スワップが多すぎると、データベースとアプリケーションの両方が応答しなくなる可能性があります。スワップファイルを作成する前に、プロバイダがスワップファイルをサポートしているか、VPSに十分なディスク容量があるかを確認してください。

サポートされている場合、1 GiB のスワップファイルは次のように作成できます。プロバイダの指示と使用可能なディスク容量に合わせてサイズを調整し、各コマンドの結果を確認してください。

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

再起動後に有効にするには、/etc/fstab同等のエントリが既に存在しないことを確認した上で、このエントリを追加します。

/swapfile none swap sw 0 0

次に、ファイルを検証しsudo findmnt --verify --verbose、それがに存在することを確認しますswapon --show。fallocateファイルシステムでサポートされていない場合、またはプロバイダがスワップをブロックしている場合は、停止してプロバイダがサポートする手順を使用します。OOM キラーを無効にしたり、MySQL に極端な OOM 保護スコアを割り当てたりしないでください。これはメモリを作成しないため、小規模 VPS の残りの部分をより大きなリスクにさらす可能性があります。

変更が効果を発揮したことを、どうやって確認したのですか？

少なくとも通常の混雑期間を通してVPSを監視してください。有用な結果には、いくつかの兆候があります。

• 以前にインシデントを引き起こしたワークロード中に、新たなカーネルOOMキルエントリは発生しなかった。
• MariaDBはアクティブな状態を維持し、再起動回数が予期せず増加することはありません。
• vmstat 1通常のトラフィック状況下では、連続的なスワップインとスワップアウトは発生しない。
• アプリケーションは引き続き応答性を維持し、データベース接続のピークは接続エラーが発生することなく、新しい上限値を下回っています。
• バックアップは完了し、データベースクエリはアプリケーションが許容するレイテンシを満たし続けています。

「サービスが起動した」ことを唯一の成功判定基準にしないでください。MariaDBを稼働させ続ける設定でも、システムが常にスワッピング状態になるだけでは、根本的な容量問題は解決されません。同様に、1日だけ負荷が静かだったとしても、まだ実行されていない月次インポート、バックアップ、トラフィックの急増、バッチジョブの有効性は証明されません。

チューニングがもはや適切な解決策ではなくなるのはどのような場合か？

適切なキャッシュと同時実行数の調整後もメモリ負荷が解消されない場合、スワップアクティビティが継続する場合、クエリのレイテンシが許容範囲を超える場合、またはアプリケーションが新しい接続制限に繰り返し達する場合は、より大きなVPSを選択するか、ワークロードを分離してください。データベースのサイズも重要です。バッファプールが小さすぎるとメモリの急増は回避できますが、ディスクI/Oが新たなボトルネックになる可能性があります。アプリケーションとデータベースに急激かつ予測可能なピークがある場合は、まずアプリケーションが過剰な接続を開いているか、メモリを大量に消費するジョブを同時に実行しているかどうかを判断してください。

DebianのデフォルトのMariaDBではなくOracle MySQLを使用する場合は、これらの例を適用する前に、サービス名、オプションファイルのパス、およびメモリ変数を、そのサーバーのバージョン管理されたマニュアルと照らし合わせて確認してください。どちらのエンジンを使用する場合でも、テスト済みのバックアップを保持し、一度に1つの変数のみを変更してください。この確実な結果は、LinuxがOOM処理を決して実行しないことを保証するものではありません。これは、VPSが実際のピークワークロードに対して十分な余裕を持ち、MySQLまたはMariaDBがもはや繰り返し発生する問題ではないことを示す証拠です。

その他の主要な参考資料としては、MariaDB の起動トラブルシューティング ガイダンス（サーバーには他のエンジン、接続ごとのバッファ、およびオペレーティングシステム用のメモリも必要であると記載されている）と、MySQL 8.0 リファレンス マニュアルがあります。