1

WSO2 BPS 3.6.0 を使用すると、時折 OutOfMemoryError が発生し、サーバーが停止しました。ヒープ分析の後、次のことが疑われます。

ビジネスアイテムの状態が変わらなくなるまで、(Web サービスを使用して) 定期的に情報を検索するプロセスがいくつかあります。しばらくすると、一部のプロセス インスタンスに多くのイベント (数千、約 10k) が発生する場合があります。Carbon コンソールでインスタンス情報を表示しようとすると、ロードされたデータ (インスタンス アクティビティ) によって OutOfMemoryError が発生し、サーバー (6GB RAM を搭載) がドロップされる可能性があります:(

回避策として、DB ルックアップを使用します。

select ode_event.event_id, ode_event.detail, ode_event.tstamp, ode_event.type,
ode_event.instance_id, ode_event.process_id,
ode_scope.scope_name
from ode_event, ode_scope where ode_event.instance_id=18204 and 
(ode_event.scope_id = ode_scope.scope_id);

ただし、すべてのビジネス ユーザー (プロセス オーナーを含む) がデータベースに直接アクセスできるようにすることは非常に悪いことだと考えています。

アクティビティを表示する (より良い) 方法/クエリはありますか? 改善/機能を配置する (ページ付けされたアクティビティをロードする) 正しい github プロジェクトはどれですか?

編集：

ソース コードを見ると、この「動作」は Apache-ODE 実装から継承されています (スコープとイベントのリスト全体をメモリに積極的にロードします)。

4

1 に答える 1

0

これが現在の動作です。ページネーションを追加することで改善できます。しかし、これが理由であり、優先されません。

個々の DB テーブルのサイズを確認すると、イベント テーブルがほとんどのスペースを消費していることがわかります。これは、プロセス デバッグ レベル イベントがデフォルトで有効になっており、多くのイベントが生成されるためです。これらのイベントは開発時には役立ちますが、本番環境になると無効にする必要があります。そうしないと、本番リソース (CPS、メモリ、DB スペース) が無駄になります。BPS エンジン全体のパフォーマンスに影響します。

一般的な推奨事項を次に示します。

大規模で長時間実行されるプロセスがある場合は、監視する必要がある選択したスコープに対してのみイベントを有効にすることをお勧めします。（何も持てない場合はさらに良いです。:)）

また、データベースから古いデータを継続的にクリーンアップする必要があります。(スクリプトについては BPS ドキュメンテーションをグーグルで検索してください) そうしないと、DBA が近い将来実行するのに十分なスペースがないと DBA に文句を言われるでしょう。:)

プロセスの実行にイベントは必要ありません。それできれいにできます。あなたのシナリオでは、アクティブな BPEL プロセスの OLD イベントをクリーンアップしてもよろしいですか? 例: 1/2/7.. 日より古いイベントを消去します。?. これにより、問題がある程度解決されます。

于 2016-12-17T02:57:43.770 に答える