Re: HP shared memory limits

>: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. 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. 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