Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!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: <3241@tank.uchicago.edu> Date: 15 May 89 16:20:49 GMT Sender: news@tank.uchicago.edu Distribution: usa Organization: University of Chicago Graduate School of Business Lines: 54 >cs_bob writes: > >>it has become fairly common for use to se an Ingres server running >>on a VAX 8650 with only 4 or 5 Ingres users to become CPU bound while only >>getting 15-20% of the available CPU. Moreover, this happens when the Ingres >>users are competing with only 4 or 5 other processes for the processor. > >Can you give us some DATA? How common? Under what conditions? What >are the users doing? What performance degradation is measured for the >individual user? For system throughput? > I think that you're missing the point. My posting was an attempt to point out that single server bottlenecks can and do exist. I'm not attacking Ingres, but the fact remains that under VMS, with its retarded scheduling strategy, the Ingres 6.1 server can become a true bottleneck. If any 5.0 users wants to determine whether or not this could happen to them, I suggest the following. a) when you suspect the database activity is heavy, run MONITOR PROCESS/TOPCPU and look for the ING_BACK_* processes. You should see the busiest backends, and if you sum the percentage of CPU they're getting, you should get a rough estimate of the total CPU being provided the backends. b) run MONITOR STATE/AVE for a typical working day to get an idea of the typical CPU load (i.e. the average number of processes in the COM state throughout the day.) If we call the result of a) CPU_USED and remember that it is a percentage strictly between 0 and 1, and if we call the result of b) CPU_LOAD then IF CPU_USED > 1 / CPU_LOAD YOU WILL PROBABLY EXPERIENCE A BOTTLENECK RUNNING A SINGLE INGRES 6.1 SERVER. most of Mr.Krueger's posting is a smokescreen. He asks for hard data, then himself proceeds with a thouroughly general, theorectical treatment of scheduling problems. Most of what he says applies equally to all DBMS systems, Ingres 5.0 as well as 6.1. My point is that in this respect, Ingres 6.1 can provide inferior performance to Ingres 5.0. My favorite of Mr.Krueger's suggestions: > If you want to support multiple fully runnable (COMputable) > jobs without interference, you need a multiprocessor. Buy one. > Configure your servers as you find optimal for best throughput > and fair for INGRES versus non-INGRES applications. > Got that? If you want your Ingres 6.1 performance to equal your Ingres 5.0 performance, Jonathon Krueger recommends that you buy yourself a multiprocessor. R.Kohout #include