Kbase P78691: Overall application performance drops after installing Fathom Replication
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/19/2005 |
|
Status: Verified
FACT(s) (Environment):
Progress 9.1D
Fathom High Availability Replication 2.0A
SYMPTOM(s):
Overall application performance drops after installing Fathom Replication
Application performs very slow after installing Fathom Replication
Performance degradation when using Fathom Replication
Using asynchronous mode of replication
CHANGE:
Installed Fathom High Availability Replication 2.0A
CAUSE:
BUG# 20040416-001
FIX:
1.) Upgrade to Fathom High Availability Replication 10.0B (OpenEdge 10.0B) or Replication 3.0A (Progress 9.1E).
2.) Change the AI and BI block size to 16KB, (will need replication to be re-initialised).
$ proutil source -C disablesitereplication source
$ rfutil source -C aimage end
$ proutil source -C truncate bi -biblocksize 16
$ rfutil source -C aimage truncate -aiblocksize 16
That the AI and BI blocksizes are 16KB is VERY important. A database with 16k blocksizes has twice the buffer size as a database with 8k blocksizes.
3.) Use -pica 256 on the source database:
$ proserve source -DBService replserv ... -pica 256
The -pica <256> increases size of an internal message queue between replication server and database server (rocket). pica 256 should be set for EVERY database being replicated (not just the main ones). This is important because if you are connected to multiple databases, even if one of the minimally used database's buffer fills then you will still get the pause.
For example: With -pica 256 + 8kb blocksizes, the maximum available to be buffered is approximately 30Mb of AI data. With 16kb it's approximately 65Mb.
There is downside to a large queue (ie -pica 256). If there is a source database/machine failure, the number of AI block(s) in transit between a database (rocket) and the replication (agent) is increased resulting in the target database being less synchronized.