web-dev-qa-db-ja.com

Tomcat（v8）が定期的にCPUスパイクを引き起こす原因

Windows 2012 RT（x64）TESTサーバーでは、Tomcat 8のインストールを実行しており、CPU使用率は、ピーク使用量に達する規則性に戸惑っています。

この動作は、アプリケーションのインストール後に発生していますが、before誰もがそれにアクセスしています。私はいくつかのページにアクセスし、いくつかの機能をテストしましたが、私が知っているこの動作を作成できるものは何もありません。

サーバーには2つの仮想プロセッサがあり、約20秒ごとに、CPU使用率が（Tomcatを実行している1つのプロセッサで）10秒間（ギブまたはテイク）100％に急上昇します。下記参照：

Graph of periodic spikes

パターンの規則性は、Tomcat8のインストールまたは設定のいずれかに問題があることを示しています。

YourKit Java Profiler（by SO推奨））をインストールしました。これにより、これらのスパイクの原因を明らかにできると期待していましたが、まだインストールされていません。スレッドが開始する理由を確認できます-少なくとも部分的にはYourKitの新しさのためです。Tomcat起動ファイルに添付しましたが、動作を追跡しているようです。

カタリナログは（アプリケーションログと同様に）スパイクが発生している間はサイレントですが、Tomcatを停止すると、ThreadLocalsの開始に関するメッセージが表示されましたが、削除できませんでした。「...スレッドは時間の経過とともに更新されます。考えられるメモリリークを回避するようにしてください。」

週末にサーバーを稼働させたままにしましたが、パターンは今日まで続いているので、症状が消えるとは思いません。起動しているものはすべて、システム上で利用可能なすべてのRAMを消費しましたこれらのスレッドの起動から（および/またはYourKit）を20秒ごとに消費しました。

この異常なTomcatアクティビティを分離し、うまくいけばそれを停止または修正するための可能なアプローチは何ですか？

YourKitには多くのグラフとタブがあるので、役に立つかもしれないすべてのものをリストすることを躊躇します。 YourKit（または他のツール）が提供できる問題を絞り込むのを手伝ってくれてありがとう。

起動に関するカタリナログからの情報：

_Apache Tomcat/8.0.23
Architecture: AMD64
Java Home: C:\Program Files\Java\jre1.8.0_65
CATALINA_BASE: C:\Program Files\Apache Software Foundation\Tomcat 8.0
_

2015-12-08更新

Gergelyの要求に応じて、アプリケーションはDSpaceのローカルインストールです。これはJava Postgres SQLデータベースバックエンドを備えたアプリケーションです。ここからオープンソースバージョンをカスタマイズしています： http://www.dspace.org/introducing 。他に何が役立つかは正確にはわかりません。スタックトレースは、何が実行されているか（および実行されていないか）についてより明確になっていると思います。以下を参照してください。

YourKitでスタックテレメトリをオンにすることにより、プロファイラー履歴の期間にわたってカーソルをドラッグすることで「CPU推定」が利用可能になりました。私には、CPUが実行しているすべてがアイドル状態で回転しているように見えます。 Javaファイルを下に示しますTomcatルーチン？それらはDSpace関連として私を襲うことはありません（私は専門家ではありませんが）、またそれは他の仕事のようには見えませんCPUがピークになっている間に実行されています。

注目：スタックトレースはクワイエット期間中は同じです-唯一の違いはCPU時間（ミリ秒）が数千ミリ秒ではなく数百ミリ秒です。以下よりも直接比較するために、こぶはThread.run（）で約8,000ミリ秒を表し、クワイエット期間は約125ミリ秒のCPU時間を消費します（ただし、ほぼ同じ時間をカバーします）。

最後に、アプリケーションのページが要求されているとき、コードの後続のブランチがコールツリーに表示されます。スパイク時に発生した場合、ページ全体をロードするのに400ミリ秒のCPU時間しかかからない場合があります。表示されるコードブランチは、階層内のJava.lang.Thread.run（）の下にあるPooledExecutor $ Worker.run（）と一緒の完全に別個のブランチとしてのApplicationFilterChain.Javaです。

スタックトレースを解釈しようとする場合：EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run()は責任がありますか？

既知の関連アクティビティがないプロセッサスパイク

CPU Profiling

2015-12-08アップデート＃2

YourKitは、Java.lang.Threadでのドリルダウンを覆い隠していた特定のJavaクラス名パターンを非表示にするように事前構成されています。フィルターをクリアすると、次のスクリーンショットが有効になり、スパイク中の処理時間の大部分が示されます。イベントは、次の3つのメソッドを呼び出すことによって行われます。

  • Java.io.WinNTFileSystem.canonicalize0
  • Java.io.WinNTFileSystem.getBooleanAttributes（inFile.exists（））
  • StardardRoot.Java

誰がこれらのタスクを開始しているのかを知るのにTomcatまたはDSpaceについてまだ十分に知らないことをお詫びします。 （最初の行のすぐ上の行が重要な場合は、Java.lang.Thread.run()、次に_<All threads>_です）

better stack trace

performancetomcatdspacewindows2012yourkit
10
veeTrain

このお問い合わせをご覧いただき、誠にありがとうございました。さまざまな個人が推測しているように、問題はTomcatの設定と使用に関連しており、Tomcat自体の問題ではありません（ほとんどの場合）。

これは、DSpaceアプリケーションとTomcatのインストールに関する完全な知識がなくても質問に答える試みですが、危険であり、フォローアップユーザーに役立つ可能性があることは十分にわかっていると思います。

