Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

EXTSHM=ON

Status
Not open for further replies.

bjverzal

MIS
Apr 26, 2001
964
US
I am already on the AIX-L news list. There has not been a whole lot of information on this topic, so I thought I'd paste it here.

Does anyone know what the benefits/disadvantages are of setting the EXTSHM=ON are in a DB2 environment on a switch-attached S80 ? 16GB 12-way system.

Thanks, Bill.
 
Hi Bill,

There's actually a Tek-Tips forum for DB2 -- have you asked your question there?

forum178 -- IBM DB2 forum

Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.
 
Extended Shared Memory (EXTSHM)

By default, each shared memory region (whatever its size),
always consumes a 256 MB region of address space.
Operating system version 4.2.1 and later implements
Extended Shared Memory, which allows for more granular
shared memory regions that can be in size of 1 byte up to
256 MB. However, the address space consumption will be
rounded up to the next page (4096 byte) boundary.
Extended Shared Memory essentially removes the limitation
of only 11 shared memory regions.

This feature is available to processes that have the
variable EXTSHM set to ON (EXTSHM=ON) in their process
environment. There is no limit on the number of
shared memory regions that a process can attach. File
mapping is supported as before, but still consumes
address space that is a multiple of 256 MB (segment size).
Resizing a shared memory region is not supported in
this mode. Kernel processes will still have the
same behavior. Without this environment variable set,
eleven 256 MB regions are available.

Extended Shared Memory has the following restrictions:
I/O support is restricted in the same manner as for
memory-mapped regions.
Only uphysio() type of I/O is supported (no raw I/O).
These shared memory regions cannot be used as
I/O buffers where the unpinning of the buffer occurs
in an interrupt handler. For example, these regions
cannot be used for async I/O buffers.

The segments cannot be pinned using the plock()
subroutine because memory-mapped segments cannot
be pinned with the plock() subroutine.

Not sure if this helps or not...didn't actually answer your
question directly...
 
I'll look into the DB2 thread. I am more curious about the impact on the system from a UNIX perspective, than the DB2 side of things.

aixqueen: Thanks for the tech info - and yup - it doesn't help the question have alot, but it is indeed some geeky stuff that is good to know. Thanks for all of the goopy details.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top