I'm looking at a customer site where they have many virtual memory segments.

IDS 9.20 UC3 on Solaris 2.6.(yes, I know it's very elderly)

Informix Dynamic Server 2000 Version 9.20.UC3 -- On-Line -- Up 5 days
06:09:01 -- 360448 Kbytes

Segment Summary:
id key addr size ovhd class blkused blkfree
801 1381386241 a000000 100663296 5456 R* 23483 1093
802 1381386242 10000000 50331648 2128 V 12288 0
503 1381386243 13000000 3145728 688 M 647 121
504 1381386244 13300000 16777216 1104 V 4096 0
505 1381386245 14300000 16777216 1104 V 4019 77
506 1381386246 15300000 16777216 1104 V 3948 148
507 1381386247 16300000 16777216 1104 V 4077 19
408 1381386248 17300000 16777216 1104 V 3854 242
409 1381386249 18300000 16777216 1104 V 3876 220
410 1381386250 19300000 16777216 1104 V 3797 299
411 1381386251 1a300000 16777216 1104 V 3268 828
412 1381386252 1b300000 16777216 1104 V 3774 322
413 1381386253 1c300000 16777216 1104 V 3703 393
414 1381386254 1d300000 16777216 1104 V 3675 421
415 1381386255 1e300000 16777216 1104 V 3794 302
416 1381386256 1f300000 16777216 1104 V 1553 2543
Total: - - 372244480 - - 83852 7028

Are there any known problems on elderly versions of Solaris with multiple
segments, as used to be the case with HP-UX 10.20? Are there general
problems with such an arrangement anyway?

thanks
Neil

Solaris is not all that vunurable to the IPCSHM issue...

"Neil Truby" <neil.truby@ardenta.com> wrote in message
news:37eottF5d5k7qU1@individual.net...
> I'm looking at a customer site where they have many virtual memory
segments.
>
> IDS 9.20 UC3 on Solaris 2.6.(yes, I know it's very elderly)
>
> Informix Dynamic Server 2000 Version 9.20.UC3 -- On-Line -- Up 5 days
> 06:09:01 -- 360448 Kbytes
>
> Segment Summary:
> id key addr size ovhd class blkused blkfree
> 801 1381386241 a000000 100663296 5456 R* 23483 1093
> 802 1381386242 10000000 50331648 2128 V 12288 0
> 503 1381386243 13000000 3145728 688 M 647 121
> 504 1381386244 13300000 16777216 1104 V 4096 0
> 505 1381386245 14300000 16777216 1104 V 4019 77
> 506 1381386246 15300000 16777216 1104 V 3948 148
> 507 1381386247 16300000 16777216 1104 V 4077 19
> 408 1381386248 17300000 16777216 1104 V 3854 242
> 409 1381386249 18300000 16777216 1104 V 3876 220
> 410 1381386250 19300000 16777216 1104 V 3797 299
> 411 1381386251 1a300000 16777216 1104 V 3268 828
> 412 1381386252 1b300000 16777216 1104 V 3774 322
> 413 1381386253 1c300000 16777216 1104 V 3703 393
> 414 1381386254 1d300000 16777216 1104 V 3675 421
> 415 1381386255 1e300000 16777216 1104 V 3794 302
> 416 1381386256 1f300000 16777216 1104 V 1553 2543
> Total: - - 372244480 - - 83852 7028
>
> Are there any known problems on elderly versions of Solaris with multiple
> segments, as used to be the case with HP-UX 10.20? Are there general
> problems with such an arrangement anyway?
>
> thanks
> Neil
>
>
>

Madison Pruet wrote:

> Solaris is not all that vunurable to the IPCSHM issue...

But Solaris is tuned for 4 segments


>
> "Neil Truby" <neil.truby@ardenta.com> wrote in message
> news:37eottF5d5k7qU1@individual.net...
>
>>I'm looking at a customer site where they have many virtual memory
>
> segments.
>
>>IDS 9.20 UC3 on Solaris 2.6.(yes, I know it's very elderly)
>>
>>Informix Dynamic Server 2000 Version 9.20.UC3 -- On-Line -- Up 5 days
>>06:09:01 -- 360448 Kbytes
>>
>>Segment Summary:
>>id key addr size ovhd class blkused blkfree
>>801 1381386241 a000000 100663296 5456 R* 23483 1093
>>802 1381386242 10000000 50331648 2128 V 12288 0
>>503 1381386243 13000000 3145728 688 M 647 121
>>504 1381386244 13300000 16777216 1104 V 4096 0
>>505 1381386245 14300000 16777216 1104 V 4019 77
>>506 1381386246 15300000 16777216 1104 V 3948 148
>>507 1381386247 16300000 16777216 1104 V 4077 19
>>408 1381386248 17300000 16777216 1104 V 3854 242
>>409 1381386249 18300000 16777216 1104 V 3876 220
>>410 1381386250 19300000 16777216 1104 V 3797 299
>>411 1381386251 1a300000 16777216 1104 V 3268 828
>>412 1381386252 1b300000 16777216 1104 V 3774 322
>>413 1381386253 1c300000 16777216 1104 V 3703 393
>>414 1381386254 1d300000 16777216 1104 V 3675 421
>>415 1381386255 1e300000 16777216 1104 V 3794 302
>>416 1381386256 1f300000 16777216 1104 V 1553 2543
>>Total: - - 372244480 - - 83852 7028
>>
>>Are there any known problems on elderly versions of Solaris with multiple
>>segments, as used to be the case with HP-UX 10.20? Are there general
>>problems with such an arrangement anyway?
>>
>>thanks
>>Neil
>>
>>
>>
>
>
>


--
Paul Watson #
Oninit Ltd # Growing old is mandatory
Tel: +44 1436 672201 # Growing up is optional
Fax: +44 1436 678693 #
Mob: +44 7818 003457 #
www.oninit.com #

"Paul Watson" <paul@oninit.com> wrote in message
news:cutjmk$5s9$1@thorium.cix.co.uk...
> Madison Pruet wrote:
>
>> Solaris is not all that vunurable to the IPCSHM issue...
>
> But Solaris is tuned for 4 segments

can you exapnd on that please, paul?

I'm not sure that really matters. Maybe a little bit, but not a major
problem.

The main reason that we had problems with HP in is the rate at which we
would try to access a memory address which was not currently based.
Basically there were only two machine registers which were basing shared
memory segments. The normal initial shared memory configuration was to have
one shared memory segment for the buffer pool, and the first virtual memory
segment. This fits rather nicely with the two SHM base registers.

The problem was when another segment was created because often the user's
stack would be in the new segment, the dictionary would be in the main
virtual memory segment, and the pages would be in the first. That would
mean that we would be constantly having to switch the contents of the base
registers, which cause a lot of extra process work. That's the reason why
on HP we keep the buffer and the first virtual segment in the same IPC
shared memory segment.

So it's not so much the number of segments that's really the root of the
problem, but rather the rate of change in what memory is going to be
accessed.

For the most part, the engine will access 1) the page buffer, 2) the thread
stack space.3) the dictionary structures, and 4) heap space. So once a
thread starts execution, we're going to tend to be using the same basing
register space over and over...