アプリケーションDSpaceをインストールする場合、Tomcatの構成ディレクトリには、Tomcatを再起動せずにコーディングファイルの変更をすぐに反映できるようにするかどうかを決定するいくつかのインストールプロパティがあります。これらの設定は、以前はディレクトリ[Tomcat]/conf/Catalina/localhost/にあり、3つのファイルのそれぞれに、次のような小さくて重要でないXMLファイルが含まれていました（例：oai.xml）。

<?xml version='1.0'?>
<Context docBase="E:/dspace/webapps/oai"
    reloadable="false"
    cachingAllowed="true"/>

これらのプロパティに関するドキュメントは、次のリンクにあります。 https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace

そのドキュメントには、reloadableおよびcachingAllowedプロパティに関する推奨事項が含まれています。 「本番環境でのTomcatコンテキスト設定」を検索します。これが抜粋です（私の強調）：

これらの設定は、DSpace XMLUI（XSLTまたはCSS）またはJSPUI（JSP）を微調整し、変更がTomcatによって自動的に再ロードされることを確認できるため（Tomcatを再起動せずに）、DSpaceを初めて使用するときに非常に便利です。 。ただし、Apache Tomcatのドキュメントでは、Tomcatがすべての変更を自動的にリロードできるようにすると「重大なランタイムオーバーヘッド」が発生する可能性があるため、本番サイトではデフォルト値（reloadable = "false" cacheingAllowed = "true"）を残すことを推奨しています。

これらのTomcat設定を適切に維持するかどうかは完全にあなた次第です。 Tomcatを再起動しなくてもサイトをより簡単にカスタマイズできるように、それらから始めることをお勧めします。小規模なDSpaceサイトでは、これらの設定を本番環境で維持してもパフォーマンスの問題に気付かない場合があります。 大規模なDSpaceサイトでは、Tomcatのパフォーマンスをより合理化することをお勧めします。

これらのブールフラグをreloadable="false"とcachingAllowed="true"に切り替えると、スパイクされたCPUエクスペリエンスはすぐに停止しました。「より大きなサイト」に関する警告が適用されるかどうかはわかりません。私たち、または「合理化されたパフォーマンス」が私が観察した否定的な活動を指すことができるかどうか。

私たちのインストールには、この特定の症状を許容する他の問題があるかもしれないと思います。不吉な手がかりの1つは、本番サーバーがreloadable="true"構成でこれらのフラグを使用して動作しているように見えることです。 Java、Tomcat、Windows、[〜＃〜]および[〜＃〜]DSpaceはすべて同時に新しいバージョンを取得しているため、同様のTomcat<context>の理由を特定するのはかなり困難です。設定はそのような異なる結果を生成します。

私は少なくとも今のところ、新しい振る舞いをして、システムが落ち着いたことに満足しています。もっと学べばもっと投稿しますが、次に他の難問に焦点を当てます。

更新

FWIW、属性はTomcatを直接制御する設定であり、バージョン間で変更されています。たとえば、バージョン8でcachingAllowedが削除されました。これは、Context要素から削除できることを意味します。比較：

https://Tomcat.Apache.org/Tomcat-8.0-doc/config/context.html#Attributeshttps://Tomcat.Apache.org/Tomcat-7.0-doc/ config/context.html＃Attributes

また、Tomcat8のドキュメントにあるreloadableのヘルプテキストを参考にしてください。

Catalinaで/ WEB-INF/classes /および/ WEB-INF/libのクラスの変更を監視し、変更が検出された場合はWebアプリケーションを自動的に再ロードする場合は、trueに設定します。この機能はアプリケーション開発中に非常に役立ちますが、実行時にかなりのオーバーヘッドが必要になるため、デプロイされた本番アプリケーションでの使用はお勧めしません。そのため、この属性のデフォルト設定はfalseです。ただし、Manager Webアプリケーションを使用して、デプロイされたアプリケーションのリロードをオンデマンドでトリガーできます。

したがって、最終的な答えは、フラグreloadable = 'true'を持つWindows2012-R2上のTomcat8がWEB-INF/libおよびWEB-INFへの変更をポーリングすることであるように思われます /クラス。閲覧するフォルダとファイルの量が、これらの激しいスパイクCPUイベントの原因である可能性があります。今のところ、reloadable = 'false'に依存します。これにより、症状が確実に解消されます。

13
veeTrain

明確な答えではありませんが、コメントするには長すぎます

この質問の更新を確認して少し読んだ後、この繰り返し発生する問題はCuratorTaskが原因であると思われます。理由：

  • 取得したスタックトレースは、DSpaceライブラリによって管理されるWorkerThread（Tomcatのせいではない）がその時点でプロセッサを使用していることを明確に示しています。

  • DSpace自体について少し読んだ後、それは機能がありますユーザーが キュレータータスク を定義できるようにする必要があるようです。 定期的に実行。

  • これに加えて少なくとも1つのタスクがあります-ドキュメントによるとデフォルトでアクティブ化なので、理論的にはデフォルトでアクティブ化されるタスクはいくつでもあります。 。

  • さらに、 this 会話は、少なくとも1つのキュレーションタスク10秒ごとにアクティブ化されるを明らかにします。

これらはすべて一緒に同じ方向を指しています。 DSpaceのUI（おそらく管理者モード）を使用して、周りを見回し、アクティブなキュレーションタスクを見つけて、それらのスケジュールが観察したものと一致するかどうかを確認することをお勧めします。

1
Gergely Bacso