4GB VPSでMariaDBのswap使用量が増加したときの調査と設定見直し

物理メモリ約4GBのVPSでWordPressを運用していたところ、サーバー負荷が高くなり、MariaDBを再起動する状況が発生しました。サーバーの状態を確認すると、約2GBのswap領域のうち、およそ1.1GBが使用されていました。

swapが使用されているだけで、すぐに障害や設定ミスと判断できるわけではありません。一方で、swapへの読み書きが継続している場合や、WordPressの応答が不安定になっている場合は、物理メモリに対してMariaDBの設定が大きすぎないか確認する必要があります。

今回の環境では、innodb_buffer_pool_sizeに3GBを割り当てていました。しかし、4GBの物理メモリはMariaDBだけが使用するものではありません。OS、Webサーバー、PHP、KUSANAGI、ファイルキャッシュなどにもメモリが必要です。そこで、現在のメモリ状況とswapの動きを確認したうえで、buffer poolを3GBから2GBへ見直しました。本記事では、確認した項目、設定変更の考え方、変更後に監視すべきポイントを実際の流れに沿って解説します。

今回使用していたサーバー環境

今回確認したのは、AlmaLinux 9とKUSANAGI 9を利用したWordPress環境です。物理メモリは約4GBで、確認時点では約2GBのswap領域が用意されていました。データベースにはMariaDBを使用しており、WordPress、PHP、Webサーバー、OSと同じVPS上で稼働しています。

サーバーの主な構成

変更前のMariaDB設定

変更前は、InnoDBのデータやインデックスをキャッシュするinnodb_buffer_pool_sizeを3GBに設定していました。約4GBの物理メモリに対して3GBを割り当てるため、単純計算でもMariaDBのbuffer poolだけでメモリ全体の約8割を占める設定です。

[mysqld]
innodb_buffer_pool_size=3G

ただし、MariaDBが使用するメモリはbuffer poolだけではありません。接続ごとのバッファ、ソート処理、一時テーブル、各種キャッシュなどにもメモリが必要です。加えて、同じVPS上ではPHPやWebサーバーも動作します。そのため、4GB環境で3GBを割り当てる設定は、アクセス数やプラグインの処理内容によっては余裕が少なくなる可能性があります。

発生していた症状

今回の確認を始めたきっかけは、WordPressの応答が不安定になり、サーバー負荷が高くなったことです。管理画面やWebページの表示が通常より遅くなり、MariaDBを再起動して状態を立て直す対応を行いました。

データベースの再起動で一時的に状態が改善しても、原因が設定やメモリ不足にある場合は、同じ症状が再発する可能性があります。そこで、再起動だけで対応を終わらせず、物理メモリとswapの使用状況を確認しました。

swapが約1.1GB使用されていた

当時の確認結果では、物理メモリの合計が約3919MB、swapの合計が約2047MBで、そのうち約1107MBが使用されていました。

Mem:   total 3919MB
Swap:  total 2047MB
       used 1107MB

ここで注意したいのは、swapが1.1GB使われているという数値だけでは、現在も深刻なメモリ不足が続いているか判断できない点です。Linuxでは、過去に使用頻度が低いと判断されたメモリ領域がswapへ移され、その後もswap上に残る場合があります。そのため、現在の負荷が下がっていても、swapの使用量だけが多く見えることがあります。

一方で、WordPressの応答遅延やMariaDBの不安定化が同時に発生している場合は、swapの読み書きによって処理が遅くなっていないか確認が必要です。つまり、swapの使用量に加えて、現在もswapへの退避や読み戻しが続いているかを調べることが重要です。

最初に確認した項目

MariaDBの設定を変更する前に、まず現在の状態を確認します。設定値だけを見て変更すると、別の原因を見落としたり、必要なキャッシュまで減らしたりする可能性があります。今回は、free、vmstat、MariaDBのSHOW FULL PROCESSLISTを使って状況を整理しました。

freeコマンドでメモリ使用量を確認する

free -m

free -mでは、メモリ容量をMB単位で確認できます。特に確認したいのは、used、free、buff/cache、available、swapのusedです。

Linuxでは、空いているメモリをファイルキャッシュとして積極的に利用します。そのため、freeの値が少ないだけでメモリ不足と判断するのは適切ではありません。アプリケーションが追加で利用できるメモリの目安として、availableも確認します。

vmstatでswapの入出力を確認する

vmstat 1 5

このコマンドでは、1秒間隔で5回、CPU、メモリ、swap、I/Oの状態を確認できます。主に見る項目は、swpd、si、so、wa、idです。

• swpd：使用中のswap容量
• si：swapから物理メモリへ読み戻した量
• so：物理メモリからswapへ書き出した量
• wa：CPUがI/O完了を待っている時間の割合
• id：CPUが何も処理していない時間の割合

