| Subject | Re: [firebird-support] Loosing connection to firebird after a while. |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-02-26T21:28:03Z |
At 07:20 AM 27/02/2009, Dimitry Sibiryakov wrote:
Page Size 8192
Buffers 20480
Means a 160MB cache buffer - fatally large for Classic which allocates the same amount of cache for *each* connection. Probably also exorbitant for SS, unless you're running a 64-bit server on a 64-bit OS -- it's 10* the default (16 MB for your page size). Try 128 pages for Classic and maybe 4092 pages for SS...you can move a bit forward or backward from there as your testing progresses to get a handle on optimal settings for your type of usage.
Actually, "more" doesn't mean "better" with page cache if you don't have oodles of otherwise unused RAM available. As soon as the cache has to swap to disk, you've lost its benefit. On a 32-bit OS you have only a *total* of 2 GB available for an entire process which, for SS, means all of your concurrent connections.
Tip: if you keep the buffers size at 0 in the database header, you can set the DefaultDbCachePages parameter in the firebird.conf of each respective server, to avoid having to change the database header each time you switch server models.
Anything in firebird.log just prior to the crashes? System log?
Also make sure you're not running Guardian with Classic.
./heLen
>> I see this behaviour in classic as well as superserver.He's using TCP local loopback. If he's hammering it hard, could be a firewall thing.
>
> How about TCP/IP versus XNET?
> Windows versus Linux?He said Windows, though not which one.
>Windows is knownResources?
>to limit number of TCP connections - it runs out of available ports.
>What you can see in netstat?
Page Size 8192
Buffers 20480
Means a 160MB cache buffer - fatally large for Classic which allocates the same amount of cache for *each* connection. Probably also exorbitant for SS, unless you're running a 64-bit server on a 64-bit OS -- it's 10* the default (16 MB for your page size). Try 128 pages for Classic and maybe 4092 pages for SS...you can move a bit forward or backward from there as your testing progresses to get a handle on optimal settings for your type of usage.
Actually, "more" doesn't mean "better" with page cache if you don't have oodles of otherwise unused RAM available. As soon as the cache has to swap to disk, you've lost its benefit. On a 32-bit OS you have only a *total* of 2 GB available for an entire process which, for SS, means all of your concurrent connections.
Tip: if you keep the buffers size at 0 in the database header, you can set the DefaultDbCachePages parameter in the firebird.conf of each respective server, to avoid having to change the database header each time you switch server models.
Anything in firebird.log just prior to the crashes? System log?
Also make sure you're not running Guardian with Classic.
./heLen