Subject Re: [firebird-support] My Firebird fails on Large database size, only way to fix is by reboot
Author Helen Borrie
At 11:31 AM 18/11/2009, you wrote:
>I have Firebird 2.1 running as super server on Win XP Pro, with the platform being Xeon 5410 chip and 4GB memory.

Firebird 2.1.what?
64-bit WinXP or 32-bit?
How many concurrent connections before the database becomes unavailable?
Page size? (Use gstat -h)
Cache size?

>The application collects phone data and needs to store A LOT of call records. ie up to 300K per day.

That is quite a moderate throughput.

>Today the system has failed (after about 4mths) with nothing being able to access the database. I use IBEasy utility for database queries and tests, but this now fails.
>The database is around 4GB in size and no OS changes have been made.
>The Firebird.log file in the Firebird directory was full of
>inet_error: connect errno = 10061

Means Firebird service wasn't running when a client tried to connect to a database; or you have something screwy in the network config that means the network doesn't recognise the supplied hostname. Usually people get this error when the machine has recently been restarted. On XP you don't have any way to get the OS to start services in a sane order.

>inet_error: read errno = 10054

Usually seen when you restart the server or reboot the host machine with clients connected. Can also accompany events like Fb server crashing, network fault, dipstick user detaching a laptop from the n/w while connected to a database, et al.

>I manually stopped/started the Firebird service applet many times, but that did nothing, only after a reboot did the system reset itself.

That's probably where your network errors are coming from.

>I'm banging my head trying to solve this and have read somewhere about modifying the MaxFileSystemCache parameter in the firebird.conf file.

If you want to read something authoritative about it, read the notes accompanying the parameter in firebird.conf. If you have an absurdly large database cache configured this can cause weird things to happen with the file system cache.

>The Filesystem is NTFS and therefore not troubled by the FAT32 Limitation ...

4GB is not a large database on NTFS. If *really* nothing changed then you are looking at a problem situation that has been building up for 4 months. If you have it recurring after reboot then the most obvious first thing to examine is the level of garbage you are not cleaning out.

>The errors in the logfile do point to some sort of connectivity issues, but I think these stem from the fact that FB is failing somewhere else ...

See above. Also try replacing the NIC on the host machine and its patch cable to the router.

>Judging by the size of the DB and the memory I think it is some internal process FB is performing, I don't really know what,

Check what setting you have for GCPolicy. If it is the default (combined) then you certainly could be observing some temporary blockages associated with cooperative GC *if* your apps or tools are periodically updating or deleting large batches of records. If you are sure that your application is well-behaved regarding transaction management then it would be worth setting it to 'background' to see if that helps.


Sweep doesn't stop the system. Neither does background gc, for that matter; although both have at least the capability to slow it down.

>Filesystem caching?

See comments above about fs caching. Your db cache could make that a bed of nails if it is configured unrealistically.

>something else ?

Well...if you are running 32-bit XP, you don't have 4 GB of RAM, you have a bit more than 3 GB, plus virtual memory, of which a total of 2 GB is available to Firebird.

>FB is great and I love using it, but when the DB gets to around 4GB, some mysterious process kicks in and throws a spanner in the works. The only way to fix is by reboot. System is currently operating, but I know it will happen again. What I need to do is discover why this happens ie what internal process happens with a DB of this size and memory.
>Any idea as to what internal process FB could be running or of fixes?

Fb can be not so great if you're using a desktop operating system to run a Firebird service that's configured to expect resources that the OS can't provide. It sounds as if you're maxing out resources in one or more ways, but you haven't supplied enough information for much except wild guesses.