8

Tomcat にデプロイするのに非常に時間がかかることが多い Web アプリケーションがあります。タイムアウトまで待機しているデータベース接続がどこかにあるのではないかと疑っていますが、それは単なる推測であり、問​​題を解決できるように、何が原因で停止しているのかを確認したいと考えています。誰かがこれを行う方法を提案できますか? Tomcat が WAR をロードしているときにプロファイルを作成し、手がかりを探す必要がありますか? もしそうなら、初心者向けのチュートリアルはどこかにありますか?

これが問題になる場合、私の Web アプリケーションは Spring と Hibernate を使用します。私は同僚から、おそらくこれらが非常に巨大であるという点で速度低下を引き起こしているので、どこかでクラスローダーがロードする必要のある膨大な数のクラスを窒息させていると言われました。

また、Tomcat を停止するか、すでに実行中の Tomcat に WAR をホットデプロイすると、次のように表示されます。

Jun 1, 2012 6:03:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
SEVERE: The web application [/nacem-rest] registered the JDBC driver [oracle.jdbc.OracleDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
Jun 1, 2012 6:03:34 PM org.apache.catalina.startup.HostConfig deployWAR

おそらくこれは問題の一部ですか？ほとんどの場合、Web アプリケーションを再デプロイするには、Tomcat の再起動も必要です。上記の JDBC ドライバーの問題が原因であると常に想定していましたが、起動時間の遅さも関係しているのではないでしょうか?

4

7 に答える 7

8

プロファイラーを使用できますが、少しやり過ぎです。代わりに、アプリケーションのロード中にスレッド ダンプをいくつか作成します。jstackまたはjvisualvm、これを行う方法を説明するネット上の多くのリソースを使用できます。基本的に、Tomcat の PID が必要です (参照: jps)。

スレッド ダンプを分析するのが難しい場合は、質問に追加してください。通常、ボトルネックを見つけるのは非常に簡単です。典型的な問題:

  • アプリケーションは、インターネットから XML スキーマなどのリソースを取得しようとします。
  • CLASSPATH でスキャンする多数のクラス
  • 過剰な GC (念のため詳細な GC ログを有効にします)
  • メモリ不足 (スワッピング、iostat/を参照iotop)
于 2012-06-01T21:31:46.907 に答える
5

最初に確認するのは、アプリケーションの起動時にTomcatのCPUまたはRAMの使用量がどのように機能するかです。

多くのCPUアクティビティとRAMの増加が見られる場合は、多くのクラスなど、多くのものをロードしているか、ある種の巨大な事前割り当てなどを実行している可能性があります。その場合、スレッドダンプは非常に役立ちますが、「lsof」（Tomcatが* nix環境で実行されている場合）を使用して、現在作業中のファイルを確認することもできます。

ただし、単にそこに座っているのを見ると、おそらく何らかの接続を待っています。

ご想像のとおり、1つの原因はDB接続である可能性があります。DBは通常、応答が速く、DBに接続しようとして失敗した場合は、通常、どこかに明確に記録されますが、それでも記録される可能性があります。

もう1つの、あまり知られていない原因は、XML検証である可能性があります。Webアプリケーションが一部のXMLデータをロードすることは珍しくありません。また、検証パーサーを使用してそのXMLをロードすることも珍しくありません。検証パーサーは検証するためにスキーマまたはDTDを必要とし、スキーマ/DTDファイルのURLは多くの場合XMLに含まれています。そのため、一部のパーサーは、XMLを検証するためにインターネットからスキーマファイルをロードしようとします。これは、インターネット接続であるために多くの時間がかかる可能性があります。さらに、一部のパーサーはサイレントに失敗し、おそらくかなり長いタイムアウトの後、XMLを検証しません。「一部のパーサー」などについてあいまいになって申し訳ありませんが、XMLの読み込みがWebアプリ内で使用されるライブラリによって行われる場合、JVM XMLパーサー、Xercesの可能なバージョン、JDOMの可能なバージョンなどを使用できます。

ただし、接続の問題である場合は、「netstat -anlp | grep java」（tomcatでは* nix環境、それ以外の場合はWindowsでは「netstat-ano」）を使用して確認する方が簡単です。 Tomcatが作成しようとしている発信接続。ここでは、DB接続と、スキームやその他のものを検索する発信（通常はhttp）接続を確認できます。

于 2012-06-01T22:32:55.340 に答える
4

Tomcat 7.0.x を使用している場合、クラスパスをスキャンして注釈を検出している可能性があります。多くの jar / クラスがある場合、これが問題になる可能性があります。

Simone が言うように、いくつかのスレッド ダンプを取得して分析することは、開始するのに適した方法です。

最新バージョンの Tomcat を使用していない場合は、アップグレードして conf/catalina.properties ファイルをチェックし、スキャンされる jar の数を減らす方法に関するヒントを確認してください。

于 2012-06-03T14:45:20.543 に答える
3

展開中にいくつかのスレッド ダンプを取得し (多いほど良い)、それらを分析する必要があります。ブロック、待機などを探します。Thread Dump Analyzerが役立つ場合があります。

于 2012-06-01T21:31:54.880 に答える
1

これはJDKのこのバグに関連している可能性があります

この記事を読んで、Ubuntu 14.04 x64 で Tomcat7 の起動が遅すぎて問題が解決しました。

$JAVA_PATH/jre/lib/security/java.security の securerandom.source=file:/dev/urandom を securerandom.source=file:/dev/./urandom に置き換えて、解決を試みてください。

于 2015-07-13T05:49:58.190 に答える
0

Web アプリケーションを Tomcat8 にデプロイするときに、大幅な遅延が発生することがわかりました。WAR 内の context.xml ファイルで 3 つのデータベース接続プールを構成しました。各接続プールの初期接続数は 10 だったので、Tomcat は起動時に 30 のデータベース接続を作成していました。テスト システムで各プールを 1 つの初期接続用に構成すると、展開時間が約 3 分から 22 秒に短縮されることがわかりました。

于 2016-05-27T15:04:57.727 に答える
-3

setenv.sh作業tomcat7/binディレクトリの下に追加します。

JAVA_OPTS="-Djava.security.egd=file:/dev/./urandom"

于 2016-11-14T18:01:25.360 に答える