Java アプリケーションで jstack コマンドを実行しようとしています。アプリケーションはかなり大きく、約 4 GB のメモリを占有する jboss AS 内で実行されます。OSはWindows Server 2003 Standard版です。「このコマンドを処理するのに十分なストレージがありません」というエラーが表示されるたびに。十分な RAM、16 GB、およびディスク容量があります。それで、何かアイデアはありますか？
質問する
27209 次
5 に答える
44
私は最近Win2008r2でこれに遭遇し、理解するのに時間がかかったので、私の解決策を共有したいと思いました。psexec -sに関するRobのコメントは、私にとってそれをしたものです。
Vista以降では、ユーザーコンテキストが原因で、jstackはサービスに対して機能しないようです。それは記憶とは何の関係もありません。これは、mstscで/adminまたは/consoleスイッチを使用しない限り、リモートデスクトップを介して2003年にこの問題が発生したのと同じ理由だと思います。Vistaの時点では、セキュリティの強化がおそらくそれを破ったものです。
cmdウィンドウからアプリを起動しても問題なく動作しましたが、標準インストールのデバッグには役立ちません。Javaデバッグポート（VisualVM、Eclipse、またはほとんどすべてのJavaデバッガーの場合）を有効にするには、アプリを再起動する必要があるため、デバッグをまだ有効にしていない場合は、キャプチャしようとしている状態が失われます。ユーザーの資格情報でサービスを開始しても機能しませんでした。少し驚いていました。しかし、psexec -sはシステムコンテキストからjstackを実行します。これは、魅力のように機能しました。ああ、UACがオンになっている場合は、昇格したcmdプロンプトからpsexecを実行する必要があります。
于 2010-06-11T21:24:46.200 に答える
7
過去に、JVM が Windows 2003 で Windows サービスとして実行されているときに、これを見てきました。
まず、これがTMP ディレクトリに問題があるかどうかを確認します。
次に、jstack (または jconsole などの他のユーティリティ) は、同じセッションで実行されていない限り、ローカル プロセスに接続しません。サービスが特定のユーザーとして実行されている場合、同じセッションにログインすることで接続できる場合があります。リモート デスクトップを使用している場合は、"mstsc /admin" (以前は /console) を使用して接続し、jstack を再度実行してみてください。これで問題が解決しない場合は、TMP ディレクトリが正しく設定されていることを確認してください。
サービスが LocalSystem として実行されている場合、上記の手順はおそらくあまり役に立ちません。LocalSystem と同じセッションにログインする方法があるかどうかはわかりません。
他の方法としては、プロセスをリモート監視用に設定し、(サーバー自体または別のマシンから) jvisualvm を使用してポート経由で接続し、スレッド ダンプを実行することもできます。
于 2009-11-04T22:57:36.710 に答える
3
適度なアプリケーション (1GB) でも、Windows マシンで JStack を実行する際に問題がありました。最終的に、Netbeans を使用してスタックとヒープの分析を行うことになりました。これにより、ダンプ ファイルの解析が大幅に改善されたようです。YMMV。
Netbeans でプロファイリングを試してみてください。非常に優れています。VisualVM はカットダウン NB プロファイラーであり、6u7 に付属していることに注意してください。
于 2009-05-25T23:01:37.643 に答える
2
psexec -s jstack PID >> c:\jstack.log同じマシンで完全に動作します。初めて時間がかかりましたが、ファイルへのリダイレクトオプションを使用して実行すると、数秒で完了しました。
于 2012-08-29T13:29:05.870 に答える
0
これは、基盤となる O/S からのエラー メッセージです。スローされた例外をキャッチする以外に、これに対処するためにコードでできることはあまりありません。非常に制限されているため、Windowsにブーイングします。
于 2010-03-05T19:01:47.020 に答える