"Paul Watson" <paul@oninit.com> wrote in message
news:cutjmk$5s9$1@thorium.cix.co.uk...
> Madison Pruet wrote:
>
> > Solaris is not all that vunurable to the IPCSHM issue...
>
> But Solaris is tuned for 4 segments
>
>
> >
> > "Neil Truby" <neil.truby@ardenta.com> wrote in message
> > news:37eottF5d5k7qU1@individual.net...
> >
> >>I'm looking at a customer site where they have many virtual memory
> >
> > segments.
> >
> >>IDS 9.20 UC3 on Solaris 2.6.(yes, I know it's very elderly)
> >>
> >>Informix Dynamic Server 2000 Version 9.20.UC3 -- On-Line -- Up 5 days
> >>06:09:01 -- 360448 Kbytes
> >>
> >>Segment Summary:
> >>id key addr size ovhd class blkused blkfree
> >>801 1381386241 a000000 100663296 5456 R* 23483 1093
> >>802 1381386242 10000000 50331648 2128 V 12288 0
> >>503 1381386243 13000000 3145728 688 M 647 121
> >>504 1381386244 13300000 16777216 1104 V 4096 0
> >>505 1381386245 14300000 16777216 1104 V 4019 77
> >>506 1381386246 15300000 16777216 1104 V 3948 148
> >>507 1381386247 16300000 16777216 1104 V 4077 19
> >>408 1381386248 17300000 16777216 1104 V 3854 242
> >>409 1381386249 18300000 16777216 1104 V 3876 220
> >>410 1381386250 19300000 16777216 1104 V 3797 299
> >>411 1381386251 1a300000 16777216 1104 V 3268 828
> >>412 1381386252 1b300000 16777216 1104 V 3774 322
> >>413 1381386253 1c300000 16777216 1104 V 3703 393
> >>414 1381386254 1d300000 16777216 1104 V 3675 421
> >>415 1381386255 1e300000 16777216 1104 V 3794 302
> >>416 1381386256 1f300000 16777216 1104 V 1553 2543
> >>Total: - - 372244480 - - 83852 7028
> >>
> >>Are there any known problems on elderly versions of Solaris with
multiple
> >>segments, as used to be the case with HP-UX 10.20? Are there general
> >>problems with such an arrangement anyway?
> >>
> >>thanks
> >>Neil
> >>
> >>
> >>
> >
> >
> >
>
>
> --
> Paul Watson #
> Oninit Ltd # Growing old is mandatory
> Tel: +44 1436 672201 # Growing up is optional
> Fax: +44 1436 678693 #
> Mob: +44 7818 003457 #
> www.oninit.com #

Neil Truby wrote:

> "Paul Watson" <paul@oninit.com> wrote in message
> news:cutjmk$5s9$1@thorium.cix.co.uk...
>
>>Madison Pruet wrote:
>>
>>
>>>Solaris is not all that vunurable to the IPCSHM issue...
>>
>>But Solaris is tuned for 4 segments
>
>
> can you exapnd on that please, paul?
>

Solaris memory management code is optimised for 4 segments, there is an
Sun whitepaper on this and you should be able to download it from Sun, I
only have hard copy. Without finding the paper and from memory it is
the memory segment control structures

But Madison is right large number of segments will not stop Solaris from
running and have, from Informix's viewpoint, only a minor effect on
performance.

--
Paul Watson #
Oninit Ltd # Growing old is mandatory
Tel: +44 1436 672201 # Growing up is optional
Fax: +44 1436 678693 #
Mob: +44 7818 003457 #
www.oninit.com #