WordPressのメモリ不足エラー

このエラーの意味と見分け方

• 致命的エラーに、Allowed memory size of 134217728 bytes exhausted (tried to allocate ... bytes)に似た文言が含まれます。
• サイト全体が利用できなくなることもあれば、ダッシュボード、特定のプラグイン画面、インポート、移行、一括操作だけに問題が限定されることもあります。
• プラグインやテーマのインストール・更新、大規模なデータ処理の開始、またはPHPメモリ上限の低いホスティングへの移行後に発生することがあります。
• ホームページは正常に読み込めても、インポート、ページビルダー画面、商品の同期、その他のメモリ負荷が高いタスクが失敗する場合があります。
• メモリを増やすことで通常のページは正常になったように見えても、元の操作は引き続き失敗することがあります。

可能性の高い順の主な原因

1. PHPのmemory_limitがサイトまたはリクエストに対して低すぎる。 WordPressコア、使用中のテーマ、プラグイン、現在のリクエスト、処理対象のデータによって、ホスティングの控えめな初期値を超えることがあります。
2. プラグインまたはテーマのメモリ使用量が大きい。 ページビルダー、インポート／エクスポートツール、バックアップソフトウェア、キャッシュツール、広範なSEOまたはマーケティングスイートは、特定のタスクで大幅に多くのメモリを使用することがあります。
3. 大規模な処理で一度に処理するデータ量が多すぎる。 メディアのインポート、商品の同期、移行、検索と置換などは、通常のページ読み込みが正常でも上限を超えることがあります。
4. 有効化されているプラグイン全体の基本メモリ使用量が大きい。 中程度のメモリ使用量のコンポーネントが複数あると、合計で上限を超えることがあります。
5. 設定レイヤー間で値が一致していない。 wp-config.php、ホスティングパネル、php.ini、.user.ini、適用される.htaccess設定によって、Webリクエストで実際に有効になる値が異なる場合があります。
6. コンポーネントの処理方法が非効率、またはメモリリークがある。 予測できる大規模処理のときだけでなく、比較的小さな処理や繰り返しの使用で特定の操作が失敗する場合、この可能性が高くなります。

修正方法

1. 失敗しているリクエストを特定する

可能であれば、完全な致命的エラーメッセージをコピーします。すべてのページ、ダッシュボードだけ、特定のプラグイン画面だけ、またはインポートや一括編集など特定の操作だけに影響するのかを記録してください。この違いから、全般的に上限が低いのか、特定の処理に固有の問題なのかを切り分けられます。

2. WordPressからより多くのメモリを要求する

ファイルを編集する前に、バックアップを作成するか、現在の設定を復元できることを確認してください。SFTPまたはホストのファイルマネージャーを使用してwp-config.phpを開き、/* That's all, stop editing! */の上に次の行を追加します。

define('WP_MEMORY_LIMIT', '256M');

これにより、サーバーが許可する範囲でWordPressが256 MBを使用するよう要求します。定数がすでに存在する場合は、2つ目を追加せず、既存の定義を編集してください。一部の管理タスクでは別の管理者用メモリ設定が使用されることがあるため、ダッシュボードだけで失敗する場合は、追加の調査が必要になることがあります。

3. サイトで使用されているPHPの上限を確認する

WP_MEMORY_LIMITで、サーバー独自のmemory_limitを超えてPHPの上限を引き上げることはできません。ホスティングのコントロールパネル、またはサイトにサービスを提供しているPHPバージョンが使用するphp.iniを確認してください。VPSでは、該当するPHP設定を変更するためにPHP-FPMまたは該当するPHPサービスの再起動が必要になることがあります。必要なアクセス権限と承認がある場合にのみ実施してください。

mod_phpを使用する一部のApache設定では、.htaccessに次のような設定を記述できます。

php_value memory_limit 256M

ただし、これはPHP-FPMには適用されず、ディレクティブが許可されていない環境ではサーバー設定エラーを引き起こす可能性があります。追加する前に、ホスティングパネルを使用するか、ホストに確認してください。コマンドラインPHPの設定は、Webリクエストで使用される設定と異なる場合があります。

4. 失敗した操作とまったく同じ操作を再実行する

エラーが発生したインポート、一括編集、プラグイン操作、またはページリクエストを再試行します。通常のページは失敗したタスクよりはるかに少ないメモリしか使用しないことがあるため、ホームページを読み込むだけでは不十分です。タスクが成功した場合は動作を監視し、同じ操作でさらにメモリが必要になる場合を除き、上限をこれ以上引き上げないでください。

5. 操作によるピーク時のメモリ使用量を減らす

インポート、移行、同期、一括編集では、ツールのバッチサイズを小さくするか、作業をより小さなグループに分割します。これは、すべてのPHPリクエストに非常に高い上限を割り当てるより安全なことがよくあります。大規模なジョブを比較的負荷の低い時間帯に実行すると運用上のリスクを減らせる場合がありますが、リクエストのピーク時メモリ要件が下がるわけではありません。

6. 原因の可能性があるプラグインまたはテーマを切り分ける

256Mまたは512Mでも不十分な場合、または変更後に問題が始まった場合は、失敗した画面やタスクに関連するコンポーネントをテストします。可能であればステージング環境のコピーを使用してください。本番サイトでは、まずバックアップを作成し、プラグインを1つずつ無効化します。ダッシュボードにアクセスできない場合は、SFTPまたはファイルマネージャーを使用して、疑わしいプラグインのディレクトリ名を一時的に変更し、WordPressが読み込めないようにします。

最近変更したコンポーネントと、失敗に関連するプラグインを優先して確認し、その後にページビルダー、インポート／エクスポートツール、バックアップツール、キャッシュツール、大規模なオールインワンスイートを確認します。フロントエンドのページが失敗する場合は、デフォルトテーマでもテストしてください。各テスト後に影響を受けていないコンポーネントを元に戻し、どの構成をテストしたのか分かるようにします。

7. 実際に有効な設定値を比較する

WP_MEMORY_LIMITを変更しても目に見える効果がない場合は、WordPressのリクエストと、Webリクエストで使用されるPHPの値を比較します。ホスティングパネル、php.ini、.user.ini、適用される.htaccess設定、およびホストによる上限を確認してください。自分で確認できない場合は、どのPHP設定が適用されるのかホストに問い合わせます。

8. 恒久的な解決を確認する

元の失敗した操作をもう一度実行し、その後、重要なフロントエンドページと管理画面を確認します。非常に高い上限を設定した場合にのみサイトが動作するなら、それを解決済みと判断せず、原因となっているプラグイン、テーマ、クエリ、またはバッチサイズの調査を続けてください。

予防と修正確認

• 本番環境のタスクが失敗するまで待つのではなく、ホストがサポートする適切なWordPressメモリ値を設定します。
• 使用していないプラグインを削除し、有効なプラグイン構成を定期的に見直します。基本的なメモリ使用量は累積するためです。
• インポート、移行、同期、一括編集のバッチを、利用可能なPHPメモリの範囲内に収めます。
• 大規模な操作は、サイト全体を処理する前に、ステージング環境または限定したデータセットでテストします。
• プラグインや設定を変更した後は、以前失敗した操作を再実行し、フロントエンドと管理画面の両方を確認します。
• WebリクエストにどのPHP設定が適用されるかを記録し、今後のメモリ変更を正しい場所で行えるようにします。

よくある質問