Subject | Re: [firebird-support] Re: No more connections after the 62nd.. |
---|---|
Author | Helen Borrie |
Post date | 2004-12-23T11:42:39Z |
At 08:49 AM 23/12/2004 +0000, you wrote:
process because GC is slowing things down. It's much better to fix up your
apps so that GC runs little and often, as it is meant to do.
users. You don't have much swap space configured (think in terms of about
approx. 3 to 4 * RAM size). But never forget that db servers love RAM and
RAM is cheap.
intrinsically know how to spawn threads across multiple CPUs. You could try
setting CPU affinity to two CPUs instead of the default one, and see
whether the OS will help you a little there by delegating some process
threads itself. (I've never had an SMP box to give this a whirl).
you need to do with gbak backup and restore) and would have left the cache
alone at its default 2K or increased its number of pages. On SS the page
cache is shared by all. 512 pages of cache is too few for multiple users,
especially as you will have a lot of very sparsely filled pages overall,
i.e. a very small number of very large, partly-filled pages. Return it to
the default 2K. If you were better supplied with RAM, a 4K or 8K page *
2048 or 4192 pages would be more reasonable for this number of users. As
it stands, the cache will be swapping out to disk constantly, adding extra
overhead churning the disk, defeating any benefit from RAM caching.
If you're really planning to serve 100+ users off this system, fix this up.
including yourself. If you change it in firebird.conf, you will have to
restart the server (assuming you still have SS installed). If you changed
firebird.conf and you don't either change it there, or comment it out
there, it will revert to that setting each time the server is restarted.
./fbmgr -shut -user SYSDBA -password whatever
I'll leave you to find the startup command yourself. :-)
btw, if you did this kind of wild guesswork previously with Classic, I'm
not surprised that each Classic process was consuming 15 Mb. Gosh, I was
beginning to wonder if you had 62 digital cameras as clients...
With Firebird there's no need to play musical chairs with the
configuration, the way you have to on most other db servers. Once you get
a satisfactory setup for your needs, you just forget about it and put your
mental energy into designing good schemas and writing good, well-performing
apps. :-)
./hb
>Thank you for your replies :)Hmm, probably garbage collection. It is NOT a cool idea to kill the server
>
>Last night I switched to Firebird SS, I had tried some hard
>operations and I could make about 240 connections with no problems.
>But, today?! I'm having a hard time here. Sometimes the cpu usage
>gets high, always about %45-65 and I when that happens , everything
>gets real slow. When that happens, I kill the fbserver process and
>when clients connect again, everything runs fine again for a while.
process because GC is slowing things down. It's much better to fix up your
apps so that GC runs little and often, as it is meant to do.
>As an additional info, there's no swap space used yet. If I maxedYou don't have much free RAM for sorting and operations for this number of
>out, wouldn't it be used too? Let me show you my server info.
>
>Cpu(s): 1.7% us, 0.2% sy, 0.0% ni, 98.0% id
>Mem: 1035692k total, 1030072k used, 5620k free, 19340k buffers
>Swap: 1048088k total, 0k used, 1048088k free, 901060k cached
users. You don't have much swap space configured (think in terms of about
approx. 3 to 4 * RAM size). But never forget that db servers love RAM and
RAM is cheap.
>PID USER VIRT RES SHR S %CPU %MEM COMMANDHaving multiple CPUs doesn't win anything for you with SS, since it doesn't
>9804 firebird 163m 59m 5648 S 0.0 5.9 /opt/firebird/bin/fbserver
>
>Can it be something related with multiple CPUs?
intrinsically know how to spawn threads across multiple CPUs. You could try
setting CPU affinity to two CPUs instead of the default one, and see
whether the OS will help you a little there by delegating some process
threads itself. (I've never had an SMP box to give this a whirl).
>Because of your memory concerns I've changed this setting :Most people would have begun with the default page_size of 4Kb (something
>DefaultDbCachePages = 512
>(My database page size is 16384k)
you need to do with gbak backup and restore) and would have left the cache
alone at its default 2K or increased its number of pages. On SS the page
cache is shared by all. 512 pages of cache is too few for multiple users,
especially as you will have a lot of very sparsely filled pages overall,
i.e. a very small number of very large, partly-filled pages. Return it to
the default 2K. If you were better supplied with RAM, a 4K or 8K page *
2048 or 4192 pages would be more reasonable for this number of users. As
it stands, the cache will be swapping out to disk constantly, adding extra
overhead churning the disk, defeating any benefit from RAM caching.
If you're really planning to serve 100+ users off this system, fix this up.
>Can I change this setting without restarting the fbserver process?If you have exclusive access and use gfix -b, yes. First log everyone out
including yourself. If you change it in firebird.conf, you will have to
restart the server (assuming you still have SS installed). If you changed
firebird.conf and you don't either change it there, or comment it out
there, it will revert to that setting each time the server is restarted.
>Oh, forgive me, too many questions for one mail, but how can IFor SS, as root, (from the /opt/firebird/bin directory)
>start/stop the firebird service properly?
./fbmgr -shut -user SYSDBA -password whatever
I'll leave you to find the startup command yourself. :-)
btw, if you did this kind of wild guesswork previously with Classic, I'm
not surprised that each Classic process was consuming 15 Mb. Gosh, I was
beginning to wonder if you had 62 digital cameras as clients...
With Firebird there's no need to play musical chairs with the
configuration, the way you have to on most other db servers. Once you get
a satisfactory setup for your needs, you just forget about it and put your
mental energy into designing good schemas and writing good, well-performing
apps. :-)
./hb