古いアプリケーションのアーカイブを担当するアプリケーションがあります。このアプリケーションは一度に多数のアプリケーションを実行するため、一度に数日間実行する必要があります。
私の会社がこれを開発したとき、彼らはそれに対してかなりのパフォーマンステストを行い、これからまともな数値を得ているようでしたが、私は最近顧客のためにアーカイブを実行していて、それは本当に遅いようで、パフォーマンスは実行時間がさらに長くなります。
jconsoleで監視しているので、まだ十分なメモリが使用可能であり、縮小していないように見えるため、メモリリークは発生していないようです。
しかし、ガベージコレクションが発生してそれをクリアするまで、サバイバースペースとヒープの保有世代が非常に迅速にいっぱいになる可能性があることに気付きました。これはかなり頻繁に発生しているようですが、それが明らかな原因であるかどうかはわかりません。徐行。
アプリケーションは現在7日間3時間実行されており、jconsoleによると、コピーガベージコレクション（772、611コレクション）の実行に6時間、marksweepコンパクション（145,940コレクション）の実行に12時間25分を費やしました。
これはガベージコレクションにかなりの時間を費やすように思われます。誰かが以前にこのようなことを調べて、これが正常かどうかを知っているかどうか疑問に思っています。
編集
ローカル処理は遅いようです。たとえば、xpathを使用してSOAPエンベロープからxmlを抽出するのに5秒かかったログの一部を調べて、ルートタグとともに文字列バッファに追加します。これですべてです。します。これは本番環境で実行されているため、まだプロファイルを作成していません。データをネット経由でプルダウンするか、開発環境に大規模なテストベースを設定する必要があります。
JavaHotSpotクライアントVMバージョン10.0-b23の実行
本当に必要なのは高スループットであり、特定のガベージコレクションパラメータを設定しておらず、デフォルトが何であれ実行されます。どのコレクターが使用されているかを見つける方法がわかりませんか？
修理
プロファイラーを実行することになり、速度低下の原因は、ステータスボックスから行を絶えずトリミングしてログステートメントを出力するコードであることが判明しましたが、これはかなりひどく行われました。ガベージコレクションは、実際の原因ではなく、ステータステキストをメモリに絶えずコピーすることによる症状であると考えるべきでした。
乾杯みんな。