2016-11-11 8 views
1

スプリット環境(CDとCMS)を使用して8.1からSitecore 8.2にアップグレードした後は、そうです。パフォーマンスに関する問題はほとんど見られません。CMSは正常に動作しますが、スレッド数はローカルで約200です! CDはサイトを起動した直後にすべてのメモリを消費するだけでフリーズしますが、ログにもエラーは表示されません。Sitecore 8.2パフォーマンスの問題/クラッシュ

何が間違っている可能性がありますか?

答えて

0

考えられる原因として、Sitecoreイベントキューのサイズが考えられます。

は、特にウェブデータベースのすべてのイベント・キューからレコード数を確認します。

SELECT count(*) FROM [EventQueue] 

カウントはあなたがより良いパフォーマンスのためにクリーンアップする必要が100Kのような高い場合。最大で数千のレコードがあるときに最も効果的です。

を参照してください:あなたはCDサーバー上のログファイルに継続的にすべてのエラーを取得していない場合

Publish Queue, History and Event Queue too big

sitecore-event-queue-how-to-clean-it-and-why

+0

イベントキューは非常に安定していますが、スレッド数はローカルマシン上で約177です。ログにエラーが表示されません – CodeBox

0

ご確認ください。

リダイレクトを確認して問題が発生しているかどうか確認してください。私たちはこれを私たちの事例では過去に問題として見つけました。

Sitecoreパフォーマンスカウンタでより多くの診断を受けることができます。 CPU使用率が高いプロセスの場合

+0

ログは安定しているようです – CodeBox

0

は、私はゼロ

<agent type="Sitecore.Tasks.CleanupAgent" method="Run" interval="06:00:00"> 
に間隔を設定することsitecore.configファイルで、このクリーンアップエージェントを停止してみてください、あなたはメモリ消費プロセスの一つと考え、いくつかのエージェント・プロセスを停止する必要があると思います
0

CPU使用率が急上昇していたが、サイトログのログファイルにエラーが見つかりませんでした。IISログから見たようにウェブトラフィックは正常でした。これが問題の解決方法です。

IISユーザーインターフェイスとサイトがホストされているアプリケーションプールでは、現在実行中のIISワーカープロセスを確認してください。各リクエストがASP.NETパイプラインの異なる部分と現在実行中のHTTPモジュールにあることがわかります。

任意のリクエストがリクエストされているかどうかを確認してください。同じURLからのリクエストが複数ある場合、そのURLの一部のモジュールがハングアップまたは無限ループになっていることを意味します。これで、このURLで使用されているモジュールを調べて、実際の問題を見つけることができます。

関連する問題