Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde!uunet!aplcen!samsung!cs.utexas.edu!asuvax!anasaz!john
From: john@anasaz.UUCP (John Moore)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Keywords: Client Server Processes
Message-ID: <972@anasaz.UUCP>
Date: 5 Dec 89 14:29:11 GMT
References: <7114@sybase.sybase.com> <6895@sybase.sybase.com> <2184@kodak.UUCP> <375@xyzzy.UUCP> <510@xyzzy.UUCP> <936@anasaz.UUCP> <2762@infmx.UUCP>
Reply-To: john@anasaz.UUCP (John Moore)
Organization: Anasazi Inc, Phoenix AZ
Lines: 53

In article <2762@infmx.UUCP> aland@infmx.UUCP (alan denney) writes:
]In article <936@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes:
]>...
]>Anyhow,... the fact is that with proper cooperation from the OS
]>scheduler and I/O system, architectures that allow requests from
]>many processes to be served by one server can do a better job than
]>process per server. We just benchmarked a realistic application
]>mix where the Informix back-end memory usage alone exceed 350MBytes!
]
]Um, I would be *really* interested to see how you computed this.
]Did you take into account text sharing, memory usage by the kernel,
]database front-end processes, and other unrelated processes?
]I can't fathom 350 MB of *actual main memory consumption* by the engines
]and server(s).  I think I know the benchmark to which you refer, and
]it was not even close to being memory-bound.
]
It was computed two ways: (1) The amount of data space memory that
each front-end/back-end pair takes up (~.5mB); (2) The paging rate
on the system when we ran the number of processes that the above
estimate indicated should take all the memory. Remember, in the
benchmark you are thinking about, the front end and back ends
were in the same machine. By the way, this is not meant to be
a slam at Informix (hey... I'm a stockholder as well as a user :-) ),
just an observation of the pitfalls of using one server per user.

]>The advantage of one process per multiple users is that the
]>"threads" can be cheap - low memory usage, low CPU usage because
]>of precisely targetted scheduling algorithms. In addition, it
]>is cheaper for them to cooperate for optimized scheduling. Finally,
]>we have found that lock contention consumes lots of CPU when
]>you have a large number of very active processes. The single
]>server (or few servers) is a good way to reduce the lock overhead.
]>John Moore (NJ7E)           mcdphx!anasaz!john asuvax!anasaz!john
]
]This depends on in what way the processes are "active".  If they are
]competing for update access to exactly the same pages, lock contention
]can indeed make the database spend much of its time managing locks.
](For example, running multiple insert processes against the same table
]with page mode locking in use is considered to be in poor taste :-]).
]In a normal transaction mix, however, these lock contentions are
]atypical.

In our benchmark, with a very realistic transaction mix, the CPU
usage went up in a non-linear way with the number of processes,
eventually using up all the MIPS on the machine. We were able
to drive a system hard enough that it spent so much time thrashing
locks that it could only do .1 transactions per second. At lighter
load, it did 20 TPS.
-- 
John Moore (NJ7E)           mcdphx!anasaz!john asuvax!anasaz!john
(602) 861-7607 (day or eve) long palladium, short petroleum
7525 Clearwater Pkwy, Scottsdale, AZ 85253
The 2nd amendment is about military weapons, NOT JUST hunting weapons!