2

ここでは、Ubuntu (サーバー版) を使用して Tomcat6 で実行されている Java Web アプリケーションを取得しました。1 ~ 3 日後、アプリケーションが非常に遅くなるため、Tomcat を新たに再起動した後にスレッドダンプを作成し、アプリケーションが遅くなり始めたときに別のスレッドダンプを作成しました。

再起動後のスレッドダンプ:

3 日後のスレッドダンプ (現在アプリケーションが遅い):

私が投稿したダンプから、何らかの理由で終了していないように見えるスレッドがたくさんあることがわかります。残念ながら、どのクラス (クラス名?) とその理由がわかりません。コンソールで使用topすると、「VIRT」の値が ~800 (再起動後) から 4000 以上 (3 日後) に上昇したことが示されました。

これらのダンプをより適切に解釈するにはどうすればよいですか? すでにそれらを TDA にロードしようとしましたが、うまくいきませんでした (TDA はそれらをダンプとして認識していないようです)。

たぶん、誰かがダンプで何が起こっているのかをすでに見ていますか?

4

4 に答える 4

5

jstack テキスト ファイルで、多数のスレッドが BCI (Byte-Code Interpreter) でハングしていることがわかります。おそらくコードを解釈しています。コード内のどこで解釈されているかを示しているようには見えません。

デッドロック状態にあると言っています

.out ファイルで、アプリケーション コードらしきものを探しました。私はそれがぶら下がっているのを見ます

  • EventProcessingThreadImpl.run:479 (2 スレッド)

  • GC.java:100 (1 スレッド) GC で何かが解放されるのを待っているため、GC を続行できます。

  • ThreadPoolExecutor.java:907 で、多くのスレッドが安全でない状態でパークされ、シンクロナイザーを保持し、ジョブ キューを読み取ろうとしています。

  • また、多くのボイラープレートのように見えるものも見ます - 与えられた仕事を待っているスレッド、実行可能なスレッド、メールを待っているスレッドなど。

これは役に立ちますか?

追加した:

OK、あなたのコードを検索したところ、ここに表示されている 3 つのスレッドで見つかりました。各スレッドの下に暫定的な説明を記載しました。

(また、jstack を使用したデッドロックの検出に関するこのリンクにも注意してください。)

----------------- 20607 -----------------
__pthread_cond_wait + 0xcc
_ZN13ObjectMonitor4waitElbP6Thread + 0x60a
_ZN18ObjectSynchronizer4waitE6HandlelP6Thread + 0x53
JVM_MonitorWait + 0x1e7
<Unknown compiled code>
* java.lang.Object.wait() bci:2 line:485 (Interpreted frame)
* org.zkoss.zk.ui.impl.EventProcessingThreadImpl.doSuspend0(java.lang.Object) bci:143 line:219 (Interpreted frame)
* org.zkoss.zk.ui.impl.EventProcessingThreadImpl.doSuspend(java.lang.Object) bci:7 line:185 (Interpreted frame)
* org.zkoss.zk.ui.impl.UiEngineImpl.wait(java.lang.Object) bci:198 line:1471 (Interpreted frame)
* org.zkoss.zk.ui.Executions.wait(java.lang.Object) bci:4 line:702 (Interpreted frame)
* org.zkoss.zul.Window.enterModal() bci:22 line:619 (Interpreted frame)
* org.zkoss.zul.Window.doModal() bci:67 line:551 (Interpreted frame)
* org.zkoss.zul.Messagebox.show(java.lang.String, java.lang.String, int, java.lang.String, int,     org.zkoss.zk.ui.event.EventListener) bci:343 line:274 (Interpreted frame)
* org.zkoss.zul.Messagebox.show(java.lang.String, java.lang.String, int, java.lang.String) bci:6 line:128 (Interpreted frame)
* com.smampi.web.view.client.ClientController$5.onEvent(org.zkoss.zk.ui.event.Event) bci:8 line:417 (Interpreted frame)
* org.zkoss.zk.ui.impl.EventProcessor.process0(org.zkoss.zk.ui.ext.Scope) bci:384 line:192 (Compiled frame)
????????

スレッド 20607 は com.smampi.web.view.client.ClientController$5.onEvent の 128 行目にあります (私は推測しています)。モーダル メッセージ ボックスを表示し、応答を待っています。

