これは説明が難しい、単なる単純な答えではうまくいかないが、それは価値があると思った。 Javaアプリケーションとやりとりする長いPythonジョブを遅くするかもしれないことに興味があります。アプリケーションは時間の経過と共に減速する - Java + Python
私たちは、デジタルオブジェクトを格納するソフトウェアFedora Commons（FedoraのOSと混同しないでください）と呼ばれるかなり複雑で頑強なWebアプリケーションを実行するTomcatのインスタンスを持っています。さらに、Celeryで長いバックグラウンドジョブを実行するPythonミドルウェアがあります。 1つの特定の仕事は、本の各ページに大きなTIFFファイルがあり、さらに小さなPDF、XML、およびメタデータファイルがある400以上のページブックを取り込むことです。 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'
私たちは、このVM上のRAMの12GBで作業しています。
私は、この動作につながる可能性のある要因の数が、チャートからの言い訳を許していることを認識しています。しかし、私たちはFedora CommonsとPythonミドルウェアをしばらく使っており、ほとんど成功しています。この遅れは、あまりにもあなたについても間違っているかもしれませんが、あなたの時計はあまりにも疑わしいJava /ガベージコレクションに関連すると感じるかもしれません。
これ以上の掘り下げについての助力やアドバイスはありがたいです！
は、jython経由でjvm上で実行されているpythonの部分ですか？それとも別のプロセスですか？後者の場合は、まず機械全体のどの部分が減速するか、つまりJavaかPythonのどちらであるかを特定する必要があります。 – the8472
Psi-ProbeをFedora Commons Tomcatインスタンスに追加してみてください。仕事の完了時のみを見ることで、Fedora Commonsのどのコンポーネントをインストールして減速の原因となっているのかを知ることはできません。問題は、Fedora、gSearch、Solr、またはDjatokaです。 Psi-Probeを追加することで、サーブレットレベルでパフォーマンスをチェックし、問題をより正確に特定することができます。 https://psi-probe.github.io/psi-probe/ –
これは素晴らしいです、ありがとう@RickSarvas！私は、これらのコンポーネントの多くが、私たちが使用していないIslandoraと手を携えていると認識しています。しかし、Psi-ProbeはTomcatには一般的に聞こえるので、非常に便利かもしれません。提案を感謝します。 – ghukill