WildflyでJavaアプリケーションのリモートデバッグスタックを分析する

Question

WildFlowインスタンスには、36コアサーバー上で実行される単純なJava Restアプリケーションが含まれています。アプリケーションには、バックグラウンドで実行されているデフォルトのジョブはありません。ユーザーの要求（1日あたり< 500）に応答します。

私たちの管理者は、今日の奇妙な行動に気付きました。 wildflyのインスタンスは、午前2時以降、サーバーの全容量を使用していました。その時点では、ユーザーはアプリケーションを使用できませんでした。夕方前の最後のユーザーアクションと今朝の最初のユーザーアクションとの間にログファイルはありません。

私はEclipseでリモートデバッガを起動しました。実際にWildflyによって開始されたすべてのスレッドが実際に何をしているのか理解したいと思いますか？

1. Thread[MSC service thread 1-xx](Running) 68エントリ。それらのスレッドは何ですか？パフォーマンス/キャパシティ・カバレッジに影響を与えている可能性はありますか？これらのスレッドの数を制限できますか？私はそれをすべきか？
2. Deamon Thread [weld-worker-xx](Running) 25件。
3. Thread[default task-x](Running) 8 entries。これらはおそらく実際のユーザータスクですか？
4. Thread[XNIO-1 I/O-x](Running) 2エントリ。データベースへの入出力？または、ログe.q.などの任意のファイル？
5. Daemon Thread [Transaction Reaper](Running)
6. Deamon Thread [Transaction Reaper Worker 0](Running)
7. Thread [Periodic Recovery](Running)
8. <not responding>たくさんの
。それは実際にはどういう意味ですか？スレッドは実行されていますが、私は一見を持っていませんか？一般的に

Answer 1

、あなたがwildfly内のスレッドサブシステムを見ているかもしれません：

https://docs.jboss.org/author/display/WFLY8/Threads+subsystem+configuration

このパフォーマンスチューニングガイドは、スレッドとスレッドプールを理解するためにも非常に便利です：

http://www.mastertheboss.com/jboss-server/jboss-performance/wildfly-performance-tuning

あなたが言及するスレッドの種類は、AFAICT：

です

MSCスレッドは、モジュラサービスコンテナスレッドです。彼らはここで設定を経由して制限することができます。https://issues.jboss.org/browse/MSC-144（-Dorg.jboss.server.bootstrap.maxThreads）

デフォルトのスレッド：さまざまなタスクのためのスレッドサブシステムで定義されたプールでのI/Oスレッド。

XNIOスレッド：Undertowは、bounded-queue-thread-poolを使用してWorkerスレッドを作成するためのXNIO APIに依存しています。 https://developer.jboss.org/thread/241230?start=0&tstart=0 - ここではいくつかの良いパフォーマンスチューニングのヒント：http://www.mastertheboss.com/jboss-server/jboss-performance/wildfly-performance-tuning

溶接ワーカースレッドはCDIの実装が使用するスレッドであり、そのように設定することができます。http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html#_thread_pool_configuration。溶接は、各展開（https://issues.jboss.org/browse/WFLY-4653）のスレッドプールを維持し、WF9以降はスタンドアロンで構成可能です。XML

取引リーパーと労働者は、JTAトランザクションやタイムアウトなどを監視する責任があるhttp://www.mastertheboss.com/jboss-server/jboss-configuration/configuring-transactions-jta-using-jboss-as7-wildflyhttp://www.hhutzler.de/blog/a-deeper-dive-into-transaction-timeouts-with-jee7wildfly-and-oracle-rac/

Reriodic回復スレッド：システムクラッシュ定期的な回復スレッドがXAの回復使用する必要がありますし、XAは、これをコミットすることを約束した後ユーザーの介入を必要としません。 http://www.hhutzler.de/blog/a-deep-dive-into-2-phase-commit-with-wildfly-and-oracle-rac/