2016-11-04 12 views
1

私たちは、イベントを送信する場所からAPIマネージャ1.10.0とともにDAS 3.1.0を実行しています。イベントはDASの受信者で受信され、ストリームに送信され、実行プランによって処理され、結果は2つのパブリッシャに送信され、RDBMSに送信されます。 DASへのイベント数は約30-40イベント/秒です。WSO2 DASパフォーマンスがゆっくりと低下する

最初に開始されたとき、DASはリアルタイムでRDBMSにイベントを出力することができますが、非常にゆっくりと「遅れている」ことがわかります。 1時間ほど後には、「遅れ」が15〜30秒になり、数時間後に「遅れ」が約20分後、4-5時間後には、もう処理されるイベントはありません(われわれはこの時点で受信イベント・データベースにデータを保管してください)。

DASはまだ起動していますが、どこにでもエラーログはありませんが、明らかに、指数関数的な「バックオフ」マルチプレイヤーではなくリアルタイムでデータを出力したいと考えていますケース。

設定上の是正策はありますか?それは何とか蓄積する記憶問題かもしれませんか? (メモリ使用量のいくつかの出力を添付)。私たちは、メモリが時間をかけて蓄積され始める見ることができますので、我々は、最適化するために、JVMの設定を変更してみました:

-Xms3072m -Xmx3072m -XX:MaxPermSize=1024m -XX:NewSize=256m -XX:MaxNewSize=614m -XX:SurvivorRatio=10 -XX:-DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+AggressiveOpts -XX:+UseStringCache -XX:+OptimizeStringConcat 

我々はまた、「長持ち」それは、少なくとも作られたいくつかのパフォーマンスの設定を変更しようとしたが、それでも同じ結果:

データブリッジ-config.xmlの:

<workerThreads>3</workerThreads> 

<maxEventBufferCapacity>1</maxEventBufferCapacity> 

<eventBufferSize>2000</eventBufferSize> 

<clientTimeoutMin>30</clientTimeoutMin> 

データ剤のconfig.xml:

<QueueSize>1024</QueueSize> 
<BatchSize>100</BatchSize> 
<CorePoolSize>2</CorePoolSize> 
<SocketTimeoutMS>30000</SocketTimeoutMS> 
<MaxPoolSize>2</MaxPoolSize> 
<KeepAliveTimeInPool>20</KeepAliveTimeInPool> 
<ReconnectionInterval>30</ReconnectionInterval> 
<MaxTransportPoolSize>250</MaxTransportPoolSize> 
<MaxIdleConnections>250</MaxIdleConnections> 
<EvictionTimePeriod>5500</EvictionTimePeriod> 
<MinIdleTimeInPool>5000</MinIdleTimeInPool> 
<SecureMaxTransportPoolSize>250</SecureMaxTransportPoolSize> 
<SecureMaxIdleConnections>250</SecureMaxIdleConnections> 
<SecureEvictionTimePeriod>5500</SecureEvictionTimePeriod> 
<SecureMinIdleTimeInPool>5000</SecureMinIdleTimeInPool> 

解析・イベント・シンク-config.xmlに:悲しげに助けにはならなかった

<QueueSize>1024</QueueSize> 

<maxQueueCapacity>1</maxQueueCapacity> 

<maxBatchSize>128</maxBatchSize> 

<WorkerPoolSize>5</WorkerPoolSize> 

。ヒントやヒントは非常に高く評価されています。

Memory usage. Server was restarted at 3PM, 8PM and 7.40AM because it was lagging too far behind

メモリ使用量。サーバーは3PM、8PM、および7.40AMで再起動されました。遅すぎるためです。

答えて

0

あなたの設定がDASの推奨事項と少し違っているようです。 DAS performance tuning guideに従ってください。改善が得られたかどうかを確認してください。

+0

お返事ありがとうございます。私たちはパフォーマンスチューニングガイドでさまざまなオプションを試しましたが、悲しいことに行動の変化はありませんでした。上述したように、私たちが上記のようにオプションを調整したとき、私たちは少なくとも長く続きましたが、それと同じ長期的な振る舞いです。 –

0

この場合、データベースの書き込みパフォーマンスを確認してください。たとえば、一部のデータベースサーバーでは、レコードにblobフィールドがある場合、レコード数が増えると挿入速度が遅くなります(DAS分析テーブルではblobフィールドを使用してフィールド値をエンコードし格納します)。したがって、データベース操作をプロファイルして、それらが実際に遅いかどうかを確認することが最善です。その後、DBMS固有のオプトマイゼーションを行い、ブログストレージのパフォーマンスを向上させることができます。

乾杯、 Anjana。

+0

さらに詳しい情報。私たちはテストし、問題が着信イベントを処理することであると結論付けました。問題は(巨大な遅れなしに)始まると、私たちのDASの受信機にイベントが表示されません。また、パフォーマンスが低下した場合、再起動せずに「回復」する方法はありません。 1日分のイベントを処理しても、DASデータベースのすべてのイベントをパージしても、受信イベントが受信イベントとして表示されるまでにはまだ大きな遅れがあります。これはさらなる手がかりを与えますか? –

関連する問題