問題タブ [portal-server]

ベースプロバイダーを拡張してベースレイアウトなどを操作できると思いますが、デフォルトプロバイダーのJavaソースコードを入手できる場所はありますか？これらのデフォルトプロバイダーのクラスはどこにコピーされますか？ベースコンテナーを拡張することで操作できるもののリストは何ですか？オーバーライドできるメソッドに関する包括的なドキュメントはありますか？

どうもありがとうございました!!

よろしく、Vivek

IBM JDK 1.4.2 を使用する AIX 上の Websphere Portal Server 5.1 で、かなり複雑なアプリをポートレットとして実行しています。私たちの実稼働システムでは、詳細な GC ログに奇妙な動作が見られます。通常の動作の期間の後、システムは急速に大きなブロックの割り当てを開始できます。システムは、各 GC を完了するために 1000 ミリ秒を超える時間を費やし始めますが、ブロックが非常に迅速に割り当てられるため、割り当ての失敗の間に 30 ミリ秒のギャップしかありません。

• 各割り当ての失敗は、前回よりわずかに整数 x 1024 バイトだけ大きくなります。たとえば、5 MB があり、しばらくすると 5 MB + 17 * 1024 になる場合があります。
• これは最大 10 分間続くことがあります。
• ブロックは、停止する前に最大 8 ～ 14 MB のサイズになる傾向があります。
• これはクアッドコア システムであり、もう一方のコアが GC を完了するのを待っている 3 つのコアで GC を実行する時間の 95% 以上を費やしていると思います。10分間。ああ。
• 明らかに、この時点でシステムのパフォーマンスは低下します。
• JSF、休止状態と JDBC、Web サービス呼び出し、log4j 出力などがあります。

これは、アプリケーション コードではなく、インフラストラクチャのようなものである可能性が高いと解釈しています。ループ内の不適切な文字列連結である場合、1024 のブロックよりも不規則な増加が予想されます。StringBuffer または ArrayList の増加である場合、ブロック サイズが 2 倍になることがわかります。成長により、ログのバッファリングなどを考えさせられます。私たちのアプリでは、14 MB どころか 1 MB を割り当てるものも思い浮かびません。今日、ディスクにフラッシュされる前にメモリにログを記録する方法を探しましたが、この GC スラッシング期間のログ ステートメントの量はどこにもありませんでした。 MB範囲。

明らかに問題は、ガベージ コレクションではなく過剰なメモリ割り当てにあり、ガベージ コレクションは追いつくために最善を尽くしています。何かが大きなブロックを割り当て、それを非常に小さい増分で非効率的に拡張しようとしています。

システムに負荷がかかっているときに、これらすべてを引き起こしている可能性のあるアイデアはありますか? Portal Server で似たようなものを見た人はいますか?

注: 興味のある人にとっては、原因は時折ではあるが巨大なデータベース クエリにあるように見え始めています。原因は、Hibernate または JDBC ドライバーのいずれかにあるようです。