| Subject | Re: [firebird-support] Re: after 2.1 to 2.5 migration, nbackup seems to slow operations unusually |
|---|---|
| Author | unordained |
| Post date | 2013-07-11T20:24:12Z |
---------- Original Message -----------
From: "unordained" <unordained_00@...>
To: firebird-support@yahoogroups.com
Sent: Thu, 11 Jul 2013 09:51:17 -0500
Subject: Re: [firebird-support] Re: after 2.1 to 2.5 migration, nbackup seems to
slow operations unusually
I switched to -D OFF. It did cut the amount of time spent on incremental backups
in half (now around 4 minutes), but during that time, I'm seeing concurrent
queries still being delayed by 15 to 220 seconds. Even starting a transaction
[from tomcat connection pool, jaybird] may be delayed 10 seconds, while nbackup
is running. Only a few queries were allowed to complete in the middle of the
backup; most that were started during the backup only completed when the backup
itself completed, which I don't think is expected behavior for nbackup.
I'm interested in some comments I find in CORE-2315, such as this:
"... Users working is stopped only for changing backup state. It takes time for
flushing cash. After that your users should use database as before. Now merging
pages from delta to main database file takes more time than in new nbackup.
There is a patch to improve nbackup but on superserver it has known issues and
it don't allow to apply it in firebird. At least the merging process must be
faster then now. ..."
What's the known issue with SS?
Also, we depend a lot on heavy on-commit triggers that "fix up" data modified
during the transaction; it seems like when on-commit triggers take a long time,
it has a knock-on effect on other connections (particularly starting new
transactions, it seems like?) Any ideas on that? Could this be a cascading
event, where slowness impacts a transaction that made changes and its on-commit
took longer than usual, and then that caused other transactions to fail to start
right away?
-Philip
From: "unordained" <unordained_00@...>
To: firebird-support@yahoogroups.com
Sent: Thu, 11 Jul 2013 09:51:17 -0500
Subject: Re: [firebird-support] Re: after 2.1 to 2.5 migration, nbackup seems to
slow operations unusually
> ---------- Original Message ------------------ End of Original Message -------
> From: Dmitry Yemanov <dimitr@...>
> > Out of curiosity, did you try playing with -D ON/OFF modes for
> > nbackup? If so, does it make any difference?
> >
> > Dmitry
> ------- End of Original Message -------
I switched to -D OFF. It did cut the amount of time spent on incremental backups
in half (now around 4 minutes), but during that time, I'm seeing concurrent
queries still being delayed by 15 to 220 seconds. Even starting a transaction
[from tomcat connection pool, jaybird] may be delayed 10 seconds, while nbackup
is running. Only a few queries were allowed to complete in the middle of the
backup; most that were started during the backup only completed when the backup
itself completed, which I don't think is expected behavior for nbackup.
I'm interested in some comments I find in CORE-2315, such as this:
"... Users working is stopped only for changing backup state. It takes time for
flushing cash. After that your users should use database as before. Now merging
pages from delta to main database file takes more time than in new nbackup.
There is a patch to improve nbackup but on superserver it has known issues and
it don't allow to apply it in firebird. At least the merging process must be
faster then now. ..."
What's the known issue with SS?
Also, we depend a lot on heavy on-commit triggers that "fix up" data modified
during the transaction; it seems like when on-commit triggers take a long time,
it has a knock-on effect on other connections (particularly starting new
transactions, it seems like?) Any ideas on that? Could this be a cascading
event, where slowness impacts a transaction that made changes and its on-commit
took longer than usual, and then that caused other transactions to fail to start
right away?
-Philip