Subject | OAT/Next Transaction & IB Performance |
---|---|
Author | Jim Sirikolkarn |
Post date | 2002-01-18T12:21:42Z |
Hi all,
We seriously need some help.
We use FB (previously 0.94 and now RC2) with IBO in few hospitals. SOmetime
during peak hours, FB just seem like hanging -- very slow slow response. We
monitor with gstat -h and found that the Oldest Trasnaction and Oldest
Active is very near (sometime diff. by 1) but the Next Transaction is very
far away from both and it keeps moving, while the Oldest Transaction/Oldest
Active stay at the same number.
To clear this problem we have to shutdown the server and restart (without
backup/restore or sweep). After restart, these numbers stay the same, but
for a while after some connection from user arrive the Oldest
Transaction/Oldest Active will move and finally come near the Next
Transaction and system performance recovered. Sometime the problem can be
clear by itself without restart the server when the load is slow down. I
have a few questions:
1. Why restart the server can bring down the OAT/Next Transaction gap
without doing backup/restore or sweep ?.
2 Why FB cannot bring down the gap by itself under heavy load ?. (The
problem do not occur on light-load days)
3 We set sweep interval = 20,000. Would it help if we set sweep interval to
3,000? Will the sweep process clear the OAT/Next Transaction gap?.
4 The Application use IBO with AutoCommit transaction. If the explicit
transaction is used it is always end with Commit or rollback. Can Rollback
contribute to this problem?
Hope someone kind enough to shed some light.
TIA,
Jim Sirikolkarn
We seriously need some help.
We use FB (previously 0.94 and now RC2) with IBO in few hospitals. SOmetime
during peak hours, FB just seem like hanging -- very slow slow response. We
monitor with gstat -h and found that the Oldest Trasnaction and Oldest
Active is very near (sometime diff. by 1) but the Next Transaction is very
far away from both and it keeps moving, while the Oldest Transaction/Oldest
Active stay at the same number.
To clear this problem we have to shutdown the server and restart (without
backup/restore or sweep). After restart, these numbers stay the same, but
for a while after some connection from user arrive the Oldest
Transaction/Oldest Active will move and finally come near the Next
Transaction and system performance recovered. Sometime the problem can be
clear by itself without restart the server when the load is slow down. I
have a few questions:
1. Why restart the server can bring down the OAT/Next Transaction gap
without doing backup/restore or sweep ?.
2 Why FB cannot bring down the gap by itself under heavy load ?. (The
problem do not occur on light-load days)
3 We set sweep interval = 20,000. Would it help if we set sweep interval to
3,000? Will the sweep process clear the OAT/Next Transaction gap?.
4 The Application use IBO with AutoCommit transaction. If the explicit
transaction is used it is always end with Commit or rollback. Can Rollback
contribute to this problem?
Hope someone kind enough to shed some light.
TIA,
Jim Sirikolkarn