0

奇妙な例を共有したいと思います。本番環境では、アプリケーションがOOM例外をスローし、ヒープダンプを取得して分析を開始しました。その後、com.mchange.v2.c3p0.stmt.PerConnectionMaxOnlyStatementCacheインスタンスに問題が見つかりました。このオブジェクトのサイズは、ヒープサイズの約50％です。アプリケーションは数十億のユーザーで実行されており、サーバーは何度もダウンしています。

このアプリケーションはtomcatで実行されており、tomcatコネクタは最大300の同時要求を許可し、以下はc3p0構成です。

jdbc.hibernate.c3p0.minPoolSize=2
jdbc.hibernate.c3p0.maxPoolSize=150
jdbc.hibernate.c3p0.maxIdleTime=0
jdbc.hibernate.c3p0.maxStatementsPerConnection=50
jdbc.hibernate.c3p0.numHelperThreads=6

ヒープ監視ツールから、次のメッセージが表示されます

「org.apache.catalina.loader.WebappClassLoader@0x82f1c58」によってロードされた「com.mchange.v2.c3p0.stmt.PerConnectionMaxOnlyStatementCache」の1つのインスタンスは、72 970 824（57,75％）バイトを占有します。メモリは、「org.apache.catalina.loader.WebappClassLoader@0x82f1c58」によってロードされた「com.mchange.v2.c3p0.stmt.PerConnectionMaxOnlyStatementCache」の1つのインスタンスに蓄積されます。

アドバイスしてください：-このインスタンスがそのような巨大なメモリを使用する理由は何ですか？正しいc3p0構成で実行していますか？負荷の高いアプリケーションに推奨される構成は何ですか？

前もって感謝します

4

3 に答える 3

2

maxStatementsPerConnection=50およびmaxPoolSize=150を設定しました。つまり、ステートメントキャッシュには、ドライバーがステートメントに関連付けるリソースのメモリフットプリントを含め、一度に7500ものオープンステートメントが含まれる可能性があります。ステートメントを準備するためのパフォーマンスコストと比較してメモリのコストが低いという理論に基づいて、基本的にc3p0に大量のメモリを使用するように要求しています。

まず、それはまったく当てはまらない可能性があります。その場合、ステートメントキャッシングは一般的に敗者であり、使用しないでください。maxStatementsとmaxStatementsPerConnectionの両方をゼロに設定してアプリのベンチマークを行い、ステートメントキャッシングのメリットを実際に得ているかどうかをテストする必要があります（まだ行っていない場合）。PreparedStatementオブジェクトで多くの解析と準備をキャッシュするドライバーの場合、ステートメントのキャッシュは大きな助けになります。ただし、キャッシュのメモリフットプリントと、ステートメントを事前にキャッシュすることによるパフォーマンス上の利点との間のトレードオフに直面します。ステートメントのキャッシュがパフォーマンスに役立つとしても、メリットがコストを超えるポイントを超えていることは明らかです。

アプリで準備された150のステートメントのうち、頻繁に使用されるのはいくつですか？使用頻度の低いステートメントがキャッシュから削除され、それらが適切に処理されることを期待して、その数を小さくすることはできますか、できればはるかに小さくすることができますか？または、その数をそのままにして、maxStatementsPerConnectionをグローバルmaxStatements設定（現在使用している暗黙の7500よりも小さい値に設定）と組み合わせることができます。maxStatementsPerConnectionとmaxStatementsを組み合わせると、プールが小さい間、各接続は最大maxStatementsPerConnectionを持つことができますが、プールが大きくなり、メモリフットプリントが危険になると、グローバルステートメント制限により、最近使用されていないステートメントが開始されます。メモリを保持するためにキャッシュからドロップアウトします。

これがお役に立てば幸いです。

于 2012-07-17T22:10:57.507 に答える
-1

高パフォーマンスの接続プールとしてBoneCPを試してみてください。c3p0と Apache DBCP の多くのパフォーマンス指向の問題が解決されます。

于 2012-07-17T08:40:29.433 に答える