Subject | Re: [firebird-support] Firebird & cluster |
---|---|
Author | Yves Glodt |
Post date | 2005-06-29T14:15:10Z |
Ann W. Harrison wrote:
(http://opensource.codito.com/migshm/), and with that sometimes (in fact
once) an fb_inet_server process migrated to another node.
We intensively queried our 4GB database from 8 connections (thus 8
fb_inet_server processes were running). But, then we ended up with
freezes (kernel panic), even once of the complete cluster. (It consists
of one master and one node atm, running clusterknoppix.) So for now we
forget the idea of FB on a cluster...
As I read Vulcan plans to introduce strong SMP capabilities. Will it
also be able to run in a cluster?
Or is the preferable way to use big (8 or 16 CPUs) SMP machines in case
where huge load is expected?
I ask because there are chances we get a new customer with about 300
users. Because of the performance issues we have right now with the
30-40 users, we search to find solutions to get the performacnce we
need, to see if we will be able to serve 300 users in the future...
(We'll start by compiling Vulcan now.)
Are there maybe others on the list that have experience (and are willing
to share) with such numbers of (intensively used) connections, with
GB-sizes of databases. Does FB (classic running on Linux 2.6) scale to 8
or 16 CPU boxes?
Is inetd or xinetd prefered?
Thank you and best regards,
Yves
> Yves Glodt wrote:We tried today, with the experimental migshm openmosix patch
>
>>>>does anybody have some experience in running firebird (classic) in an
>>>>Openmosix or Rocks cluster?
>>>
> I wrote;
> >>
>
>>>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.
>
>
> I suspect it won't work well in our case. I looked at the description
> here: http://www.unixreview.com/documents/s=8989/ur0404l/ and it seems
> to me that each time the lock table owner changes (which is very very
> often) the memory section has to be propagated to all nodes on the
> cluster. Nor is it clear to me how a process running on one node in the
> cluster requests access to shared memory currently used on another node.
> Maybe all processes start on a parent node where they acquire the
> memory...
>
> Jim says it won't work at all because, even in classic, some of the lock
> manager communication depends on a thread waiting on an event, and
> that's nowhere in this model.
(http://opensource.codito.com/migshm/), and with that sometimes (in fact
once) an fb_inet_server process migrated to another node.
We intensively queried our 4GB database from 8 connections (thus 8
fb_inet_server processes were running). But, then we ended up with
freezes (kernel panic), even once of the complete cluster. (It consists
of one master and one node atm, running clusterknoppix.) So for now we
forget the idea of FB on a cluster...
As I read Vulcan plans to introduce strong SMP capabilities. Will it
also be able to run in a cluster?
Or is the preferable way to use big (8 or 16 CPUs) SMP machines in case
where huge load is expected?
I ask because there are chances we get a new customer with about 300
users. Because of the performance issues we have right now with the
30-40 users, we search to find solutions to get the performacnce we
need, to see if we will be able to serve 300 users in the future...
(We'll start by compiling Vulcan now.)
Are there maybe others on the list that have experience (and are willing
to share) with such numbers of (intensively used) connections, with
GB-sizes of databases. Does FB (classic running on Linux 2.6) scale to 8
or 16 CPU boxes?
Is inetd or xinetd prefered?
Thank you and best regards,
Yves
>>
>>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?)
>
>
> I'd try the switch to Linux. Anecdotal evidence says that Linux will
> work better with classic than Windows does.
>
> Regards,
>
>
> Ann