Per the "UniData Troubleshooting Guide 2004.pdr"...
What should one look at when experiencing shared-memory problems?
Record the exact error message that appears.
Review the contents of ipclogs created. They will appear at the
directory level in the account
where the udt session died. An example name is UDT2285812c0.ipclog.
Look at what has changed.
Gather pertinent information about your current parameter settings,
both kernel and udtconfig.
Use the kp UniData-supplied UNIX level command to report kernel
parameters. The user must be
root for kp to work properly in some environments. When the parameter
value appears as -1, kp is
unable to determine the kernel setting. Most UNIX platforms provide the
sysdef command to
view the kernel parameter values. Use the man pages to see what options
are available for sysdef
in your environment. Also get a copy of your udtconfig parameters. These
parameters are located
in /usr/udXX/include/udtconfig, where XX is the UniData release number,
for example 60 or 61.
Use the showconf command to reports active settings. See Shared
Memory Errors for more
information.
smm cannot get the first GSM errno=22
smm needs to acquire the first shared-memory segment in order to build
the necessary control
tables. Acquiring the segment is not possible because shmmax is not
large enough. To correct this
problem and avoid other problems, it is best to correct shmmax base on
the following formula:
SHM_GNPAGES * SHM_GPAGESZ * 512 ? shmmax
Increase shmmax or decrease SHM_GNPAGES or SHM_GPAGESZ to satisfy this
formula.
Most Common Runtime Errors
1. No more entries in MI table in LCT - xxx
The MI table in an LCT is full. Each global page identifier occupies an
entry in the MI table. If
your global page size is too small and your application requires more
memory, the MI table
rapidly reaches its specified limit of entries. You can increase the
SHM_LMINENTS parameter
or you can create a larger global page (SHM_GPAGESZ) so more data can fit.
2. Error when attaching shm (xxx,xxx,xxx), errno=xxx
A process cannot attach a shared-memory segment. The shared-memory
segment specified is too
large, or the number of shared-memory segments attached to a process has
exceeded the system
limits. There are several parameters to consider for adjustment:
Try to increase shmseg to increase the number of segments that a
process can attach.
If you cannot increase shmseg, then increase SHM_GPAGESZ. You may need
to increase
shmmax to keep the formula accurate:
SHM_GNPAGES * SHM_GPAGESZ * 512 ? shmmax.
Bear in mind that the product of SHM_GNPAGES * SHM_GPAGESZ * 512 on AIX
should
result in segments no larger than 256 meg. Because of AIX shared memory
segment alignment
boundary rules, making it larger will cause the next segment to start at
the next 256 meg
boundary marker, thus losing the ability to make use of the intervening
space. Another way of
interpreting this is that a user process can attach 11 segments, each
beginning on a 256 meg
boundary for a total usuable space of 2,816 meg. Segments exceeding
256meg would reduce the
total number actually attachable and thereby "cheating" udt processes
from begin able to use this
full maximum possible address space.
In some cases you may need to increase SBCS_SHM_SIZE
3. Error when attaching shm (xxx,xxx,xxx), errno=22, bad attach on shmid
setshpcode
Increase SBCS_SHM_SIZE, and/or tune the parameters as noted in number 2.
4. Error when creating a shared memory segment (size=xxx), errno=xxx
The system cannot create a shared memory segment of the requested size.
Normally, the size is
larger than the maximum size of a shared memory segment in the system.
Adjust the UNIX
kernel shmmax parameter to increase the maximum size of a shared memory
segment. If shmmax
is already large, look for a programming problem which may be looping
and using excessive
shared memory. If the errno is 12, ENOMEM returned by shmget(), a shared
memory identifier
and associated shared memory segment are to be created, but the amount
of available memory is
not sufficient to fulfill the request. There is no clear indication
whether the system is out of
physical or virtual memory, but generally the system is out of swap
space. If the errno is 28, the
system has reached the limit of shmmni. Either increase shmmni, or
increase the
SHM_GPAGESZ size so an excess number of private segments are not created.
5. No more LCTs
You are out of LCTs (Local Control Tables). Increase NUSERS. This number
should be at least
1.2 * number of licensed users and up to 2 * number of licensed users,
if using many phantoms.
Remember to have semmnu ? 3 * NUSERS.
HTH,
Bill
Jeff Schasny said the following on 7/10/2009 8:35 AM:
Me too. Blew up immediately.
IBM P570 AIX 5.3 UV 10.2.4
Mecki Foerthmann wrote:
Well, if it makes you feel better, my test crashed out with a similar
error message as well.
The size shown was about half of what you had, otherwise the same
message.
UD 5.2 on Solaris 5.2 (I think).
I know it's old, but that's all they give me.
Symeon Breen wrote:
Ok I am very jealous now of all these quick times, when my one
crashed out
Can someone remind me (its been years since i did any udt config
stuff) what
should i be looking at to fix this error
Thanks
PS - i like this thread i think this can be of benefit to people to
fine
tune both code and their os and u2 configuration !
-----Original Message-----
From: Symeon Breen [mailto:[email protected]] Sent: 09 July 2009 14:04
To: 'U2 Users List'
Subject: RE: [U2] General guidelines on indexing
Unidata 7.1 (32bit) on redhat EL 3 64bit, on XEON E5335 with 4 gig
ram. \
Error when creating a shared memory segment (size=35682416), errno=22
Lol
Hmmm ?
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
