| Subject | Re: [IBO] Freeing connection very slow |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-07-09T15:46:45Z |
At 03:29 PM 9/07/2003 +0000, you wrote:
had many users running an application that does only commitretaining
(autocommit) without ever doing a hard commit. IBO cleans up all these
unfinished transactions, so that, by the time the last user logs out, there
is a HUGE amount of garbage collection waiting to be done. (Autocommit
with no hard commits prevents GC from doing its stuff when these users are
logged in).
Do you have any huge selects? on a request to close a cursor, the server
will finish sending all the unfetched rows before closing it. You can fix
this by limiting the potential maximum size of sets via where clauses.
Do you have forced writes turned off? Windows never writes withheld
changes out to disk until the server shuts down (that's why you shouldn't
use asynchronous writes on Windows). Quite apart from the shutdown lag,
it's also very risky unless your UPS was Made in Heaven.
If you have been messing around with affinity settings, make sure you
finally have single-processor affinity BEFORE starting the server. No
affinity changes will take effect on a running server - only on startup.
Helen
>--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:This can be a symptom of lots of things...one to look at is where you have
> > You DO have to disable hyperthreading at BIOS level for Firebird.
> >
> > Helen
>
>I disabled the hyperthreading at the BIOS level, and slowness has
>not gone away. Another data point is that it does not happen every
>time. It appears to happen only when releasing the last connection
>to the database.
had many users running an application that does only commitretaining
(autocommit) without ever doing a hard commit. IBO cleans up all these
unfinished transactions, so that, by the time the last user logs out, there
is a HUGE amount of garbage collection waiting to be done. (Autocommit
with no hard commits prevents GC from doing its stuff when these users are
logged in).
Do you have any huge selects? on a request to close a cursor, the server
will finish sending all the unfetched rows before closing it. You can fix
this by limiting the potential maximum size of sets via where clauses.
Do you have forced writes turned off? Windows never writes withheld
changes out to disk until the server shuts down (that's why you shouldn't
use asynchronous writes on Windows). Quite apart from the shutdown lag,
it's also very risky unless your UPS was Made in Heaven.
If you have been messing around with affinity settings, make sure you
finally have single-processor affinity BEFORE starting the server. No
affinity changes will take effect on a running server - only on startup.
>Back on the hyperthreading issue, will Firebird 1.5 be compatibleNo.
>with hyperthreading?
Helen