1

Sitecore (6.6) の実装では、Lucene インデックスを使用しています。私たちの PROD サーバーでは、インデックスの構築プロセスが非常に遅いです。現時点では、インデックス キューで待機するエントリが 5000 以上あります。

私が使用したクエリ（マスターデータベースで）、

select * from Properties (check the index last run time)

select * from History where created > 'last index updated time'

この遅延の結果、作成されるデータは、Web サイトでの変更を反映しません。また、このキューは増え続けています。サイトがオフラインになると、しばらくするとインデックスの構築が追いつきます。

その重い読み取り集中型の Web サイト。

CPU 使用率が高くなる問題が発生しましたが、現在は解決されています。CPU 使用率が高いため、インデックスの構築が遅れていると考えました。しかし、現在、CPU は約 30 ～ 40% 実行されています。それでも lucene インデックス作成キューの増加率は高いです。

この問題を解決するにはどうすればよいですか? 助けてください。

4

2 に答える 2

0

Sitecore にどのような構成変更を加えることができるかを検討する前に、まず一歩下がって、履歴テーブルに大量のエントリが追加されている理由について質問する必要があると思います。

実装の各ユース ケースに基づいて開発環境でコードをトレースし、アイテムが次の場所にある Sitecore API へのすべての呼び出しを見つける必要があります。

  1. Sitecore ツリーに追加
  2. 編集済み - セキュリティ、プレゼンテーション、ワークフロー、公開制限などを含むフィールド項目の変更。
  3. 複製された
  4. Sitecore ツリーから削除
  5. 新しい場所に移動しました。
  6. 新しいバージョンが追加されました
  7. バージョンが削除されました

作業中は、アイテムに対するすべての編集アクションが常に単一の Sitecore.Data.Items.Item.Editing.BeginEdit() および Sitecore.Data.Items.Item.Editing.EndEdit() 呼び出しで実行されることを確認してください。これにより、変更が複数ではなく単一の編集アクションとして実行されます。Sitecore.Data.Items.Item.Editing.EndEdit() が呼び出されるたびに、新しいレコードが履歴テーブルに挿入されるため、不要な編集は履歴テーブルのサイズを増やすだけです。

Sitecore.Data.Items.Item.CopyTo() メソッドを使用してアイテムを複製する場合、アイテムのすべてのバージョンとアイテムの子孫が複製されることに注意してください。つまり、履歴テーブルには、コピーされたアイテムのすべてのバージョンのレコードが含まれます。最新バージョンのみが必要なため、作成後に新しいアイテムから古いバージョンを削除する場合、アイテムからバージョンを削除すると、削除された各バージョンの履歴テーブルにレコードが挿入されることに注意してください。

上記のすべてのアクションをシステムを機能させるために必要な最小限に抑えた場合、Sitecore のデフォルトのインデックス構成を変更しなくても、Lucene のインデックス作成が最新の状態に保たれることがわかるはずです。

于 2014-09-17T06:42:10.943 に答える