swpdが多くても、siとsoが継続して0に近ければ、過去に退避されたデータがswapへ残っているだけの可能性があります。一方、アクセス中にsiやsoが繰り返し増え、waも高くなる場合は、swapの読み書きが応答速度へ影響している可能性があります。

MariaDBで重い処理が動いていないか確認する

SHOW FULL PROCESSLIST;

MariaDBへ接続し、長時間実行されているSQL、ロック待ち、同じ処理の大量実行、Sleep状態の接続が増えていないかを確認します。WordPressでは、プラグインによる集計処理、検索処理、バックアップ、アクセス解析、定期実行などが負荷の原因になることがあります。

メモリ設定だけでなく、処理内容にも問題がある場合は、buffer poolを縮小するだけでは解決しません。まず負荷の高いSQLや接続数の増加がないかを確認し、そのうえでメモリ配分を判断することが大切です。

swap使用量が多くなった原因を考える

今回の環境で特に気になったのは、物理メモリ約4GBに対して、innodb_buffer_pool_sizeが3GBだった点です。buffer poolは、InnoDBのデータやインデックスをメモリ上へ保持し、ディスクアクセスを減らすために使用されます。十分な容量を確保できれば、データベースの処理速度を改善できる可能性があります。

しかし、buffer poolは大きければ大きいほどよいわけではありません。専用のデータベースサーバーであれば、物理メモリの多くをMariaDBへ割り当てる設計もあります。一方、今回のようにWordPress、PHP、Webサーバー、MariaDBを同じ4GB VPSで動かす場合は、ほかのプロセスが使うメモリも残す必要があります。

buffer pool以外にもメモリが必要になる

MariaDBでは、buffer pool以外にも接続や処理内容に応じてメモリを使用します。たとえば、ソート処理用のバッファ、結合処理用のバッファ、一時テーブル、接続スレッドなどです。これらは同時接続数や実行されるSQLによって増減します。

さらに、PHPの同時実行数が増えれば、PHPプロセスが使用するメモリも増えます。WordPressの管理画面、画像処理、バックアップ、インポート、ページ生成などでは、1リクエストあたりの使用量が大きくなる場合があります。加えて、NginxまたはApache、KUSANAGIの関連プロセス、OSのファイルキャッシュにもメモリが必要です。

今回の状況では、swap使用量の数値だけで原因を断定することはできません。ただし、4GB環境に対して3GBのbuffer poolは余裕が少ないと判断し、OSやPHPなどが利用できる領域を増やす方向で設定を見直しました。

実施した対応

今回の対応では、swap領域を保険として確保したうえで、innodb_buffer_pool_sizeを3GBから2GBへ縮小しました。重要なのは、swapを増やすこと自体を根本解決にしないことです。

swap領域を確認して必要な容量を確保する

swapは、物理メモリが一時的に不足した際に、プロセスが強制終了されるリスクを下げるための保険になります。swapが設定されていない場合や容量が極端に少ない場合は、サーバーの構成を確認したうえで、2GB程度を確保する方法があります。

ただし、swapはディスク上の領域であり、物理メモリよりもアクセス速度が遅くなります。swapを追加して強制終了を回避できても、継続的に読み書きが発生すれば、WordPressやMariaDBの応答が遅くなる可能性があります。そのため、swapの確保と同時に、物理メモリ内へ収まりやすい設定へ見直す必要があります。

innodb_buffer_pool_sizeを3GBから2GBへ変更する

[mysqld]
innodb_buffer_pool_size=2G

2GBへ変更した理由は、MariaDB以外のプロセスが使用できるメモリを確保するためです。buffer poolを1GB減らすことで、OS、PHP、Webサーバー、MariaDBの接続処理などが利用できる余地が増えます。その結果、メモリ不足によるプロセス終了や、swapへの頻繁な退避を抑えられる可能性があります。

ただし、2GBがすべての4GB VPSに適した値とは限りません。データベース容量、アクセス数、PHPの同時実行数、プラグイン、キャッシュ構成によって適正値は変わります。今回の変更は、WordPressを運用する小規模な4GB環境で、3GBでは余裕が少ないと判断した事例です。

MariaDBを再起動する

設定ファイルを変更したあと、MariaDBを再起動して設定を反映します。

sudo systemctl restart mariadb

再起動後は、サービスが正常に起動していることを確認します。

sudo systemctl status mariadb

サービスが起動していても、設定が意図した値になっているとは限りません。必要に応じてMariaDBへ接続し、現在の設定値を確認します。

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

設定値はバイト単位で表示される場合があります。変更後の値を記録し、再起動前後で比較できるようにしておくと、後から状況を確認しやすくなります。

設定変更後に確認したこと

MariaDBが正常に再起動したことを確認したら、設定変更だけで対応を終わらせず、サーバー全体の状態を継続して確認します。今回の目的は、swapの表示値をゼロにすることではなく、WordPressとMariaDBが安定して稼働できるメモリ配分にすることです。

MariaDBが正常に起動しているか

