問題タブ [ibm-jvm]

Java 1.6、JVM IBM J9 2.6 (appserver に同梱) を使用して、Websphere Application Server 8.5.0 にデプロイされたアプリケーション内で組み込みの Cassandra 1.2.18 を実行しています。起動も問題なく、問題なく使えています。これは、Cassandra クラスター内の唯一のノードです。

ただし、ノードを廃止しようとすると、Cassandra は MessagingService をシャットダウンしようとして、ハングします。デバッグ中、サーバー自身の IP、ポート 7000 (Cassandra がノード間通信に使用) をリッスンして、開いている ServerSocket を閉じようとしていることがわかります。

これにより、Cassandra が正しくシャットダウンされなくなり、サーバー全体が正常にシャットダウンされなくなります。おそらく非常に特殊な状況だと思いますが、以前にCassandra / Websphereで同様のことを経験した人はいますか、または私よりもServerSocketの経験が豊富な人は何が起こっているのかを示唆できますか?

次のコードがあります。

これをコンパイルして、ローカル マシン (JRE 1.7_0_71、Win 7 64 ビット、4 コア、8 GB RAM) の Oracle JVM で実行すると、実行に約 3.5 秒かかります。

IBM JVM (j9、java 7、ビルド pap6470_27sr2-20141101_01(SR2)) を搭載した AIX マシン (POWER7+、16 コア、64GB RAM) で実行すると、実行ごとにほぼ 9 秒で結果が得られます。

どこで捕まえることができますか？

Java API を介して clearquest データベースにアクセスする Web アプリケーションを開発しています。Tomcat の下で正常に動作します。次に、そのアプリケーションを WebSphere Application Server 8.5.5 に変換する必要があります。Clearquest への最初の呼び出しで、アプリケーションと JVM が終了します。

WAS で Clearquest API ライブラリを定義する方法と、Java API で使用される Clearquest DLL へのアクセスを確保する方法を教えてください。

ありがとう！ベルトルト

IBM jvm は初めてです。OutOfMemoryError (つまり -XX:+HeapDumpOnOutOfMemoryError) によって発生したヒープ ダンプを確認すると、同じ瞬間に複数のダンプ (.phd ファイル) が生成されることがよくあります。例：

heapdump.20141111.011601.8944.0003.phd heapdump.20141111.011601.8944.0005.phd heapdump.20141111.011601.8944.0007.phd heapdump.20141111.011601.8944.0009.phd

これらを読んでみると、jvm は 2014 年 11 月 11 日午前 1 時 16 分 1 秒に pid #8944 の 4 つのヒープ ダンプを生成しました。

では、なぜ 4 か。そして、なぜ同じ秒で 4 なのですか? [同じ秒に実際に 4 つの OOM が発生したため、推測しました]

これらのダンプを確認したところ、かなり同一であることがわかりました。ダンプ 2、3、および 4 は情報を追加しませんが、混乱してドライブがいっぱいになるだけです。

ヒープ・ダンプを 1 つだけダンプするように IBM jvm を構成するにはどうすればよいですか? ヒープ ダンプ間の「待機時間」を構成できますか?

ありがとう

XSLT を使用して変換を行っているときに、パフォーマンスの問題に直面しています。

提供されたデータを変換するには、約 13 ～ 14 秒かかります。

その間、コンソールログに次のような警告があることに気付きました

[ERR 0635] 生成された関数の一部が JVM メソッドのサイズ制限を超えたため、自動的に小さな関数に分割されました。Process または Compile コマンドに「splitlimit」オプションを使用するか、「http://www.ibm.com/xmlns/prod/xltxe- j/split-limit ' トランスフォーマー ファクトリ属性。

そのエラーを見て、以下に示す方法で属性を設定しようとしました。

ここから取った1500番。

しかし、負荷テストが実行されたときにこれが本当に役立つかどうかはよくわかりません。

トランスフォーメーションでパフォーマンスを向上させるにはどうすればよいか、誰かが教えてくれますか?

基盤となる JVM は Websphere App Server にあります。

WebSphere アプリケーションが z/OS でハングした場合、原因を見つけるためにどのような手順を実行する必要がありますか?

ここまでで、ヒープ ダンプ、Java コア、およびシステム ダンプを取得しました。

どのスレッドもデッドロックしておらず、メモリの問題もなく、スレッドが豊富にあるようにも見えません。(ごく普通の 50 までです。)

アプリケーション全体にアクセスできません。つまり、Web ページに接続しようとすると、ハングしてタイムアウトになります。

これを引き起こすことによって何ができますか？CPU 使用率の高いイベントを検討していますが、それをさかのぼって確認する方法がわかりません。

これと同様のエラー メッセージが 30 回表示されます。

「ハングした」スレッド自体には実際のパターンはないようです。これらは通常のアクティビティであり、ハングすることはありません。

Websphere 8.5 でアプリケーションを実行していますが、この特定の JVM のヒープ メモリ サイズが過去に増加したことを知っています。コミットされたメモリは現在 5.6 GB ですが、ダイレクト バッファ メモリに関連するメモリの問題が発生しており、サイズも変更する必要があります。この問題は監視料金で発生していることがわかるため、直接メモリのサイズはわかりません。

私の質問は次のとおりです。Javaヒープメモリサイズに応じたダイレクトメモリの正しいサイズ設定はありますか? X GBごとに少なくともX MBとしましょう。

XX:MaxDirectMemorySize オプションのデフォルト値は?

このオプションを変更する前に、他に何を考慮する必要がありますか?

「 loa」が 100% で構成されていても問題ありませんか? 他の領域に空きメモリがあります。それが問題である場合、適切な解決策は何ですか? gc type="スカベンジ"

JVMの詳細