----------------- 20878 -----------------
__pthread_cond_wait + 0xcc
_ZN13ObjectMonitor4waitElbP6Thread + 0x60a
_ZN18ObjectSynchronizer4waitE6HandlelP6Thread + 0x53
JVM_MonitorWait + 0x1e7
<Unknown compiled code>
* java.lang.Object.wait() bci:2 line:485 (Interpreted frame)
* org.zkoss.zk.ui.impl.EventProcessingThreadImpl.doSuspend0(java.lang.Object) bci:143 line:219 (Interpreted frame)
* org.zkoss.zk.ui.impl.EventProcessingThreadImpl.doSuspend(java.lang.Object) bci:7 line:185 (Interpreted frame)
* org.zkoss.zk.ui.impl.UiEngineImpl.wait(java.lang.Object) bci:198 line:1471 (Interpreted frame)
* org.zkoss.zk.ui.Executions.wait(java.lang.Object) bci:4 line:702 (Interpreted frame)
* org.zkoss.zul.Window.enterModal() bci:22 line:619 (Interpreted frame)
* org.zkoss.zul.Window.doModal() bci:67 line:551 (Interpreted frame)
* org.zkoss.zul.Messagebox.show(java.lang.String, java.lang.String, int, java.lang.String, int, org.zkoss.zk.ui.event.EventListener) bci:343 line:274 (Interpreted frame)
* org.zkoss.zul.Messagebox.show(java.lang.String, java.lang.String, int, java.lang.String) bci:6 line:128 (Interpreted frame)
* com.smampi.web.view.client.ClientController$5.onEvent(org.zkoss.zk.ui.event.Event) bci:8 line:417 (Interpreted frame)
* org.zkoss.zk.ui.impl.EventProcessor.process0(org.zkoss.zk.ui.ext.Scope) bci:384 line:192 (Compiled frame)
????????

スレッド 20878 もメッセージ ボックスを表示していますが、417 行目です (私は推測しています)。

----------------- 22792 -----------------
__pthread_cond_wait + 0xcc
_ZN7Monitor5ILockEP6Thread + 0xb9
_ZN7Monitor4lockEP6Thread + 0xf2
_ZN7Monitor4lockEv + 0x28
_ZN18GenCollectorPolicy17mem_allocate_workEmbPb + 0xca
_ZN16GenCollectedHeap12mem_allocateEmbbPb + 0x38
_ZN13CollectedHeap26common_mem_allocate_noinitEmbP6Thread + 0x9a
_ZN13instanceKlass17allocate_instanceEP6Thread + 0x7d
_ZN18InterpreterRuntime4_newEP10JavaThreadP19constantPoolOopDesci + 0xda
* com.sun.mail.util.SocketFetcher.startTLS(java.net.Socket, java.lang.String, java.util.Properties, java.lang.String) bci:378 line:413 (Interpreted frame)
* com.sun.mail.iap.Protocol.startTLS(java.lang.String) bci:23 line:377 (Interpreted frame)
* com.sun.mail.imap.protocol.IMAPProtocol.startTLS() bci:3 line:734 (Interpreted frame)
* com.sun.mail.imap.IMAPStore.login(com.sun.mail.imap.protocol.IMAPProtocol, java.lang.String, java.lang.String) bci:24 line:676 (Interpreted frame)
* com.sun.mail.imap.IMAPStore.protocolConnect(java.lang.String, int, java.lang.String, java.lang.String) bci:343 line:643 (Interpreted frame)
* javax.mail.Service.connect(java.lang.String, int, java.lang.String, java.lang.String) bci:380 line:295 (Interpreted frame)
* com.smampi.web.model.mail.server.MailServer.connect() bci:427 line:514 (Interpreted frame)
* com.smampi.web.model.mail.server.MailServer$1.closed(javax.mail.event.ConnectionEvent) bci:10 line:593 (Interpreted frame)
* javax.mail.event.ConnectionEvent.dispatch(java.lang.Object) bci:55 line:96 (Interpreted frame)

スレッド 22792 は、com.smampi.web.model.mail.server.MailServer.connect 行 514 からメール サービス接続を実行しようとしています。これは、com.smampi.web.model.mail.server.MailServer$1.closed から呼び出されています。そのために、別のスレッドがガベージ コレクションを停止するのを待っているように見えます。そのため、新しいスレッドにメモリを割り当てて、「startTLS」(プレーン テキスト リンクを暗号化されたリンクにアップグレードするため) を実行できるようになります。メールサービス接続を行うことができます。

