Re: HP shared memory limits
Posted in 1998
In article <1998032304401000.XAA04553@ladder01.news.aol.com>, SaTriGuy <satriguy@aol.com> writes >>:Okay, David. I might agree with you, but I would want to try it first. >>:Just remember that HP-UX 10.20 does not like to have more than two (2) >>:Informix virtual shared memory segments, remember? More than two (2), >>:and they get paged out. HP-UX problem, right? >> >>I believe that was more than 3 segments and they got swapped out. We always >>shot to tune the virtual seg size large enough so that additional virtual >>segments were never allocated under HP/UX. Since you commonly have a shared >>memory message segment along with the resident and virtual portion, 3 was the >>magic number. > >I think there's a bit of confusion here. > >It's not true that if there are more than two segments that the unused segment >gets swapped out. This has nothing to do with the swap file, or virtural >memory. > Correct. >The situation has to do with how shared memory segments are accessed in HP. HP >can support as many segments had you can fit into memory, However only two >segments are "active" by a unix process at any point in time. This means that >if an memory address is accessed that is not contained within one of the two >"active" shared memory segments, then an address violation will occur, the >kernel loads the basing information for that segment into one of the space >registers, and then the unix process regains control. This extra overhead is >why the performance degredation occurs, not because of page swapping. > I heard that it is the MMU which can only handle the protection bits for 3 shared memory segments at time. This sounds like what you are saying. >The probability that this will occur is fairly great if dynamically allocated >segments are added to the Informix engine because 1) the data pages are >contained in the resident portion, 2) the dictionary and other system structors >will tend to be located within the "fixed" virtural segment, and 3) if virtural >memory segments have been added, it is probably that the allocated memory used >by the sqlexec thread will be contained within one of the dynamically allocated >segments. Hence using the traditional 7.1/7.2 memory structure, the >possibility of degredation is fairly high. > >It should be noted that with recent versions of the engine, the resident and >"fixed" are being contained within a single OS shared memory segment that is >then "logically" split into two parts. This means that the probability of >switching between the multiple segments within the execution of the sqlexec >thread is minimized. This should decrease the impact of the dynamically >allocated segment on HP. > > >Madison Pruet -- David Williams Maintainer of the Informix FAQ Primary site (Beta Version) http://www.smooth1.demon.co.uk Official site http://www.iiug.org/techinfo/faq/faq_top.html I see you standin', Standin' on your own, It's such a lonely place for you, For you to be If you need a shoulder, Or if you need a friend, I'll be here standing, Until the bitter end... So don't chastise me Or think I, I mean you harm... All I ever wanted Was for you To know that I care