Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!tank!cs_bob@gsbacd.uchicago.edu
From: cs_bob@gsbacd.uchicago.edu
Newsgroups: comp.databases
Subject: Re: Single Server Bottlenecks (was RE:ORACLE REL 6, INGRES REL 6)
Message-ID: <3280@tank.uchicago.edu>
Date: 17 May 89 15:22:04 GMT
Sender: news@tank.uchicago.edu
Distribution: usa
Organization: University of Chicago Graduate School of Business
Lines: 53

> 
>And your point is well taken.  Okay, it can.  Does it?  How often?
>How inferior?  If you want to be helpful, please tell us not only the
>what and where of bottlenecks but also when and how much.
> 

There is very little in your excellent analysis which I can dispute. It
is much more detailed than I ever intended to be, or could even pretend
to be. However, I would like to point out a couple of things

1) My analysis was directed at one special case, which greatly simplifies
everything. That is, it is directed at instances where the version 6 backend
becomes truly compute bound (which is to say, there are no free cycles, and
the backend may actually have use for 100% or more of the processor.)

2) I never intended to give a detailed perscription for the analysis of
all situations. I realize that different sites have a wide variety of
computing environments, and individual users will have to take this into
account. For example, a machine dedicated to serving Ingres database
requests will experience no ill effects. However, in our mix, which
for a given processor includes 3 or 4 software developers compiling,
linking etc. at any given time, a variable number of students and faculty
do various things, and generally several large, CPU bound batch jobs
running at priority 3, the bottleneck I observed is very real. (Note
too that we force large CPU bound jobs to run in batch by enforcing a
CPU limit for interactive jobs.)

3) For the purpose of rough estimation, I still stand by my metric. Users
need to understand the implications of the numbers derived, and Mr.Krueger's
analysis is a good start. There are a number of ways of calculating load.
Again, most of my analysis presumes that the CPU is busy with priority 4
jobs, including non-Ingres DBMS work.

Any statistics I give regarding frequency and extent, would of course only
apply to my particular installation. Nonetheless they result from a problem
that results from a combination of Ingres's single server architecture
and the VMS scheduling philosophy. If the server is running at priority
4, VMS is going to treat it on a par with all interactive jobs. This is
not a problem as long as the database server is primarily responsible
for issuing I/O requests, which is what it usually does. However, if
and when the server becomes CPU bound, (and in our installation it happens
2-3 times a day for 10 to 30 minute periods, when there are no more than
6 or 7 users on the server), the server is a bottleneck. It is treated by
VMS as a single process, and is provided with a single process's share
of CPU. However, it is effectively providing cycles for 6, 7 or theorectically
many more users.

I never intended to provide a detailed performance analysis for my own site,
let alone "the general case." My initial posting was in response to a request
for examples of single server bottlenecks. I believe that the potential for
such a bottleneck exists in Ingres 6.1 running under VMS. 

-- Bob Kohout