Subject | Re: [firebird-support] Long ad hoc delays? |
---|---|
Author | Thomas Steinmaurer |
Post date | 2011-02-04T12:06:37Z |
> Thomas Steinmaurer skriver:Imagine you do a DELETE FROM on a very huge table and a SELECT COUNT(*)
>> > I've got an ASP.Net app with a FB 2.1 DB on a 64 bit Win system.
>> >
>> > From time to time, apparently ad hoc, the FB server does "something"
>> > that takes about half an hour. While doing so it does millions of I/O
>> > reads and Windows' file cache consumes all memory I allow it to, but the
>> > FB process itself doesn't seem to consume memory out of the ordinary.
> [snip]
>> > I guess the most likely reason is that the OO framework issues some SQL
>> > that requires a natural scan of one or both of the large tables, or a
>> > full index scan or something.
>>
>> Or garbage collection kicking in. The used garbage collection mode
>> (background, cooperative, mixed) depends on the Firebird architecture
>> and/or the GCPolicy parameter in firebird.conf.
>
> Oh, but I thought GC wouldn't do such large batches of work such as
> this. I thought GC would do "a little every time" rather than "a lot but
> seldom". Maybe I should read again about GC...
on that table afterwards. Depending on the garbage collection mode,
garbage collection will either happen immediately in the context of the
SELECT COUNT(*) or marked to be GC by a background thread.
>> Can only talk about FB TraceManager. It works only with Firebird 2.5 dueYes. I wouldn't mix connections on the same database by different server
>> to the Trace API. We have customers, which moved to Firebird 2.5 in a
>> test environment for just taking advantage of the Trace API. Run stuff
>> there and improved queries in their dev environment. ;-)
>>
>> You don't even need to backup/restore (change the ODS) for using the
>> Trace API. Simply take a copy of the database (just in case), connect
>> with Firebird 2.5 and you are ready to go in respect to the Trace API.
>
> Yes, but I shudder at the thought of copying 52 gigabyte over ADSL...
> I'd have to install 2.5 alongside of 2.1 on the production system. I
> guess I could, and set it up to use port 3051.
processes/versions though.
>> Not sure if a switch to Firebird 2.5 is that easy for you. OO framework etc.--
>
> I'd have to test it. I think it would work - the framework (ECO) is
> rather DB agnostic and supports about a dozen engines. And I assume the
> .Net provider has been brought up to date to support 2.5.
With regards,
Thomas Steinmaurer
Upscene Productions
http://www.upscene.com
http://blog.upscene.com/thomas/
Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server
and NexusDB!