Subject | Re: [firebird-support] Firebird & cluster |
---|---|
Author | Yves Glodt |
Post date | 2005-06-28T16:07:15Z |
Ann W. Harrison wrote:
It seems openmosix provides the needed shared memory functionality.
then we got a dual-processor box and that's when we switched to classic
to have at least the processes use the 2 cpus.
There are frequently like 50 processes, and the performance problem
comes mainly from some expensive selects which block it's fbserver
process for a more or less long time (several to many seconds).
The queries can be considered optimized so far, it seems the slowness
comes simply from the huge amount of data which is queried intensively
by some concurrent users.
We have considered switching to Linux on the server (current OS is
windows 2000 server IIRC) as it manages (theroretically) processes more
efficiently than windows. (Any experience on that subject?)
That's also why we came up with the idea of an openmosix cluster.
If we have already a Linux server, it's easy to install an openmosix
kernel + the userland tools, add more boxes to the setup and have a
small cluster.
Then, ideally, the processes would migrate from the busy "main"server to
the next less-busy node of the cluster.
But, first tests today have shown that we were not able to migrate an
fb_inet_server process from one node to another, for unknown reasons.
Even forcing it with the "migrate" tool did not succeed. We will do more
testing tomorrow with more processes (today was only 4 max.).
(Question for om pros: Could the not-migrating of processes be related
to the fact that inetd is staring the fbserver processes.)
Thanks in advance and best regards,
Yves
> Yves Glodt wrote:Hi again and thanks for your answer,
>
>>does anybody have some experience in running firebird (classic) in an
>>Openmosix or Rocks cluster?
>
>
> Unless the cluster provides shared memory for the lock manager, Firebird
> won't run on it.
It seems openmosix provides the needed shared memory functionality.
>>Wee need a performance improvement for a project where about 30-50In fact first there was a single processor machine with superserver,
>>concurrent users are hitting a 4GB database. We are using classic server
>>as the server is a dual-processor machine.
>
>
> What else have you tried to increase performance? Classic has the down
> side that pages have to be transfered through disk when two connections
> are both updating them. SuperServer was designed to be a performance
> boost because it manages a shared cache and reduces the I/O load.
then we got a dual-processor box and that's when we switched to classic
to have at least the processes use the 2 cpus.
There are frequently like 50 processes, and the performance problem
comes mainly from some expensive selects which block it's fbserver
process for a more or less long time (several to many seconds).
The queries can be considered optimized so far, it seems the slowness
comes simply from the huge amount of data which is queried intensively
by some concurrent users.
We have considered switching to Linux on the server (current OS is
windows 2000 server IIRC) as it manages (theroretically) processes more
efficiently than windows. (Any experience on that subject?)
That's also why we came up with the idea of an openmosix cluster.
If we have already a Linux server, it's easy to install an openmosix
kernel + the userland tools, add more boxes to the setup and have a
small cluster.
Then, ideally, the processes would migrate from the busy "main"server to
the next less-busy node of the cluster.
But, first tests today have shown that we were not able to migrate an
fb_inet_server process from one node to another, for unknown reasons.
Even forcing it with the "migrate" tool did not succeed. We will do more
testing tomorrow with more processes (today was only 4 max.).
(Question for om pros: Could the not-migrating of processes be related
to the fact that inetd is staring the fbserver processes.)
Thanks in advance and best regards,
Yves
> Regards,
>
>
> Ann