Sybase scalability on Sun SMP 
Author Message
 Sybase scalability on Sun SMP

Mark Breland writes :

> You flirt with semantic disaster by stating "there are *2* sybase servers".
> In fact, there still exists only one Sybase server, but with multiple
> engine processes to speed up transaction processing where concurrency
> is possible.  Given two online engines, one of those processes serves as
> a master and handles every transaction presented in the queue.  If the
> master is processing one transaction, and another transaction arrives
> which has no dependencies on tables used in the first transaction, then
> the master will hand that second transaction over to the slave online
> engine to process concurrently.  However when dependencies exist, such
> as an update to the same table, then the second transaction must wait
> until completion of the first (just as in a single server environment).

I don't know where mark gets this, If the server checked any such
dependancies, then the TPC benchmarks would run no faster on a
multi-processor.  I believe that Sybase handles only network communications
on a master/slave basis - the slaves are capable of compiling thier own
SQL and no dependancies are checked.  I have run my own benchmarks which
show no indication of the master checking dependancies.

> What you'll observe with the mpstat command on a Sun multi-processor is
> that the cpu with the master server has a greater loading than the cpus
> wherein reside the slave servers.  This is because the master reviews
> all incoming transactions.  The slaves get work only when their assigned
> transactions don't overlap tables.  Therefore, you will primarily realize
> performance gains for applications with a diverse number of tables
> that are queried against through interleaved transactions.

Again - the master would have to compile the query plan to do this and review
the query plans of all running transactions.  The added CPU load on the
master is not enough to indicate that it is performing this much work for
each and every transaction.  This also does not explain the cases where
three engines run at 65% while processing a single statement.  

I hope we will be hearing from Sybase on this since Mr. Breland's
interpretation of thier master/slave arrangement would be bad for
business if it were to spread around.

In my experience, the biggest limiting factor is the memory bandwidth.  
Databases tend to produce low cache hit ratios and require many fetches
from main memory.  On a shared-memory multi processors (such as an SMP
system)  the common memory bus will become swamped at a point that
depends on the size of the local cache, the speed of the processors
and the bandwidth of the main memory bus.  After this point, bus
contention causes the thruput to actually decrease as additional
engines are added. (This assumes of course that there is not some
other bottleneck such as Disk or network I/O's)

Lawrence E. Hall
First Boston Corp.
5 World Trade Center 9th Floor                    uunet!csfb1!phantom!lhall

The Secretary will disavow all knowledge.
This message will self-destruct in 5 seconds.

Fri, 11 Aug 1995 23:24:01 GMT
 [ 1 post ] 

 Relevant Pages 

1. Scalability of Sybase on Sun SMP

2. Scalability : SMP to MPP in a Datawarehouse env.

3. scalability and data warehouse (smp to mpp)

4. Ingres SMP Scalability

5. SpinLock values for SMP Sun 1000E

6. Servlet scalability in Sybase

7. Sybase MPP shows excellent scalability to 128 CPUs

8. sybase scalability

Powered by phpBB® Forum Software