Hi,

issues with my firebird istalation persists :(

As helen mentioned i checked IOT AIT and other stuf. Yesterday at night i
done nbackup 0 on all databases. After that all databases shown

OIT X
AIT X+1
SNAPSHOT X+1
Next transaction X+2

All are ODS 11.0 implementation 19. Some of them are dialect 1 and some
are dialect 3.

Server simple stop responding even to TERM signal. Aprox 15 hours after
nbackup. I didnt done restore. All databases was restored at 24/Feb so
they are not very old. Bigest transaction number is less then 20k.

Please give me a glue what can i do to hunt this bug. Will coredump show
you anything? I dont want to use strace as its production server.

So simple tell me what i have to provide and may be how to get it so i'll
be able to collect all informations at next freeze.

thx,

pavol

> At 07:13 AM 3/03/2008, you wrote:
>>Hi all,
>>
>>i use firebird or interbase from version 4. All that time there was
>>small or bigger issues with it, but nothing so serious to blame it.
>>
>>Till now of course :)
>>
>>I'm small hosting provider. We host near 200 websites on server.
>>Majority of them uses firebird of course. As we use gentoo we used
>>firebird from official repository. Client is PHP on apache. Again base
>>gentoo versions.
>>
>>Till last weekend we used version 1.5.3. Everything worked near
>>perfect. Except one think. Firebird used hang every 10 days but later
>>every 24 hours.
>
> This smells like a garbage collection (and transaction management)
> problem.
>
>>It simple stop responding to connect or react on any api function. It
>>simple locks out. There is no load from firebird on server and it
>>looks its in Sl state (sleep multithreads.) Not respondindg to TERM
>>only to KILL
>
> This smells like an exacerbated garbage collection problem.
>
>
>>Last week I upgraded to version 2.0.3 issue is even worse.
>
> Have you studied the release notes? In particular, search for "garbage
> collection". Fb 2 offers more options for GC on Superserver and installs
> with two GC methods combined. Without more information, e.g., the DB
> header statistics and whether you upgraded the database to ODS 11, the
> obvious deduction is that you have a long-term GC problem and cooperative
> GC is making it worse.
>
> You have the option of reverting to the Background method alone, which
> would at least take you back the GC conditions that you had with Fb 1.5.
> Or, if you have plenty of machine resources, you could use Classic
> instead, where Cooperative is the only method used.
>
> However, neither of these options is going to correct the problem that
> *causes* the build-up of garbage. That problem lies in your client code.
>
>
>>so i use:
>>firebird superserver 2.0.3.12981-r5 (portage version)
>>php-5.2.5_p20080206-r3 (portage version)
>>32bit gentoo-sources kernel 2.6.24-gentoo-r3
>>CFLAGS="-O2 -march=i686 -pipe"
>>CHOST="i686-pc-linux-gnu"
>>
>>Daily aprox. 1 milion of connects to server (hits), i do not use
>>persistent connection as it had no impact on issue.
>>
>>And here is question:
>>Can anyone help me to solve this issues? If not i'll be forced to
>>replace firebird by something else (sqlite and postgres). But as i
>>said i use firebird for long time and i like it.
>
> You will have the same problem with PostGres. Worse, actually, because
> with PG you have to take your database offline to deal with garbage
> overload.
>
>
>>So If there is anyone who can point me where problem is i'll be very
>>happpy. I can attach gdb on hanged firebird. But i cannot use strace
>>ot run firebird in gdb as this issue happen on production server. I
>>can provide any aditional information on request.
>
> There's no need to send the database, nor anything to learn from it. You
> need to do your own forensics. But, if you want help with this you need
> to provide more information. The output from gstat -h would be a good
> starting place, since it will tell us what the ODS of the database is,
> besides providing some essential clues about how your application code is
> managing transactions.
>
> You should also provide *honest* information about how often you perform
> gbak on the database without the -g switch and/or sweeping. Meaning, when
> people have databases with severe garbage collection problems, they tell
> you what the housekeeping routines are *meant* to be, not what they
> actually DO! ;-)
>
> If poor GC *is* the basis of your troubles then this list can help you
> with the forensics and explain what admin measures you can take to reduce
> the effects. We can explain what the application code needs to do to
> avoid those troubles recurring.
>
> However, for advice about altering your PHP scripts and effecting a
> solution, you would need to use the firebird-php list. I'm sure the
> firebird-php community would welcome the participation of a new face with
> a long history of using PHP for access to Firebird, as well.
>
> [ If this is an O2 service provider we are looking at here (just a wild
> guess!) then you're not the only one who could be very keen to get a
> perfect solution to what looks like a very long-standing problem. ]
>
> ./heLen
>