Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!mtxinu!sybase!orion!forrest
From: forrest@orion.sybase.com (Jon Forrest)
Newsgroups: comp.databases
Subject: Re: Multiple DBMS servers on the same CPU
Message-ID: <9735@sybase.sybase.com>
Date: 13 Jun 90 15:32:53 GMT
References: <1990Jun12.154120.3169@newkodak.kodak.com>
Sender: news@Sybase.COM
Distribution: na
Organization: Sybase, Inc.
Lines: 59

In article <1990Jun12.154120.3169@newkodak.kodak.com> deal@newkodak.uucp (Stephen M. Deal) writes:
>
>We are wondering what the impact on a hardware/os platform would be if we
>ran two (or more) DBMS servers simultaneously on the same CPU. For example
>if we use a vendors application which runs on the DBMS bundled with the OS
>and then develop our own applications on a different DBMS, what would be
>the performance impact.
>
>It seems to me that the two DBMSs might fight for resources and therefore
>provide less throughput than if both applications used the same DBMS.
>However this is the real (read heterogeneous) world and quite often we are
>faced with applications that are not DBMS independent. 
>
>Aside from the obvious problems of sharing data between the databases (RDA
>ain't here yet), does anyone have experience running two RDBMSs simultaneously
>on the same CPU (e.g. Ingres and Rdb/VMS, Informix and Sybase)?
>

You didn't say which OS the DBMS is using. This makes some difference
because on OS's which don't do asynchronous I/O I would imagine that
having more than one server might get you something since the second
server could get some CPU while the first is waiting for an I/O to
complete. On the other hand, if asynchronous I/O is supported then
I don't see any benefit from running more than one server, assuming
a multithreaded server, since the CPU will be kept busy performing
all the DBMS work presented to the server. If there isn't enough
work to keep the CPU busy, then the server would be idle but then
there wouldn't be any reason to have a second server in the first
place, unless the second server is needed for other not
related to performance.

For non-Sybase servers there might also be the question of what
happens if you're running more than one server where all the servers
access the same database. If one server gets a lock on a resource and
then is scheduled out because another server needs to run, and the
second server needs to access the locked data, then it will have to
wait until the first server can run again. This simple case will
cause a minor slowdown but these locking conflicts can get complicated.
(By "non-Sybase servers" I mean servers that use the O.S. provided
locking mechanism. One of the reasons we don't allow simultanous
access of multiple servers to the same database is because we don't
use the O.S. provided locking mechanism. We use a scheme that is part
of our multithreaded kernel inside our server. Our announced MP
server uses shared memory and internal synchronization primitives
to control data access when running on multiple CPUs in the same node.)

If you're running more than one server and the servers are from
different vendors then this locking problem would not occur but then
you couldn't access the same databases. In this case you'd have the
same problem running two servers as you'd have running two compilers
at the same time.

----
Anything you read here is my opinion and in no way represents Sybase, Inc.

Jon Forrest WB6EDM
forrest@sybase.com
{pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest
415-596-3422