Linuxサーバの安定稼働において、メモリ管理は最も重要な要素の一つです。特にWordPressのような動的なコンテンツを扱うWebサーバでは、Apache、PHP-FPM、データベース（MariaDB/MySQL）といった主要コンポーネントが常にメモリを消費し、その配分と最適化がパフォーマンスと安定性を大きく左右します。本記事では、メモリの物理的な基盤であるDIMMの基礎から、Linuxカーネルのメモリ管理の深層、そしてWordPressサーバにおける具体的なチューニング手法まで、その真髄を徹底的に解説します。16GBサーバで「カツカツ」と感じる現状を打破し、32GBへのスムーズな移行までを見据えたロードマップを提供します。
Linuxメモリ管理の真髄は、単にメモリ量を増やすことだけではなく、その仕組みを深く理解し、アプリケーションとカーネルが協調して効率的に動作するよう、適切な設定と継続的な監視を行うことにあります。DIMMの物理的な特性から、Linuxカーネルの仮想・物理メモリ管理、そしてWordPressサーバの各コンポーネントに至るまで、多角的な視点からメモリを最適化する重要性をご理解いただけたでしょうか。本記事で紹介したチューニング手法と監視のポイントを実践し、あなたのWordPressサーバが常に最高のパフォーマンスと安定性を提供できるよう願っています。メモリはサーバの心臓部であり、その健全な運用がビジネスの成功に直結するのです。
DIMM基礎解説：世代・種類からチャネル構成の要点
SIMM（Single Inline Memory Module）からDIMM（Dual Inline Memory Module）への移行は、現代コンピューティングにおけるメモリ技術の大きな転換点でした。SIMMはデータ幅の狭さや容量拡張の限界、高クロック化の難しさを抱えていましたが、DIMMは表裏独立した信号線を持つことで、64bit幅の標準化、飛躍的な高速化、そしてギガバイト単位の大容量化を可能にしました。初期のDIMMがSDR SDRAMであったため、一時的にSIMMの方が高速に感じられた時期もありましたが、帯域と容量の面でDIMMの優位性は圧倒的です。
DIMMは、SDR SDRAMからDDR（DDR1）、DDR2、DDR3、DDR4、そして最新のDDR5へと世代を重ねるごとに進化を遂げてきました。各世代はピン数の変更（184ピン、240ピン、288ピンなど）、動作電圧の低下（1.8V、1.5V、1.2V）、そして転送レートの向上（〜400MHzから〜6400MHz以上）を特徴としています。特にDDR（Double Data Rate）という名称が示す通り、1クロックサイクルで2回のデータ転送を行うことで、実クロック周波数の2倍の転送レートを実現しています。
サーバ用途では、データの信頼性を確保するためにECC（Error-Correcting Code）機能を持つDIMMが必須とされます。さらに、多くのメモリモジュールを搭載するサーバでは、信号の安定化を図るRegistered DIMM（RDIMM）や、電気的負荷を軽減して大容量化を可能にするLoad-Reduced DIMM（LRDIMM）が用いられます。これらの種類はそれぞれ異なる用途と特性を持ち、サーバの規模や要求される性能に応じて適切に選択されます。
メモリの性能を最大限に引き出すためには、マザーボードやCPUが対応するマルチチャネル構成を理解し、適切にDIMMを配置することが極めて重要です。デュアルチャネルでは2本のメモリチャネルを並列で動作させ、理論上のメモリ帯域を2倍に拡張します。さらにハイエンドのサーバCPUでは、クアッドチャネル、ヘキサチャネル、オクタチャネルといった構成も存在し、同容量・同クロックのDIMMをペアで揃えて指定されたスロットに挿すことで最大の効果を発揮します。
しかし、DIMMの物理的な特性は時に予期せぬトラブルを引き起こすこともあります。例えば、BIOS画面すら表示されないような起動不良は、DIMMの接触不良が原因であることが少なくありません。これは、長年の使用による接点の酸化、ホコリの付着、あるいは微振動によるモジュールの浮きなどが原因で発生します。差し直しによって一時的に症状が改善するのは、これらの接触不良が解消されるためです。
このようなトラブルを未然に防ぎ、安定した動作を維持するためには、定期的な清掃と適切な環境管理が欠かせません。作業時には静電気対策を徹底し、無水エタノールでの接点清掃やエアダスターでのスロット内のホコリ除去が推奨されます。また、サーバ内の温度管理を適切に行い、DIMMが熱膨張・収縮によって緩むのを防ぐことも、長期的な安定稼働には非常に重要となります。
Linuxメモリの現状把握：freeと/proc/meminfoで読み解く実態
Linuxサーバのメモリ状況を把握する最も基本的なコマンドはfreeですが、その出力解釈には注意が必要です。特にfree -hで表示される「used」メモリは、アプリケーションが実際に使用しているメモリだけでなく、ファイルI/Oの高速化のためにカーネルがキャッシュしているページキャッシュも含まれるため、見かけ上、空きメモリが少ないように見えて誤解を招くことがあります。現代のLinuxでは、実質的な空きメモリの目安としては「MemAvailable」の値を重視すべきです。
より詳細なメモリ情報を得るには/proc/meminfoファイルを参照します。このファイルには、システム全体のメモリ総量（MemTotal）、物理的な空きメモリ（MemFree）、そして最も実用的な「アプリケーションが今すぐ使えるメモリの目安」であるMemAvailableなど、多岐にわたる情報がキロバイト単位で記載されています。その他にも、Buffers、Cached、SReclaimableといった項目も、カーネルがどのようにメモリを管理しているかを理解する上で重要です。
Linuxカーネルの設計思想として「空きメモリはゼロに近いのが健全」という考え方があります。これは、アイドル状態のメモリを遊ばせておくよりも、積極的にページキャッシュとして活用し、ファイルI/Oの高速化に役立てることで、システム全体のパフォーマンス向上に繋がるというものです。そのため、MemFreeの値が少なくてもMemAvailableが十分にあれば、通常は問題ない状態と判断できます。
ページキャッシュは、ディスクから読み込んだファイルの内容をメモリ上に一時的に保持することで、同じファイルへの再アクセスを高速化します。また、Slabキャッシュは、カーネル内部で使用するデータ構造などを効率的に管理するためのキャッシュ領域であり、SReclaimableはそのうち解放可能な領域を示します。これらのキャッシュは必要に応じて解放されるため、「ほぼ空き」に近い扱いで見ることができます。
物理メモリが不足した場合、Linuxカーネルは一部のデータをディスク上のスワップ領域に退避させます。スワップの発生状況はvmstat 1コマンドのsi（swap in）とso（swap out）の列や、/proc/vmstatのpswpin/pswpoutで監視できます。これらの値が継続的に高い場合は、スワップスラッシングが発生しており、パフォーマンス低下の深刻な原因となる可能性があります。
メモリの現状を多角的に把握するためには、topやhtopでプロセスごとのメモリ使用量を確認したり、vmstatでシステム全体のメモリ・IO・CPUの流れを時系列で追ったりすることが有効です。さらに、sar -rでメモリの推移を記録したり、ps -o pid,cmd,%mem,rss --sort=-rssでRSSが大きいプロセスを特定したり、slabtopでカーネルのSlabキャッシュの内訳を確認したりと、状況に応じた多様なコマンドを使いこなすことが、メモリ管理の真髄に迫る第一歩となります。
仮想・物理の深層：RSS, PSS, ページキャッシュの役割と監視
Linuxシステムにおいて、各プロセスは「仮想アドレス空間」を持っており、直接物理メモリを操作することはありません。VSS（Virtual Set Size）は、プロセスが確保している仮想アドレス空間の総量を示しますが、これはあくまで概念的なサイズであり、実際に物理メモリを消費している量とは大きく異なります。多くの仮想メモリを確保していても、実際に使用している部分が少なければ物理メモリの消費はわずかです。
プロセスが実際に物理メモリにロードして使用している領域を「常駐集合サイズ（Resident Set Size、RSS）」と呼びます。topコマンドなどで表示されるメモリ使用量の多くはこのRSSを指しますが、RSSには共有ライブラリや共有メモリがプロセスごとに重複して計上されるという特性があります。そのため、複数のプロセスが同じ共有ライブラリを使用している場合、それらのRSSを単純に合計してもシステム全体の物理メモリ使用量の実態とは乖離が生じます。
このRSSの重複計上問題を解消し、より正確なメモリ使用量を把握するために考案されたのが「比例按分サイズ（Proportional Set Size、PSS）」です。PSSは、共有されているメモリページを、そのページを共有しているプロセスの数で按分して計上します。例えば、10MBの共有ページを5つのプロセスが使っていれば、各プロセスには2MBが計上されるため、システム全体のメモリ使用量をより正確に把握する上で非常に有用です。smemコマンドなどを用いることで、このPSSベースでのメモリ使用量を確認できます。
Linuxメモリは、ユーザープロセスが使用する匿名メモリ（ヒープ、スタック、データセグメントなど）と、カーネルが使用するメモリ、そして「ページキャッシュ」という大きく3つの主要な領域に分けられます。ページキャッシュは、ディスクI/Oを高速化するためにファイルの内容を一時的にメモリに保持する仕組みであり、システム全体のパフォーマンス向上に大きく貢献します。一方で匿名メモリは、ファイルとしてバックアップされていない、プロセス固有のデータ領域です。
物理メモリが枯渇し始めた場合、Linuxカーネルはまずページキャッシュなど、比較的安全に解放できるメモリを回収しようとします。それでもメモリが不足し続けると、スワップアウト（物理メモリ上のデータをディスクに退避）が発生し、最終的にはOOM Killer（Out Of Memory Killer）が発動し、システムを安定させるために最もメモリを消費しているプロセスを強制終了させることがあります。これはサーバ管理者にとって最も避けたい事態の一つです。
プロセスのメモリ使用状況をさらに詳細に分析するには、pmap -xコマンドが非常に有効です。このコマンドは、指定したプロセスの仮想アドレス空間のマップと、それぞれの領域が実際に使用している物理メモリ量（RSS）を表示します。これにより、どのライブラリやデータ領域が多くのメモリを消費しているのか、あるいは共有されているのかといった情報を把握でき、メモリリークや非効率なメモリ利用の原因特定に役立てることができます。
サーバ安定化の鍵：メモリ不足トラブルの診断と初期対応
サーバのメモリ不足トラブルは、システム全体の安定性を著しく損なう深刻な問題であり、その兆候を早期に捉えることが安定稼働の鍵となります。主な症状としては、アプリケーションの応答速度が極端に低下する、特定のサービスが頻繁にクラッシュする、あるいはSSH接続すら不安定になるなどが挙げられます。これらの症状が見られた場合、dmesg | grep -i oomコマンドでOOM Killerのログが記録されていないか確認し、メモリ不足が原因であるかを診断する第一歩となります。
メモリ不足が深刻化すると「スワップスラッシング」という現象が発生します。これは、物理メモリとスワップ領域の間でデータが頻繁に交換されることで、ディスクI/Oがボトルネックとなり、CPU使用率は低いにもかかわらずシステム全体のパフォーマンスが著しく低下する状態を指します。vmstat 1コマンドのsi（swap in）とso（swap out）の値が継続的に高い状態が続いている場合は、スワップスラッシングの発生を強く疑うべきです。
特定のプロセスが大量のメモリを消費している場合、それはアプリケーション側のメモリリークや非効率な設計が原因である可能性が高いです。topコマンドでMキーを押してRSS順にソートしたり、ps -eo pid,cmd,%mem,rss --sort=-rssコマンドを実行したりすることで、メモリを最も消費しているプロセスを特定できます。この情報に基づいて、アプリケーションログの確認や、コードレベルでのメモリ使用効率の見直しが必要となる場合があります。
Linuxのメモリ管理において、ページキャッシュの肥大化は必ずしも悪ではありませんが、状況によってはシステムの応答性を低下させる要因となることもあります。例えば、大容量のファイルを頻繁に読み書きするような特定のワークロードで、MemAvailableが極端に少なくなる場合に限り、デバッグ目的で一時的にページキャッシュを解放するsync; echo 3 | sudo tee /proc/sys/vm/drop_cachesコマンドの使用が検討されます。しかし、これは常用すべきではありません。
メモリ不足が緊急事態に陥った際の初期対応としては、まず不要なサービスやメモリ消費の大きいプロセスを一時的に停止または再起動し、システムに一時的な余裕を持たせることを試みます。また、vm.swappinessカーネルパラメータを一時的に低い値に設定することで、カーネルがスワップアウトをより控えめに行うように促し、スワップスラッシングの悪化を軽減できる場合があります。
より根本的な解決策としては、cgroups v2を活用し、Apache、PHP-FPM、MariaDBといった主要なサービスに対してメモリ使用量の上限（MemoryMax）を設定することが有効です。これにより、たとえ特定のサービスが暴走してメモリを大量消費しようとしても、設定された上限値を超えてメモリを使い果たすことを防ぎ、OOM Killerによるシステム全体の停止リスクを大幅に低減することができます。
カーネルパラメータ調整：swappinessとTHPでパフォーマンス最適化
Linuxカーネルのメモリ管理における重要な調整ポイントの一つが、vm.swappinessカーネルパラメータです。このパラメータは、カーネルがスワップ領域をどれだけ積極的に利用するかを制御するもので、0から100までの値を設定できます。デフォルト値は60であることが多く、これは比較的に積極的にスワップを利用する設定です。ウェブサーバやデータベースサーバのように、I/O性能が重視されるシステムでは、物理メモリの空きがまだある段階でスワップが発生するとパフォーマンスが低下するため、vm.swappiness=10や20といった低い値に設定することが推奨されます。
vm.swappinessの変更は、sudo sysctl -w vm.swappiness=10コマンドで一時的に適用できますが、システム再起動後も設定を維持するためには、/etc/sysctl.d/ディレクトリ内に設定ファイル（例: 99-mem.conf）を作成し、vm.swappiness=10と記述する必要があります。これにより、カーネルは物理メモリが枯渇に近づくまでスワップアウトを極力行わないようになり、不必要なディスクI/Oを減らして応答性を向上させることができます。
もう一つの重要なカーネルパラメータとして、Transparent Huge Pages（THP）があります。THPは、通常4KBのメモリページを、より大きな2MBの「Huge Page」として透過的に管理することで、メモリ管理のオーバーヘッドを削減し、特定のワークロードでパフォーマンスを向上させることを目的としています。しかし、データベースなど、メモリの断片化が頻繁に発生し、予測可能なメモリ動作が求められるアプリケーションでは、THPがレイテンシの増加や安定性の低下を引き起こす場合があります。
THPの動作モードは、/sys/kernel/mm/transparent_hugepage/enabledファイルを通じて設定できます。always（常にTHPを使用）、madvise（アプリケーションが明示的に要求した場合のみ使用）、never（THPを使用しない）の3つのモードがあります。多くのデータベースサーバでは、THPをmadviseまたはneverに設定することで、より安定したパフォーマンスが得られることが知られており、echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabledで一時的に変更可能です。永続化にはGRUB設定などの変更が必要です。
vm.overcommit_memoryも、メモリ管理の挙動に大きな影響を与えるパラメータです。これは、アプリケーションが物理メモリを超過してメモリを要求することをカーネルがどの程度許可するかを制御します。0（ヒューリスティックな判断）、1（常に許可）、2（スワップと物理メモリの一定割合を上限とする厳格な管理）の3つのモードがあり、1に設定するとOOM Killerのリスクが高まりますが、2とvm.overcommit_ratioを組み合わせることで、より予測可能なメモリ管理を実現し、特にデータベースサーバなどで安全性を高めることができます。
その他にも、vm.dirty_ratioやvm.dirty_background_ratioといったパラメータは、ファイルシステムのダーティページ（メモリ上で変更されたがまだディスクに書き込まれていないデータ）の書き戻し動作を制御し、大量の書き込みが発生するワークロードにおけるI/Oレイテンシの尖りを調整するのに役立ちます。また、zramを導入することで、物理メモリの一部を圧縮スワップとして利用し、スワップアウト時のディスクI/Oを軽減しつつ、実質的なメモリ容量を増やすといった高度な最適化も可能です。
WordPress稼働基盤：Apache, PHP-FPM, DBのメモリ配分戦略
WordPressを安定稼働させるためには、その基盤となるApache、PHP-FPM、そしてMariaDB/MySQLの各コンポーネントにおけるメモリ配分戦略が極めて重要です。WordPressは動的なコンテンツ生成が主であるため、リクエストごとにPHPプロセスが起動し、データベースへの頻繁なアクセスが発生します。これらのコンポーネントがメモリをどのように消費し、全体としていかに効率的に利用させるかが、サーバの応答性と安定性を決定します。
データベース（MariaDB/MySQL）は、WordPressサーバにおいて最も多くのメモリを消費するコンポーネントの一つです。特にinnodb_buffer_pool_sizeは、InnoDBストレージエンジンがデータとインデックスをキャッシュするために使用する領域であり、そのサイズがデータベースのパフォーマンスに直接影響します。一般的には、サーバの総物理メモリの50%から70%程度をこのバッファプールに割り当てることが推奨されますが、小規模なサーバでは他のコンポーネントとのバランスを考慮し、より控えめな設定から始めるべきです。max_connectionsなどの設定も、接続数に応じてメモリを消費するため注意が必要です。
PHP-FPM（FastCGI Process Manager）は、PHPスクリプトの実行を管理するプロセスプールで、各ワーカープロセスがPHPスクリプトを処理するためにメモリを消費します。pm.max_childrenは同時に実行できるPHPワーカーの最大数を、pm.start_serversなどはアイドル状態のワーカー数を制御します。重要なのは、1つのPHPワーカープロセスが消費するメモリ量（memory_limitで設定）と、max_childrenのバランスです。pm.max_requestsを設定することで、一定回数のリクエスト処理後にワーカープロセスを再起動させ、メモリリークや断片化によるメモリ肥大化を防ぐことができます。
WebサーバであるApacheは、Event MPM（Multi-Processing Module）を採用することで、より少ないリソースで高い同時接続数を処理できます。MaxRequestWorkersはApacheが同時に処理できるリクエストの総数を、ThreadsPerChildは各子プロセスが持つスレッド数を制御します。これらの設定は、PHP-FPMのmax_childrenやMariaDBのmax_connectionsとのバランスを考慮し、過剰なリクエストがFPMやDBに集中してボトルネックとならないよう、適切に調整する必要があります。
WordPress環境のメモリ効率をさらに高めるためには、OPcacheとRedisの活用が不可欠です。OPcacheは、PHPスクリプトのコンパイル済みコードをメモリにキャッシュすることで、リクエストごとのスクリプト解析・コンパイルのオーバーヘッドを削減し、PHPプロセスの起動時間を短縮し、結果的にPHPワーカーのメモリ消費を抑制します。また、Redisをオブジェクトキャッシュとして導入することで、データベースへのクエリ負荷を軽減し、セッション管理をRedisにオフロードすることでPHPのI/Oとメモリ断片化を減らすことができます。
その他にも、WordPress自体の設定や運用面での工夫もメモリ消費の抑制に寄与します。例えば、不要なApacheモジュールの無効化、wp-cronをサーバのcronで外部化してアクセス時実行を避ける、軽量なテーマやプラグインを選択する、そしてWP Super CacheやLiteSpeed Cacheといったキャッシュプラグインを適切に活用することで、動的なコンテンツ生成の頻度を減らし、サーバ全体のメモリ使用量を最適化することが可能です。
16GBサーバ限界突破：WordPress安定稼働チューニング実践
16GBの物理メモリを搭載したサーバでWordPressが「カツカツ」と感じる場合、それはリソースの配分が最適化されていないか、特定のコンポーネントが過剰にメモリを消費している可能性が高いです。現状を打破し安定稼働を実現するには、まずMemAvailableの残量、Swapの使用状況、PHP-FPMのmax active processesがmax_childrenに貼り付いていないか、そしてMariaDBのバッファプール命中率といった指標を正確に把握することから始めます。
MariaDBのinnodb_buffer_pool_sizeは、16GBサーバにおいては総メモリの約1/3から1/2（例えば6〜8GB）を目安に設定することが現実的です。この値を決定する際には、SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%'で確認できる命中率（Innodb_buffer_pool_read_requestsに対するInnodb_buffer_pool_readsの割合）が99%以上を維持しているかを確認しながら、段階的に調整します。命中率が低い場合は増量を検討し、逆にInnodb_buffer_pool_pages_freeが常に潤沢であれば減量も視野に入れます。また、sort_buffer_sizeやjoin_buffer_sizeのようなper-connectionバッファは、max_connectionsとの積でメモリを大量消費するため、必要最小限に抑えるべきです。
PHP-FPMのワーカー数（pm.max_children）は、闇雲に増やすのではなく、ps -o rss,cmd -C php-fpm --no-headers | awk '{s+=$1;n++}END{printf "avg_rss_per_fpm: %.1f MBn", s/n/1024}'で計測した1プロセスあたりの平均RSSから逆算することが鉄則です。例えば、PHPに割り当てたいメモリが3.5GBで平均RSSが220MBであれば、max_childrenは約15が適切な目安となります。php_admin_value[memory_limit]はWordPressの必要に応じて256MB程度に抑え、pm.max_requests=500を設定して定期的にワーカーを再起動させ、メモリリークや断片化による肥大化を防ぎます。
ApacheのMaxRequestWorkersは、PHP-FPMのmax_childrenの実力値と連携して調整します。過剰に高い値に設定すると、FPMやデータベースに不必要な負荷を集中させ、ボトルネックを引き起こす可能性があります。FPMのmax_childrenを少し上回る程度に抑え、KeepAliveTimeoutを短く設定することで、リソースの早期解放を促し、Apacheが持つアイドルスレッドの効率的な再利用を促進します。mod_phpが有効になっている場合は、FPMとの二重起動を避けるために無効化するべきです。
WordPressサイトの応答性を高め、メモリ消費を抑えるためには、Redis Object Cacheの導入と、それが実際に機能しているかの確認が不可欠です。単にプラグインをインストールするだけでなく、wp-config.phpの設定やRedisサーバの状態を確認し、キャッシュが確実に利用されていることを確認します。また、session.save_handler = redisを設定することで、セッションデータをファイルシステムではなくRedisに保存し、PHPプロセスのI/O負荷とメモリ使用量をさらに削減できます。
最終的な安定化には、カーネルパラメータの微調整とcgroupによるリソース制限が有効です。vm.swappiness=10でスワップの使用を抑制し、データベースの安定性を考慮してTHPをmadviseモードに設定します。さらに、systemdのcgroup機能を用いて、Apache、PHP-FPM、MariaDBの各サービスに対してMemoryMaxとMemoryHighを設定し、万が一の暴走時にも他のサービスやシステム全体に影響が及ばないよう、物理的な上限を設けることで、16GBサーバでも堅牢なWordPress環境を構築することが可能になります。
メモリ増設の判断基準：32GBへの移行と最適化ロードマップ
現在の16GBサーバでWordPressが慢性的に「カツカツ」の状態が続く場合、特に以下の客観的な指標が危険水域を示しているならば、32GBへのメモリ増設は非常に合理的な判断となります。具体的には、MemAvailableが平常時でも2GB未満に張り付いている、Swapの使用量が継続的に増加している、PHP-FPMのmax active processesがmax_childrenに頻繁に到達している、あるいはMariaDBのinnodb_buffer_pool命中率が99%を下回っているといった状況です。これらの兆候が複数見られる場合、メモリ増設はパフォーマンスと安定性向上のための最も効果的な投資となるでしょう。
32GBへのメモリ増設は、各コンポーネントにより潤沢なメモリを割り当て、サーバ全体の処理能力と耐障害性を飛躍的に向上させる機会を提供します。増設後のメモリ配分としては、OS基盤に約1.0GB、MariaDBのinnodb_buffer_pool_sizeに12GBから16GB（まずは12GBから開始し、実測に基づいて調整）、PHP-FPMに5GBから7GB（平均RSSからmax_childrenを再計算）、ApacheやRedis、その他の常駐プロセスに0.8GBから1.2GB、そしてページキャッシュと安全ヘッドルームとして合計7GBから10GBを確保するイメージが現実的です。
MariaDBのチューニングでは、32GB環境であればinnodb_buffer_pool_sizeを12GBでスタートし、データベースのヒット率やディスクI/Oの状況を監視しながら16GBまで引き上げる余地が生まれます。innodb_log_file_sizeも2GB程度に増強することで、書き込み性能の向上に寄与します。max_connectionsも120程度まで引き上げることが可能となり、より多くの同時接続を安定して処理できるようになります。
PHP-FPMの設定では、平均RSSが220MBと仮定した場合、PHPに6GBを割り当てることでpm.max_childrenを約28まで増やせるようになります。これにより、WordPressサイトがより多くの同時リクエストを並列で処理できるようになり、ユーザー体験の向上に直結します。OPcacheのメモリ割り当てもopcache.memory_consumption=256に増強し、pm.max_requests=600でワーカーの健全性を維持します。
ApacheのEvent MPM設定も、PHP-FPMの拡張に合わせて調整します。MaxRequestWorkersを例えば220程度まで引き上げることで、Apacheがより多くの同時接続に対応し、FPMへのリリクエストをスムーズにハンドリングできるようになります。KeepAliveTimeoutやMaxKeepAliveRequestsも適切な値に設定し、リソースを効率的に利用しつつ、クライアントとの接続を最適化します。
メモリ増設後も、カーネルパラメータのvm.swappiness=10やTHPのmadviseモードは継続して適用し、システムの安定性を維持します。さらに、cgroupv2による各サービスへのMemoryMax設定も、32GB環境に合わせて上限値を見直すことで、万が一のアプリケーション暴走時にもシステム全体が落ちるのを防ぐ安全策として機能し続けます。増設はゴールではなく、さらなる最適化のスタートラインであり、継続的な監視と調整が安定稼働へのロードマップとなります。