それは何か光を当てますか?

于 2011-10-04T14:39:52.607 に答える
0

WAITING状態のスレッドがたくさん(数千?)あります。さまざまなスレッドの状態については、こちらをお読みください:http: //download.oracle.com/javase/1,5,0/docs/api/java/lang/Thread.State.html

これは問題だ。アプリが非常に多くのスレッドを作成し、それらを破壊しない理由を見つける必要があります。

「JavaMail-EventQueue」と呼ばれるスレッドもたくさんあります。郵送のライフサイクルが完了していない理由を調べてください。JavaMailの使用にいくつかのロギングステートメントを追加すると、定期的に完了しないアクションが見つかる可能性があります。

于 2011-10-04T13:32:15.457 に答える
0

SSL コンテキストを確立しようとしているスレッドがたくさんあります。

「JavaMail-EventQueue」デーモン prio=10 tid=0x00007f9f10416000 nid=0x54c6 モニター エントリを待機中 [0x00007f9e3e92d000]
   java.lang.Thread.State: BLOCKED (オブジェクト モニター上)
    sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:255) で
    - ロック待ち (java.lang.Object)
    sun.security.provider.NativePRNG$RandomIO.access$200(NativePRNG.java:108) で
    sun.security.provider.NativePRNG.engineNextBytes (NativePRNG.java:97) で
    java.security.SecureRandom.nextBytes (SecureRandom.java:433) で
    - ロックされた (java.security.SecureRandom)
    java.security.SecureRandom.next (SecureRandom.java:455) で
    java.util.Random.nextInt (Random.java:189) で
    com.sun.net.ssl.internal.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:82) で
    javax.net.ssl.SSLContext.init(SSLContext.java:248)
    com.sun.mail.util.MailSSLSocketFactory.newAdapteeFactory(MailSSLSocketFactory.java:130) で
    - ロック済み (com.sun.mail.util.MailSSLSocketFactory)
    com.sun.mail.util.MailSSLSocketFactory.(MailSSLSocketFactory.java:119) で
    com.sun.mail.util.MailSSLSocketFactory.(MailSSLSocketFactory.java:94) で
    com.sun.mail.util.SocketFetcher.startTLS(SocketFetcher.java:413) で
    com.sun.mail.iap.Protocol.startTLS (Protocol.java:377) で
    - ロック済み (com.sun.mail.imap.protocol.IMAPProtocol)
    com.sun.mail.imap.protocol.IMAPProtocol.startTLS (IMAPProtocol.java:734) で
    com.sun.mail.imap.IMAPStore.login(IMAPStore.java:676)
    com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:643) で
    - ロック済み (com.sun.mail.imap.IMAPStore)
    javax.mail.Service.connect(Service.java:295)
    - ロック済み (com.sun.mail.imap.IMAPStore)
    com.smampi.web.model.mail.server.MailServer.connect(MailServer.java:514) で
    com.smampi.web.model.mail.server.MailServer$1.closed(MailServer.java:593) で
    javax.mail.event.ConnectionEvent.dispatch(ConnectionEvent.java:96) で
    javax.mail.EventQueue.run(EventQueue.java:134) で
    java.lang.Thread.run(Thread.java:662) で

オペレーティング システムで利用可能なエントロピーの量が非常に少なくなる (つまり、OS が高品質の乱数を生成できなくなる) SSL のセットアップ中に (サーバーとして、またはクライアントとして) サーバーが不可解に遅くなるのをよく見てきました。もっと)。

/proc/sys/kernel/random/entropy_avail使用内容を表示してみる

cat /proc/sys/kernel/random/entropy_avail

これは、現時点で OS が提供できるランダム データの量を示しているはずです。通常は、少なくとも数百になるはずです。一貫して 0 または非常に近い場合は、問題があり、エントロピーの別のソースを導入する必要があります。

また、逆の場合もあります。その接続の反対側では、エントロピーの収集に問題があり、応答が遅い可能性があります。

于 2011-10-04T13:28:09.530 に答える
0

私の推測では、暗号化されたトラフィックを予期しないサービスに対して TLS (暗号化) を誤って通信しようとしたため、適切な応答を待機しているスレッドが多数存在しているのでしょう。

このサービスに正しいポート番号を使用していますか?

于 2011-10-17T23:09:58.747 に答える