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