| Subject | Re: [Firebird-Architect] Superserver |
|---|---|
| Author | Jim Starkey |
| Post date | 2006-10-29T11:49:30Z |
Erik LaBianca wrote:
worked on clusters, where a cluster is defined as loosely coupled
processor each with independent memory, a shared (distributed) lock
manager, and shared disk. The original lock managers (note plural) were
constrained to be strictly VMS lock manager compatible so we could use
the VMS lock manager on VAXClusters. Here are the issues for Firebird
clusters:
1. Distributed lock manager, including failover and dynamic node entry
2. Lock semantics (new stuff snuck in) that may not be distributed
lock manager compatible
3. Shared disk access (I don't know enough about Linux clusters to know)
4. Is it a good idea?
Although the gating issues is #1, the critical issue is #4 -- is it a
good idea. I think the answer is no. Assuming the goal is to provide
data management services to the cluster (as opposed to, say, writing a
PhD thesis), then a single process DBMS using single serial write commit
technology will "beat the pants" off a cluster DBMS that has to write a
page to disk to transfer it from process A to process B. In all
seriousness, the best database architecture for a cluster is a separate
large memory SMP box with processors to keep the memory full and the
disk(s) busy.
fine for many readers and light updates, but when page contention picks
up, it spends all of its time playing page ping-pong (table tennis in
the rest of the world). Superserver also has the potential to be souped
up with serial log technology.
> What I'd really like to know is the following"Classic" (the original Interbase architecture) was designed for and
>
> 1. Am I oversimplifying the problem of making classic cluster aware? If
> not it's conceivably something I could see devoting some resources to
> given an agreed upon design.
>
worked on clusters, where a cluster is defined as loosely coupled
processor each with independent memory, a shared (distributed) lock
manager, and shared disk. The original lock managers (note plural) were
constrained to be strictly VMS lock manager compatible so we could use
the VMS lock manager on VAXClusters. Here are the issues for Firebird
clusters:
1. Distributed lock manager, including failover and dynamic node entry
2. Lock semantics (new stuff snuck in) that may not be distributed
lock manager compatible
3. Shared disk access (I don't know enough about Linux clusters to know)
4. Is it a good idea?
Although the gating issues is #1, the critical issue is #4 -- is it a
good idea. I think the answer is no. Assuming the goal is to provide
data management services to the cluster (as opposed to, say, writing a
PhD thesis), then a single process DBMS using single serial write commit
technology will "beat the pants" off a cluster DBMS that has to write a
page to disk to transfer it from process A to process B. In all
seriousness, the best database architecture for a cluster is a separate
large memory SMP box with processors to keep the memory full and the
disk(s) busy.
> 2. Why are people so jazzed about superserver? As I understand it it wasClassic doesn't scale with update load; superserver does. Classic works
> largely implemented to work around weak ipc on windows. Why push
> superserver on unix then, since classic embedded mode works great, and
> classic has some great potential scalability? Is the lack of a shared
> page cache really that big of a performance hit in the days of 64 bit
> machines with gobs of ram?
>
>
>
fine for many readers and light updates, but when page contention picks
up, it spends all of its time playing page ping-pong (table tennis in
the rest of the world). Superserver also has the potential to be souped
up with serial log technology.