KPSA swap handling
Article ID: KB0094521
Updated On:
| Products | Versions |
|---|---|
| TIBCO KPSA - Mobile | - |
| Not Applicable | - |
Description
Resolution:
Description:
============
In KPSA, swapping is used to avoid memory exhaustion. It relies on checkpoints to remove Service Orders from memory and reload them only when necessary. This Solution describes how the swap is handled in KPSA and the main configurable parameters used with it.
Environment:
============
TIBCO® KPSA - Mobile 3.4.x
TIBCO® KPSA - Mobile 3.5.x
TIBCO® KPSA - Mobile 3.6.x
TIBCO® KPSA - Mobile 3.7.x
TIBCO® KPSA - Broadband 3.4.x
TIBCO® KPSA - Broadband 3.5.x
TIBCO® KPSA - Broadband 3.6.x
TIBCO® KPSA - Broadband 3.7.x
Resolution:
===========
1). Prerequisite
A Flow Controller attribute (swapLevel) is used to configure the maximum number of Service Orders allowed in memory before swap is triggered.
By "driver-like order queue" is meant a queue automatically frozen when a certain amount of memory usage is reached (80% by default. Typically drivers, to stop injection and avoid memory exhaustion).
An Order Queue queue out is a temporary place where the Service Order wait a Flow Controller token. It is expected to leave the Order Queue very quickly, therefore it is the worst candidate for swapping.
2). Swap out and swap purge
When an order enters an order queue the order queue may trigger:
- The swap out of the incoming order.
- A local swap purge of the current order queue : orders inside this order queue may be removed from memory.
- A global swap purge on all the queues of the application.
The decision is based on the internal number of Service Orders compared to the allowed value, swap level, and there is three progressive phases.
If above 80 % of the swap level:
- If the order queue is driver-like, the order is swapped out (to remove best candidates for swapping).
- If the order queue is driver-like, a local purge is triggered (to remove previous waiting Service Orders)
- For any queue, if the incoming orders is not enqueued in the queue out, it is swapped out (to remove the Service Order which is going to wait anyway)
Additionally, if above 90 % of the swap level:
- If the order queue is driver like, the order is swapped out.
- A global swap purge is triggered unless a previous purge was run recently (Flow Controller swapCheckDelay attribute, 30s by default).
Additionally, if above 100% of the swap level:
- The incoming order is swapped out.
3). Related configuration parameters
Order Queue maxSOAge can be used for the purge to prevent a recent Service Order to be swapped out from memory. Use case: asynchronous Work Order that was sent and recently enqueued into the POPWaiting Queue and for which the asynchronous response might come quickly. Once enqueued for more than maxSOAge seconds. Default value 600s.
Order Queue maxSwappedInSO attribute can be used to make sure the queue will keep Service Orders in memory. Use case: POPWaiting Queue or all queue in the performance path, to make sure those queues are the last one to swap requests. Default value 100 (per queue).
Flow Controller swapLevel, maximum number of Service Orders allowed in memory, default 200. Depending on Service Orders size vs ossm size, to be found by testing.
Flow Controller ossmIsSwapIndicator, boolean to tell KPSA to rely on ossm occupation rather than Service Order cardinality vs swapLevel, false by default. When true, swapLevel is ignored, an ossmSwapPercentage (see below) is used.
Flow Controller ossmSwapPercentage, 80% by default. Stands for the max level target against which the three progressive phases are triggered (still with 80, 90 and 100%) so that by default, phase 1 starts at 64% of occupation, phase 2 at 72% and phase 3 at 80% of ossm usage.
Flow Controller swapCheckDelay, delay per queue between 2 swap purges. Default 30s.
Note:
=====
ossmIsSwapIndicator has been added in KPSA-3.5.9. It is not present in KPSA-3.6.0 nor KPSA-3.7.0. If you are interested into this enhancement, check your KPSA PROV.ISSUE files for the following:
AP-2: Swap level purge optimization
Description:
============
In KPSA, swapping is used to avoid memory exhaustion. It relies on checkpoints to remove Service Orders from memory and reload them only when necessary. This Solution describes how the swap is handled in KPSA and the main configurable parameters used with it.
Environment:
============
TIBCO® KPSA - Mobile 3.4.x
TIBCO® KPSA - Mobile 3.5.x
TIBCO® KPSA - Mobile 3.6.x
TIBCO® KPSA - Mobile 3.7.x
TIBCO® KPSA - Broadband 3.4.x
TIBCO® KPSA - Broadband 3.5.x
TIBCO® KPSA - Broadband 3.6.x
TIBCO® KPSA - Broadband 3.7.x
Resolution:
===========
1). Prerequisite
A Flow Controller attribute (swapLevel) is used to configure the maximum number of Service Orders allowed in memory before swap is triggered.
By "driver-like order queue" is meant a queue automatically frozen when a certain amount of memory usage is reached (80% by default. Typically drivers, to stop injection and avoid memory exhaustion).
An Order Queue queue out is a temporary place where the Service Order wait a Flow Controller token. It is expected to leave the Order Queue very quickly, therefore it is the worst candidate for swapping.
2). Swap out and swap purge
When an order enters an order queue the order queue may trigger:
- The swap out of the incoming order.
- A local swap purge of the current order queue : orders inside this order queue may be removed from memory.
- A global swap purge on all the queues of the application.
The decision is based on the internal number of Service Orders compared to the allowed value, swap level, and there is three progressive phases.
If above 80 % of the swap level:
- If the order queue is driver-like, the order is swapped out (to remove best candidates for swapping).
- If the order queue is driver-like, a local purge is triggered (to remove previous waiting Service Orders)
- For any queue, if the incoming orders is not enqueued in the queue out, it is swapped out (to remove the Service Order which is going to wait anyway)
Additionally, if above 90 % of the swap level:
- If the order queue is driver like, the order is swapped out.
- A global swap purge is triggered unless a previous purge was run recently (Flow Controller swapCheckDelay attribute, 30s by default).
Additionally, if above 100% of the swap level:
- The incoming order is swapped out.
3). Related configuration parameters
Order Queue maxSOAge can be used for the purge to prevent a recent Service Order to be swapped out from memory. Use case: asynchronous Work Order that was sent and recently enqueued into the POPWaiting Queue and for which the asynchronous response might come quickly. Once enqueued for more than maxSOAge seconds. Default value 600s.
Order Queue maxSwappedInSO attribute can be used to make sure the queue will keep Service Orders in memory. Use case: POPWaiting Queue or all queue in the performance path, to make sure those queues are the last one to swap requests. Default value 100 (per queue).
Flow Controller swapLevel, maximum number of Service Orders allowed in memory, default 200. Depending on Service Orders size vs ossm size, to be found by testing.
Flow Controller ossmIsSwapIndicator, boolean to tell KPSA to rely on ossm occupation rather than Service Order cardinality vs swapLevel, false by default. When true, swapLevel is ignored, an ossmSwapPercentage (see below) is used.
Flow Controller ossmSwapPercentage, 80% by default. Stands for the max level target against which the three progressive phases are triggered (still with 80, 90 and 100%) so that by default, phase 1 starts at 64% of occupation, phase 2 at 72% and phase 3 at 80% of ossm usage.
Flow Controller swapCheckDelay, delay per queue between 2 swap purges. Default 30s.
Note:
=====
ossmIsSwapIndicator has been added in KPSA-3.5.9. It is not present in KPSA-3.6.0 nor KPSA-3.7.0. If you are interested into this enhancement, check your KPSA PROV.ISSUE files for the following:
AP-2: Swap level purge optimization
Issue/Introduction
KPSA swap handling
Feedback
Yes
No
Powered by
