gary@mic.UUCP (Gary Lewin) (08/28/90)
It is my understanding that on a 33 mhz, caching UN*X system with 16
megs of ram, up to 16 users could run Oracle at once. At least
according to people at Oracle.
Now for some questions for those of you actually running Oracle:
1) How many simultaneous users are <REALLY> able to use the above
system with little or no performance degradation?
2) How many simultaneous users are able to use a 16 megabyte
25 mhz system with little or no performance degradation?
3) How many simultaneous Oracle developers should be able to use
the 33 mhz, 16 meg system with little or no performance
degradation (Oracle says 5-6)?
I appreciate any light that may be shed on this topic. It would also
be of interest to get a comparison of the above information but with
other database managers running under UN*X on 386-486 systems.
Thanks,
Gary Lewin
gary@mic.lonestar.orgrad@genco.uucp (Bob Daniel) (08/29/90)
In article <2399@mic.UUCP> gary@mic.UUCP (Gary Lewin) writes: > >2) How many simultaneous users are able to use a 16 megabyte > 25 mhz system with little or no performance degradation? We have 25mhz w/8meg on UNIX running 6.0 RDBMS, 3.0 Forms. I ran 8 users with some performance change. At 10 users, it got too sluggish. At 12, I was getting fork errors but that was a UNIX tuning issue and not Oracle. I'll be trying out 16mb soon. > >3) How many simultaneous Oracle developers should be able to use > the 33 mhz, 16 meg system with little or no performance > degradation (Oracle says 5-6)? With the same system, we have had 6 in sqlforms in development mode (3.0 forms) and it did get slow at times. 4 users hasn't seemed to be much of a problem.
barr@frog.UUCP (Chris Barr) (09/01/90)
In article <2399@mic.UUCP>, gary@mic.UUCP (Gary Lewin) writes: > It is my understanding that on a 33 mhz, caching UN*X system with 16 > megs of ram, up to 16 users could run Oracle at once. At least > according to people at Oracle. > > 1) How many simultaneous users are <REALLY> able to use the above > system with little or no performance degradation? In our experience, sql*forms applications which open many cursors can ----------------- eat up the 15 meg (1 meg is lost on DOS architecture motherboards running Unix) with only 6 users. However, we've also run 20 users, with each using very, very few open cursors. The performance hit is in paging to disk. The math for calculating processes' memory consumption is pretty straightforward, with input from ps commands showing text (shared) and data sizes. It's easy to recommend a 486 system, which at least will have the option of upgrading to support > 16 Meg. The vast majority of '386 motherboards have an AT architecture that won't go above 16; a few go to 24 or 40.
aland@infmx.UUCP (Colonel Panic) (09/02/90)
In article <18383@frog.UUCP> barr@frog.UUCP (Chris Barr) writes: >In article <2399@mic.UUCP>, gary@mic.UUCP (Gary Lewin) writes: >> It is my understanding that on a 33 mhz, caching UN*X system with 16 >> megs of ram, up to 16 users could run Oracle at once. At least >> according to people at Oracle. >> 1) How many simultaneous users are <REALLY> able to use the above >> system with little or no performance degradation? > >In our experience, sql*forms applications which open many cursors can > ----------------- >eat up the 15 meg (1 meg is lost on DOS architecture motherboards running >Unix) with only 6 users. However, we've also run 20 users, with each >using very, very few open cursors. The performance hit is in paging >... >It's easy to recommend a 486 system, which at least will have the >option of upgrading to support > 16 Meg. The vast majority of '386 >motherboards have an AT architecture that won't go above 16; a few >go to 24 or 40. Not anymore. In my experience, most high performance 386 boxes will support 24, 32, 40, 48, or 64 MB of memory. (For example, all currently-produced AT&T and Intel 386 boxes support 40MB or more). The bigger problem is the ISA (AT) bus. Since it can't handle DMA beyond the 16MB boundary, UNIX has to go thru some hoops (and not very solid ones, BTW) to remap the higher memory in the kernel. If they will really need more memory, they would be better served by a Micro Channel- or EISA-based machine, regardless of processor. Or, get a database system that's less of a resource hog... :-] -- Alan Denney # aland@informix.com # {pyramid|uunet}!infmx!aland There are only 3,734 known Denneys in North America. Be nice to us.