2017-04-06 262 views
0

PDFRendererのrenderImageWithDPIメソッドを使用して、さまざまなPDFファイルから画像をレンダリングしようとしています。特定のPDFでは、一部のページでは、ライブラリレンダラーの動作が異なります。PDFBox 2の異常なメモリ消費

レンダリング自体が他の類似したページより長くなり、メモリ消費量が異常に大きな値に達する:プロセスによって消費されるメモリは、1〜2秒ごとに約50MBになり、5GBのRAM renderImageWithDPI中にアプリケーションプロセスによって消費されます。スレッドがrenderImageWithDPIを終了すると、メモリ消費量はほぼ即座に1.5〜2 GBに低下します。メモリ消費量が高いため、Javaヒープ・スペース例外がスローされることがあります。

このようなページは、同じ幅、高さ、およびディスクサイズで、他のものと目に見える違いはありません。レンダリングは250 DPIで行われ、 ImageType RGBとなります。また、アプリケーションは「-Dsun.java2d.cmm = sun.java2d.cmm.kcms.KcmsServiceProvider」パラメータを使用して実行されています。

これはメモリリークまたは予期される動作ですか?また、誰かが2GBのメモリを吸い取ってレンダリングするのに1分かかり、他のページが数秒でレンダリングされるのをなぜ説明できるのでしょうか?

+0

問題のPDFを共有できますか? – mkl

+0

メールアドレスを教えて、Googleドライブのリンクを送信することができますか? – Cristian

+0

かもしれないが、おそらく複雑なパターン...おそらくsnafu dot deでtilmanにリンクを送ってください。 –

答えて

0

PDFを分析すると、34ページには10000個以上のXObject要素があり、ほとんどすべてがCMYKイメージです。 the PDFDebugger command line app、34ページ、リソース、XObjectを参照してください。それらを変換することはJavaでは非常に高速ではありません。メモリ使用量は、これらのイメージをキャッシュする可能性が高いためです。次回ページが表示されたら、はるかに高速に処理されることがわかります。キャッシュを無効にすることは、FAQに示されています。

このオプションを使用すると、スピードが向上します(89秒ではなく21秒)。-Dorg.apache.pdfbox.rendering.UsePureJavaCMYKConversion=true。しかし、画質は非常にわずかに異なる場合があります。PDFBOX-3569を参照してください。

+0

私たちは、よくある質問と最後に言及したすべてのオプションを試してみましょう。画像品質は実際に重要です。この問題を理解していただきありがとうございます。 – Cristian

+0

https://issues.apache.org/jira/browse/PDFBOX-3569を読んだ後、KcmsServiceProviderとUsePureJavaCMYKConversionはレンダリングを遅くするので、同時に使用しないでください。私たちはKcmsServiceProviderだけに固執します。なぜなら、1つのpdfなどに応じて2つの間を切り替えることができないからです。 – Cristian

+0

私の場合、両方を使うとより速くなりました。 –