Re: HP HW/OS and Shared Memory Segments Problem...

Greg Moye wrote: > > Does anybody know if current HP hardware (and HP-UX) still has that > nasty problem where >2 Shared memory segments can *really* slow things > down?? > > If so, is it scheduled to go away anytime soon?? > > TIA - Greg OK, I've been researching this HP shared memory degradation thing, determined to get to the bottom of it, so I'll answer my own question: There is a two element cache local to *each* HP-UX process that contains the addresses of the two most recently referenced shared memory segments for that process that is currently running on it. When the process blocks, this info and other state information is saved as part of the context switch. The next process (whatever it is) is switched in, it's state info is loaded onto the CPU and then dispatched. So, what this boils down to is that the degradation problem occurs only when an *individual* process (like a CPUVP oninit) needs to reference 3 or more shared segments in rapid fire order, i.e. many times within a single dispatcher time quantum. This is exactly what happens when Informix dynamically allocates an additional shared segment for it's virtual pool. The problem can be skirted with Informix by configuring the database to get one very large virtual pool shared segment at startup time, thus guaranteeing that no dynamic segments will be allocated. The downside to this solution is that you may have to do one of two undesirable things: 1. Allocate liberally, thus limiting the number of instances per box (due to shared memory max limits) or 2. Allocate more conservatively, but monitor more closely, and bounce the instance asap after any dynamic allocations. Typically only big systems will run into these potential flexibility problems. Greg