まず、systemctl status mariadbでサービスの状態を確認します。起動に失敗している場合は、設定ファイルの記述ミス、単位の指定、同じ項目の重複などを確認します。また、MariaDBのログにエラーが記録されていないかも確認します。

メモリとswapの使用量

次に、free -mを実行し、availableが極端に少なくなっていないか、swapの使用量が急増していないかを確認します。MariaDBの再起動直後だけでなく、通常アクセス時、管理画面の操作時、バックアップ実行時など、負荷が異なるタイミングで確認することが重要です。

継続的なswap入出力が発生していないか

vmstat 1 5を使い、siとsoが継続して増えていないかを確認します。swapの使用済み容量が残っていても、入出力が落ち着いており、WordPressの応答にも問題がなければ、直ちにswapを解放する必要はありません。

WordPressの表示や管理画面に問題がないか

最後に、公開ページ、管理画面、投稿編集、画像アップロード、プラグインの処理などを確認します。データベース設定の変更後は、単にサービスが起動しているだけでなく、実際の業務操作に問題がないことを確かめる必要があります。

なお、今回の確認では、設定変更による改善率や処理時間の変化を厳密に測定していません。そのため、「何％高速化した」といった断定は避け、確認できた範囲の数値と動作状況を記録する形にしました。

swapの使用量だけで判断しない

サーバー監視では、swapの使用量が増えていると不安になります。しかし、swapが使われていることと、現在サーバーがメモリ不足で苦しんでいることは、必ずしも同じではありません。

過去に退避されたメモリが残る場合がある

Linuxでは、長時間使用されていないメモリ領域がswapへ退避されることがあります。その後、物理メモリに余裕ができても、すぐにすべてのデータが物理メモリへ戻るとは限りません。そのため、現在の負荷が低くても、swapの使用済み容量が残る場合があります。

この状態でswap使用量だけを見て、無理にswapを解放したり、何度もサーバーを再起動したりすると、かえって運用へ影響を与える可能性があります。重要なのは、現在の処理でswapへの読み書きが続いているかどうかです。

重要なのはsiとsoの継続発生

vmstatのsiとsoが継続的に増えている場合、物理メモリとswapの間でデータ移動が繰り返されている可能性があります。さらに、waが高く、WordPressの応答も遅い場合は、ディスクI/O待ちが影響していることも考えられます。

つまり、「swapが1GB使われているから異常」と単純に判断するのではなく、現在の入出力、メモリのavailable、ディスク待ち、MariaDBの処理、WordPressの応答を組み合わせて判断することが重要です。

今回の対応で分かったこと

今回の対応を通じて、MariaDBのbuffer poolは、大きく設定すれば必ず安定するわけではないことが分かりました。データベース専用サーバーと、WordPressやPHPを同居させるサーバーでは、適切なメモリ配分が異なります。

特に4GB程度の小規模VPSでは、MariaDBへ大部分を割り当てると、OSやPHPが利用するメモリが不足しやすくなります。アクセスが少ない時間帯には問題がなくても、バックアップ、管理画面の操作、プラグインの定期処理などが重なると、急にメモリ使用量が増える場合があります。

一方で、buffer poolを必要以上に小さくすると、データやインデックスを十分にキャッシュできず、ディスクアクセスが増える可能性があります。そのため、設定変更後は、メモリ使用量だけでなく、WordPressの応答やMariaDBの処理状況も継続して確認する必要があります。

また、再起動によって一時的に状態が改善しても、原因の特定にはなりません。再発を防ぐには、再起動前後のメモリ使用量、swapの動き、実行中のSQL、アクセス状況を記録し、どの処理が重なったときに問題が起きるかを確認する必要があります。

まとめ

4GBメモリのVPSでMariaDBのswap使用量が増加した場合は、swapの使用済み容量だけを見て判断せず、サーバー全体の状態を確認することが大切です。

今回の環境では、まずfree -mで物理メモリとswapの使用状況を確認し、vmstat 1 5でswapの入出力を確認しました。さらに、SHOW FULL PROCESSLISTを使い、長時間実行されているSQLやロック待ちがないかを調べました。

そのうえで、物理メモリ約4GBに対してinnodb_buffer_pool_sizeが3GBでは余裕が少ないと判断し、2GBへ縮小しました。これにより、OS、PHP、Webサーバー、MariaDBの追加処理が利用できるメモリ領域を確保する方針としました。

ただし、2GBという値がすべての環境に適しているわけではありません。データベース容量、アクセス数、同時接続数、PHPの構成、利用しているプラグインによって適正値は変わります。設定変更後は、MariaDBの起動状態、メモリのavailable、swapの入出力、WordPressの動作を継続して確認してください。

小規模なVPSでは、性能を最大限に引き出す設定よりも、負荷の変動に耐えられる余裕を残すことが安定運用につながります。設定値を一度決めて終わりにせず、実際の使用状況を記録しながら調整することが重要です。