Re: Why Performance Tank

Obnoxio The Clown wrote: > Mark D. Stock wrote: > > >>miyaki wrote: >> >>>Dear Mark, >>> >>>Additional info as below: >>> >>>OS = Sun Solaris 2.7 >>>IDS=7.31.UC2 >>>Total Memory = 2GB >>>SHMVIRTSIZE = 90112 (88MB) >>>SHMADD = 8192 (8MB)>>> >>>My current database was allocated additional 6 virtual segments by >>>itself and the performance was became very slow. This performance issue >>>was gone away after I consolidate all the additional segments into one >>>single segment by increasing the value of SHMVIRTSIZE. >>> >>>My question is WHY is it so?? Eventhough the database engine acquired >>>additional segments from OS, but the OS still have sufficient memory to >>>support the engine. >>> >>>Appreciate that if you could enlighten me on this. >> >>Not really, as I am not a systems person. However, from a DBA point of >>view, what you have done is exactly right. Lots of segments can slow >>access down, so consolidate them into one single segment. > > I'm "quoting" from memory, so don't shoot me if it's not exactly right: > HP-UX is designed so that each process can access N shared memory segments > from the current context. In order to access more than N segments, you need > to do a context switch, which is horrendously inefficient. Hence the > performance problems when you have too many segments. > > On HP-UX 10.20, N was 4. On HP-UX 11.0, it seems to be 6. I won't shoot you for the HP info (although I think N is 2 on 10.20), but I will shoot you for not reading the question. :-) Unless you know something about Sun buying HP and distributing HPUX as Solaris 2.7 that we don't. ;-) >>I have only found ONE platform that handles shared memory access well, >>and that is DEC Alpha..., er I mean Compaq Alpha..., er I mean HP Compaq >>Alpha. It all becomes clear now why HP bought Compaq, doesn't it. ;-) > > None of the other OSs seem to have too much of a problem, apart from AIX, > which used to have a hard limit of 10 segments, that could only be 256MB > each. Allegedly this has disappeared from AIX 5. ... and the aforementioned problems on HP & Sun..., but apart from that... :-) > I'd be interested to hear why you think Tru64 is particularly good...? Because it just works. No limits, no fiddling, no performance problems. Cheers, -- Mark. +----------------------------------------------------------+-----------+ | Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /| | Mydas Solutions Ltd http://MydasSolutions.com |///// / //| | +-----------------------------------+//// / ///| | |We value your comments, which have |/// / ////| | |been recorded and automatically |// / /////| | |emailed back to us for our records.|/ ////////| +----------------------+-----------------------------------+-----------+