1

私の会社では、最近メモリの問題が発生しています。私たちが行ったことの 1 つは、JRUN のヒープ サイズを増やしたことですが、現在、いくつかの副作用に気付いています。

そのうちの 1 つは、画像を処理する CFX タグです。それを使用すると、時々与えられたファイルを読み込めません。現在の考えでは、画像を処理するには、画像全体をメモリにロードする必要があります。全体を保存するには200 MB以上のメモリが必要な大きなファイルでのみエラーが発生するようです。

私が知りたいのは、Coldfusion が CFX タグの読み込みと実行をどのように処理するかです。特に CFX タグは C++ で記述されているため、必ずしも Coldfusion ヒープを使用するとは限らないと思います (Java データのみを格納するため)。また、何かを処理するときにヒープ スパイクが発生することはありません。

主な問題は、CFX がどのように実行されるかということだと思います。CFX は JRUN の下でスレッドとして実行されますか、それとも独自のユーザー空間で実行されるネイティブ Windows プロセスが作成されますか? また、JRUN で実行する場合、実行時にどのメモリ領域を使用し、それを監視する方法はありますか?

4

2 に答える 2

1

32ビットプロセスを実行している場合、2ギガにしかアクセスできないと思います。ヒープが1ギガの場合、非ヒープメモリは60〜200メガグラム以上になり、プロセスが実行されているスレッドごとにメモリを追加します（クラスター化すると、スレッドの数がさらに増えます）。プロセスに残っているメモリスペースの量。さらに、私が理解しているように、さまざまなDLLがメモリ範囲の上部のどこかでメモリ空間にマップされます。つまり、画像処理タグが連続したメモリの非常に大きなブロックを割り当てようとすると（ヒープの外が私の推測です） 、そのための単一のブロックは残っていません。この答えはやや推測的なものなので、福音とは見なさないでください。ただし、プロセスのメモリマップを視覚化できるプログラムを検討する価値があるかもしれません。

于 2012-05-19T06:07:56.843 に答える
1

CFX は確実に JRUN の下でスレッドとして実行され、データは JNI レイヤーを介して Java から C++ にマーシャリングされます。そうです、デフォルトのファイル open/read (カバーの下) を使用してイメージ全体をヒープにロードし、バイナリを C++ タグに渡します。大きな画像ファイル (または一般的には大きなファイル) の処理は、常に CF の問題であると私は考えています。パフォーマンスを向上させるために提供される画像処理用の「純粋な Java」ソリューションがいくつかあります。または、ファイル名とパスをシェルに渡して個別に実行される「imagemagik」などを使用することもできます。それが私の見解です。

于 2012-05-18T18:25:19.233 に答える