3週間前にDrupal 7.14から7.15に切り替えたため、一連の非常に洗練された（私にとって）メモリ制限エラーが発生します。これらのエラーは、パフォーマンスのキャッシュをクリアしたり、更新スクリプトを実行したりするときに発生します。

私のホスティング会社はphp.iniのメモリ制限を126 M、256 M、512 M、さらには1024 Mまで増やしました。しかし、エラーはまだ発生します。私のサイトを共有からVPSに移行しましたが、それでもエラーが発生します。私には方法がなく、どうすれば前進できるかわかりません。

ここにエラーがあります：

• 致命的なエラー：536870912バイトの許容メモリサイズが/home/example/public_html/sites/all/modules/views/views.moduleの416行で使い果たされました（30バイトを割り当てようとしました）

• 致命的なエラー：行2736の/home/example/public_html/includes/menu.incで許可されたメモリサイズ536870912バイトを使い果たしました（108バイトを割り当てようとしました）

• 致命的なエラー：/home/example/public_html/sites/all/modules/chain_menu_access/chain_menu_access.moduleの59行目で、許可されたメモリサイズ536870912バイトを使い果たしました（71バイトを割り当てようとしました）。

• /home/example/public_html/sites/all/modules/views/includes/base.incの93行目に64バイトを割り当てます

また、Drupalのメモリの問題で最後に壁に頭をぶつけてきました。これが私のトピックについて収集した知識です：

1.ビューは大量のメモリを使用する（できる）

私はいくつかのビュー（およびパネルとCTools、およびmerlinofchaosが彼の力強い指で触れるすべてのもの）を愛していますが、多くのメモリを使用する複数の関係を持つ構成を作成することは可能です。ビューを無効にしてメモリの問題が解消された場合は、ビューの構成が不適切であるために問題が発生している可能性があります。

それがビューであり、本当にそのビューが機能する必要がある場合はどうしますか？まず、コード（Bulk ExporterまたはFeaturesを使用して、以下を参照してください。パフォーマンスを向上させるために、ビューのような機能を手動でコーディングしましたが、ほとんど成功しません）を試してみてください。別の考えは、ビューを別の方法でやり直すことです。つまり、最終的に得られるのが分類用語である場合、ビューのタイプが作成時に分類ビューであることを確認してください。関係を使用して分類用語を取得するコンテンツビューを作成しないでください。

また、Panelsも大量のメモリを使用している可能性があることをここで言及する価値があります-私は実際にベンチマークしていないため、これを確認できません。

2.データベースからコードへのものを移動することは非常に良い習慣です

これを実現するにはいくつかのDrupalサイトが必要でしたが、UIを介して作成されたすべてのもの（特にビューとパネルの構成）をデータベースに保持することは、Drupalの最悪の習慣です。どうして？データベースの負荷が増加し、バージョン管理できません。最初の点は、メモリ使用量の点で特に問題があります。データベースからビューからコンテンツをロードするだけでなく、サイトはビューコンポーネント自体もロードする必要があります。これは、Drupalがテーブルを使用する方法によって悪化します。すべてをn次まで抽象化することにより、Drupalの機能の各ビットが新しいテーブルを使用し、いくつかのリクエストがバジリオンテーブルを結合します。これはコンピューターサイエンスの人々に苦痛を与えます（警告：リンクはばかげています）が、Drupalのようにモジュール式でユーザーフレンドリーなソフトウェアでは、これを回避することはできません。

ソリューション？バルクエクスポーター（CToolsに含まれています）または機能を使用して、現在データベースに常駐しているコードのビットをモジュールコードとしてパッケージ化します。

3.テーマは記憶を食べることもあります

あなたのテーマにはたくさんのテンプレートファイルがありますか（つまり、themename / templates /にあるファイル）？その場合、これらのファイルのいずれかが読み込まれるたびにメモリが消費されます。Drupalのビットが表示されないようにするためのテンプレートを作成している場合は、次のいずれかを試してください。

1. 特定の非管理者ユーザーの役割に対してビットが表示されないように権限を変更する。
2. CSSを使用して要素を非表示にする。

最初の選択は明らかに、セキュリティに影響を与えるものに対して何をしたいかです。CSSを使用して特定のユーザーの「編集」ボタンを非表示にしたくない場合は、Firebugなどで非表示にしないでください。

4. contribモジュールを使いすぎないでください

サイトには多くのcontribモジュールが必要な場合がありますが、やり過ぎないでください。各有効（注：有効。無効モジュールはメモリを使用しません）モジュールはメモリを使用します。これは少し明白ですが、関係なく注目に値します。

5. VPSは（時には）嘘です

私の経験では、悪質なホスティング会社の中には、DrupalサイトをVPSサーバーにプッシュすることを好むものがあります。それらはより高価であり、共有ホスティングスペースを解放して、WordPressのWebサイトを増やします。共有ホスティングのメモリの上限が何であるかをウェブホストが宣伝しない（または尋ねられた場合でも喜んで通知する）ことが多いため、状況はさらに悪化します。

悲しいかな、多くの場合、サイトのトラフィックが多くなく、それでもクラッシュしている場合、問題はおそらく何よりもDrupalの構成に関係しています。ユーザーをVPSにプッシュすることは、水を濁らせ、処理する変数を追加するだけです（それはWebサーバー構成ですか？PHP構成ですか？VPSゲスト構成ですか？VPSホスト構成ですか？）。

6.他のすべてが失敗したら、localhostにクローンを作成し、スティックでそれを打ちます

これが、人々がバージョン管理を備えたdev-staging-production方法論を使用する大きな理由です-他のすべてが失敗した場合、DBダンプを実行し、サイトをローカルのテストサーバーにgit cloneして、サイトのサイトを破壊します。本番サーバーで実際に何かが壊れることを心配することなくサーバーをテストします。

メモリの問題の場合、これは通常、問題の原因となっているモジュールが明らかになるまで、モジュールを1つずつ無効にすることを意味します。また、ウェブホスト関連の問題を指摘している可能性があります。サイトがローカルインストールでメモリを128MBなどの適切な値に設定して完全に正常に動作している場合、ウェブホストがクラックしていることがわかります。

tl; dr

私の直感は、問題を引き起こしているのはchain_menu_accessであるということです。それを無効にしてキャッシュをクリアしてみて、動作するかどうか確認してください。

他にも試してみたいことがあるので、この回答にも追加します...

XHProfやXdebugの組み込みプロファイラーのようなPHPプロファイラーを配置して、リクエストで何が起こっているかを調べることができます。

ビューは記憶を独り占めします。Drupalのキャッシングが役立ちます。Drupalはアクティブなモジュールのみをロードしますが、テーブルを作成したり、他のオブジェクトがぶらぶらする可能性がある場合のみです。アンインストールするだけで、ほとんどの成果物が削除されます。drupalの承認/許可を使用し、内部に独自のモジュールを記述します。最高ではありませんが、パフォーマンスははるかに良く、調整も簡単です。WPについても同様です。

私の場合、メモリ制限の問題はキャッシュシステム（BoostおよびBoost Expireモジュール）によって生成されたものです。これにより、モジュールまたはビューの更新に関する問題が発生します。無効にすると、Boostモジュールはすべて正常に動作します。