web-dev-qa-db-ja.com

cache_menuアイテムは巨大です

Drupal 7.24

D7サイトで興味深い問題に悩まされています。基本的に、cache_menuテーブルは非常に大きくなっていましたが、アイテム（奇数6300）だけではなく、いくつかのアイテムが巨大です。

私にとってはその新記録、アイテムの1つは1.24 mbで、そのうちの26は800kから1mbの間です。

トラフィックがわずかに上昇しているgitのときにサイトがダウンし、RDSが後ろにある負荷分散されたAWSクラスターで実行されていました。20の同時接続サイトにはリソースが不足していません。

私はcache_menuを切り捨て、サイトを閲覧してすべてを再生成しましたが、いくつかのアイテムを除いてすべてなくなっていますが、1.2 mbのアイテムと800 kbのアイテムがまだ残っています。

私はこのリンクをたどりました- http://drupal.org/node/12348 ここから 巨大なcache_menuテーブル そして、この特定の問題は7.13以降で解決されたようですので、私は何か建築上の問題が発生していると考えています。

コアハックはありません。分類用語にフックするロジックサーバーネットワーク（SOLRで外部で実行される）を使用した印象的な検索システムがあります。このサイトは基本的にリンクのポータルです。

誰かが私にこの問題の追跡を開始する場所に関するいくつかの指針を教えてもらえますか？

編集：CID/cache_menuのサイズ、クエリ：

SELECT cid, LENGTH(`data`)/1024 as `size KB` FROM cache_menu WHERE LENGTH(`data`)/1024 > '300' ORDER BY `size kb` DESC;

結果

links:management:tree-data:en:ec99d3452fef1ede622e66c68ba908b1dad455aa71f5e68648aeec6488b89c88
1094.2188
links:main-menu:all-cid:0:1:en
839.4873
links:main-menu:tree-data:en:ec99d3452fef1ede622e66c68ba908b1dad455aa71f5e68648aeec6488b89c88
815.6230
7cachingusers
2
mister koz

サイトに非常に大きなメニューがいくつかあると思います。メニューの再構築は負荷の高い操作であり、メニューツリーはページごと、ユーザーごとなどさまざまです。その結果、そのデータは_{cache_menu}_にキャッシュされます。

私の提案は、お気に入りのSQLツールでクエリを実行し、大きなエントリのデータ列をprint_r()して、異常なものがないかどうかを確認することです。一般に、データは、さまざまなhook_menu()エントリからのすべてが追加されたメニューツリーになります。メニューエントリに追加のデータを追加するモジュール（メニュー属性など）にも、ここにデータがあります。

問題が実際に発生している場所を確認するには、プロファイルを作成する必要があります。

これは、理想的とは言えない構成のMySQLインスタンスの結果である可能性があります。 1Mのキャッシュエントリがある場合は、クエリキャッシュの結果セットの制限を引き上げることができます（これはデフォルトで128Kになると思います）。

キャッシュバックエンドとしてmemcacheまたはredisを使用して調査することもできます。

ただし、実際に巨大なメニューがある場合は、データのシリアル化をすべて解除することで速度が低下する可能性があります。この場合は、ページの作成時にメニュー出力をキャッシュする方法を理解する必要があります。ブロックレベルのキャッシュを有効にすると役立つ場合があります。または、独自のメニューブロックを作成し、その出力を自分でキャッシュする必要がある場合があります。パネルのキャッシュは調査する価値があります。

奇妙に聞こえるかもしれませんが、_{cache_menu}_のキャッシュを無効にしてみてください。これを行う最も簡単な方法は、ダミーキャッシュモジュールの1つをインストールし、そのキャッシュバックエンドを_{cache_menu}_に使用するように構成することです。

2
mpdonadio