これは説明するのが難しいものであり、単一の単純な答えには期待できませんが、試してみる価値はあると思いました. Java アプリケーションと対話する長い Python ジョブを遅くする可能性があるものに興味があります。
Fedora Commons (OS の Fedora と混同しないでください) と呼ばれる、かなり複雑で堅牢な Web アプリケーションを実行する Tomcat のインスタンスがあります。これは、デジタル オブジェクトを格納するためのソフトウェアです。さらに、 Celeryで長いバックグラウンド ジョブを実行する python ミドルウェアがあります。特定のジョブの 1 つは、400 ページ以上の本を取り込むことです。本の各ページには、大きな TIFF ファイルがあり、次にいくつかの小さな PDF、XML、およびメタデータ ファイルがあります。10 ～ 15 分かけて、これらのファイルから派生物が作成され、Fedora の単一のオブジェクトに追加されます。
私たちの問題: 1 冊の本を摂取する過程で、Java アプリ Fedora Commons のデジタル オブジェクトにファイルを追加すると、非常に一貫して予測どおりに遅くなりますが、その方法や理由がわかりません。
取り込み速度のグラフが役立つかもしれないと思いましたが、Java の経験が豊富な人が認識できる一般的なメモリ管理パターンとは異なる可能性があります。
左上のグラフは、大きな TIFF のタイミングをとっており、JP2 に変換されてから Fedora Commons に取り込まれています。左下は非常に小さな XML ファイルで、派生物は作成されておらず、同様に取り込まれています。ご覧のとおり、減速曲線の傾きはほぼ同じです。右側は、これら 2 つのプロセスを一緒にグラフ化したものです。
Java (GC) でのガベージ コレクションについて学び、さまざまな構成を試してみましたが、スローダウンにはあまり効果がありませんでした。それが役立つ場合は、Tomcatに渡すいくつかのメモリ構成を次に示します（テールエンドはほとんど診断用であると私は信じています）：
JAVA_OPTS='-server -Xms1g -Xmx1g -XX:+UseG1GC -XX:+DisableExplicitGC -XX:SurvivorRatio=10 -XX:TargetSurvivorRatio=90 -verbose:gc -Xloggc:/var/log/tomcat7/ggc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC'
12GBこの VM の RAM を使用しています。
この行動につながる可能性のある要因の数は、しゃれを許して、チャートから外れていることに気づきました。しかし、私たちはかなり長い間 Fedora Commons と Python ミドルウェアを使用してきましたが、ほぼ成功しています。この速度低下は、時計を設定することもできますが、Java / ガベージ コレクションに関連していると疑わしく感じますが、それについても非常に間違っている可能性があります。
さらに掘り下げるためのヘルプやアドバイスをいただければ幸いです。
