3週間前にDrupal 7.14から7.15に切り替えたため、一連の非常に洗練された(私にとって)メモリ制限エラーに遭遇しています。これらのエラーパフォーマンスのキャッシュをクリアしたり、更新スクリプトを実行したりするときにいつでも発生します。
私のホスティング会社はphp.iniのメモリ制限を126 M、256 M、512 M、さらには1024 Mまで増やしました。しかし、エラーはまだ発生します。私のサイトを共有からVPSに移行しましたが、それでもエラーが発生します。私には方法がなく、どうすれば前進できるかわかりません。
ここにエラーがあります:
致命的なエラー:行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のメモリの問題で、最後の壁に頭をぶつけてきました。ここに私のトピックについて集めた知識があります:
私はいくつかのビュー(およびパネルとCTools、およびmerlinofchaosが彼の力強い指で触れるすべてのもの)を愛していますが、多くのメモリを使用する複数の関係を持つ構成を作成することは可能です。ビューを無効にしてメモリの問題が解消された場合は、ビューの構成が不適切であるために問題が発生している可能性があります。
それがビューであり、本当にそのビューが機能する必要がある場合はどうしますか?まず、コード(Bulk ExporterまたはFeaturesを使用して、以下を参照してください。パフォーマンスを向上させるために、ビューのような機能を手動でコーディングしましたが、ほとんど成功しません)を試してみてください。もう1つの考えは、ビューを別の方法でやり直すことです。つまり、最終的に得られるのが分類用語の場合、ビューのタイプが作成時に分類ビューであることを確認してください。関係を使用して分類用語を取得するコンテンツビューを作成しないでください。
また、Panelsも大量のメモリを使用している可能性があることをここで言及する価値があります-私は実際にベンチマークしていないため、これを確認できません。
これを実現するためにいくつかのDrupalサイトが必要でしたが、UIを介して作成されたすべてのもの(特にビューとパネルの構成)をデータベースに保持することは、Drupal最悪ですこれは、データベースへの負荷が増加し、バージョン管理ができないためです。最初の点は、メモリ使用量の点で特に問題があります。データベースからビューからコンテンツをロードするだけでなく、サイトもビューコンポーネント自体をロードする必要があります。 。これは、Drupalがテーブルを使用する方法によって悪化します。すべてをn次まで抽象化することにより、Drupalの機能の各ビットが新しいテーブルを使用し、結果としていくつかのリクエストがバジリオンテーブルを結合します。これにより- コンピュータサイエンスの人々ヘルニア (警告:リンクはばかげています)しかし、Drupalのようにモジュール式でユーザーフレンドリーなソフトウェアでは、これを回避することはできません。
ソリューション? Bulk Exporter(CToolsに含まれています)または Features を使用して、データベースに現在存在するコードのビットをモジュールコードとしてパッケージ化します。
あなたのテーマにはたくさんのテンプレートファイルがありますか(例:themename/templates /にあるファイル)?その場合、これらのファイルのいずれかが読み込まれるたびにメモリが消費されます。 Drupalの一部が表示されないようにするためのテンプレートを作成している場合は、次のいずれかを試してください。
最初の選択は、セキュリティに影響を与えるものに対して実行したいことです。CSSを使用して特定のユーザーの「編集」ボタンを非表示にしたくない場合は、Firebugなどで非表示にしないでください。
サイトには多くのcontribモジュールが必要な場合がありますが、やり過ぎないでください。各有効(注:有効。無効モジュールはメモリを使用しません)モジュールはメモリを使用します。これは少し明白ですが、関係なく注目に値します。
私の経験では、 一部の悪質なホスティング会社 プッシュしようとする愛DrupalサイトをVPSサーバーに-より高価であり、共有ホスティングスペースを永久に解放します-詳細WordPressウェブサイト。ウェブホスティングは共有ホスティングのメモリの上限をアドバタイズしない(または尋ねられた場合でも通知する)ことが多いため、状況は悪化します。
悲しいかな、多くの場合、サイトのトラフィックが多くなく、それでもクラッシュしている場合、問題はおそらく何よりもDrupalの構成に関係しています。ユーザーをVPSにプッシュすることは、水を濁し、処理する変数を追加するだけです(それは、Webサーバーの構成ですか?PHP構成?VPSゲスト構成?VPSホスト構成でも?)。
これが、人々がバージョン管理を備えたdev-staging-production方法論を使用する大きな理由です-他のすべてが失敗した場合、DBダンプを実行し、サイトをローカルのテストサーバーにgit cloneして、サイトのサイトを破壊します。本番サーバーで実際に何かが壊れることを心配することなくサーバーをテストします。
メモリの問題の場合、これは通常、問題の原因となっているモジュールが明らかになるまで、モジュールを1つずつ無効にすることを意味します。また、ウェブホスト関連の問題を指摘している可能性があります。サイトがローカルインストールでメモリを128MBなどの適切な値に設定して完全に正常に実行されている場合、ウェブホストがクラックしていることがわかります。
私の直感は、問題を引き起こしているのはchain_menu_accessであるということです。それを無効にしてキャッシュをクリアしてみて、動作するかどうか確認してください。
他にも試してみたいことがあるので、この回答にも追加します...
PHP XHProfやXdebugの組み込みプロファイラのようなプロファイラを入れて、リクエストで何が起こっているかを調べることができます。
ビューは記憶を独り占めします。 Drupalのキャッシングが役立ちます。 Drupalは、アクティブなモジュールのみをロードしますが、テーブルを作成したり、他のオブジェクトがぶらぶらしている場合は、アンインストールするだけで、ほとんどのアーティファクトが削除されます。drupalの承認/権限を使用し、内部に独自のモジュールを書き込みます。最高ではありませんが、パフォーマンスははるかに優れており、調整も簡単です。WPについても同様です。
私の場合、メモリ制限の問題はキャッシュシステム(BoostおよびBoost Expireモジュール)によって生成されたものです。これにより、モジュールまたはビューの更新に関する問題が発生します。無効にすると、Boostモジュールはすべて正常に動作します。