Howto verify limit specified that can be used per process ?

[De Gucht Helga]

HPUX B.11.00
How can we verify if there has been a limit specified that can be used per process ?
Please advise asap.

[A. Clay Stephenson]

Your question is unclear as to WHICH limit but the answer is probably ulimit -a.

[Martin Burnett_2]

Hello,

There all all kinds of limits on processes. I am afraid you are going to have to be more sepcific. For instance consider the following kernel parameters:

maxfiles sets the soft limit for the number of files a process is allowed to have open simultaneously

maxdsiz and maxdsiz_64bit specify the maximum data segment size, in bytes, for an executing process

max_thread_proc specifies the maximum number of threads a single process is allowed to create

nproc specifies the maximum number of processes that can exist simultaneously on the system at any given time

The timeslice interval is the amount of time one process is allowed to run before the CPU is given to the next process at the same priority

The list goes on and on. Take a look at http://docs.hp.com//hpux/onlinedocs/os/KCparams.OverviewAll.html

Thanks for participating in the forums,

Martin
Chaos reigns within. Reflect, repent, and reboot. Order shall return.

[James R. Ferguson]

Hi:

Have a look in the user's profile for a 'ulimit'. Also, system-wide, with SAM or 'sysdef' (on 10.20), or 'kmtune -l' on 11.x, look at the kernel parameters 'maxuprc' and 'max_thread_proc'.

Regards!

...JRF...

[De Gucht Helga]

The result of this command is: ( ulimit -a )

time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 65536
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 1024

How can we verify if a process fails to allocate enough ( new ) memory.
it could be that the process has a shortage in memory and therfore maybe hangs .
Please advise ...

[De Gucht Helga]

max_thread_proc 256
maxuprc 256

- - -
Parameter Value
===============================================================================
NSTRBLKSCHED 2
NSTREVENT 50
NSTRPUSH 16
NSTRSCHED 0
STRCTLSZ 1024
STRMSGSZ 65535
acctresume 4
acctsuspend 2
aio_listio_max 256
aio_max_ops 2048
aio_physmem_pct 10
aio_prio_delta_max 20
allocate_fs_swapmap 0
alwaysdump 0
bootspinlocks 256
bufcache_hash_locks 128
bufpages (NBUF*2)
chanq_hash_locks 256
create_fastlinks 1
dbc_max_pct 30
dbc_min_pct 5
default_disk_ir 1
desfree 0
dnlc_hash_locks 64
dontdump 0
dskless_node 0
dst 1
eisa_io_estimate 0x300
eqmemsize 15
fcp_large_config 0
file_pad 10
fs_async 1
ftable_hash_locks 64
hdlpreg_hash_locks 128
hfs_max_ra_blocks 8
hfs_ra_per_disk 64
hpux_aes_override 0
initmodmax 50
io_ports_hash_locks 64
iomemsize 40000
km_disable 0
ksi_alloc_max (NPROC*8)
ksi_send_max 32
lotsfree 0
max_async_ports 50
max_fcp_reqs 512
max_mem_window 0
max_thread_proc 256
maxdsiz 0XC0000000
maxdsiz_64bit 0X400000000
maxfiles 1024
maxfiles_lim 2048
maxqueuetime 0
maxssiz 0X04000000
maxssiz_64bit 0X04000000
maxswapchunks 4096
maxtsiz 0X40000000
maxtsiz_64bit 0X100000000
maxuprc 256
maxusers 128
maxvgs 10
mesg 1
minfree 0
modstrmax 500
msgmap (2+MSGTQL)
msgmax 8192
msgmnb 16384
msgmni 50
msgseg 2048
msgssz 8
msgtql 40
nbuf 0
ncallout 4096
ncdnode 150
nclist (100+16*MAXUSERS)
ncsize (NINODE+VX_NCSIZE)
ndilbuffers 30
netisr_priority -1
netmemmax 0
nfile (16*(NPROC+16+MAXUSERS)/10+32+2*(NPTY+NSTRPTY+NSTRTEL))
nflocks 200
nhtbl_scale 0
ninode 4000
nkthread 2048
nni 2
no_lvm_disks 0
nproc (20+8*MAXUSERS)
npty 200
nstrpty 200
nstrtel 60
nswapdev 10
nswapfs 10
nsysmap ((NPROC)>800?2*(NPROC):800)
nsysmap64 ((NPROC)>800?2*(NPROC):800)
num_tachyon_adapters 0
o_sync_is_o_dsync 0
page_text_to_local 0
pfdat_hash_locks 128
public_shlibs 1
region_hash_locks 128
remote_nfs_swap 0
rtsched_numpri 32
scroll_lines 100
scsi_maxphys 1048576
sema 1
semaem 16384
semmap (SEMMNI+2)
semmni 70
semmns 200
semmnu 30
semume 10
semvmx 32767
sendfile_max 0
shmem 1
shmmax 0X40000000
shmmni 200
shmseg 120
st_ats_enabled 1
st_fail_overruns 0
st_large_recs 0
streampipes 0
swapmem_on 1
swchunk 2048
sysv_hash_locks 128
tcphashsz 0
timeslice (100/10)
timezone 420
unlockable_mem 0
vnode_cd_hash_locks 128
vnode_hash_locks 128
vps_ceiling 16
vps_chatr_ceiling 65536
vps_pagesize 4
vx_maxlink 32767
vx_ncsize 1024
vx_ninode 0
vx_noifree 0
vxfs_max_ra_kbytes 1024
vxfs_ra_per_disk 1024

[De Gucht Helga]

maximum number of simultaneous user processes that any given user can be running.

should not be the problem

we are also only using 5 threads for arserverd
so the 256 is for both
seemingly
not causing a problem.

?? any ideas .
Tnx

[A. Clay Stephenson]

Hi:

I think you need to start over and tell us what problems you are observing rather than asking about limits. You mentioned the process not having enough memory and somehow hanging; that would be most unusual; when a UNIX process can't allocate enough memory (errno = 13) it almost always dies. Hangs are usually endless loops or deadlocks (waiting for resources that never become available).

You could be running out of swap space but again something would die but not hang.

[De Gucht Helga]

sorry if I failed to explain the situation.
The behaviour we see is that when the using the admin tool the admin launches an export
of a very limited piece of workflow ( being some active links only )
and the arserverd which is the server process of Remedy ( and which is multithreaded ) shows "running" but refuses connections
when you try to connect to the server you get RPC timeouts, connections are refused, the server process hangs and it does not get out of this behaviour.
For the users connected or trying to connect they get the following error : "ARERR [90] Cannot establish a network connection to the AR System : remedy:
RPC: miscellaneous tli error - System error [No error]"
The only thing you can do is stop and restart the arserverd process and than it works fine again. Normal user activity does not give any problems, but launching the export hangs the process.
In the API log you see the Arexport being launched and after this the proces starts not responding and the next line you see in the log is the RPC set to 0000 so it has lost it's connection.
In the arerror.log we get following errors :
"
Tue Apr 16 10:17:52 2002 0 : AR System server terminated when a
signal/exception was received by the server (ARNOTE 20)
Tue Apr 16 10:17:52 2002 10
Tue Apr 16 10:17:52 2002 0 : AR System server terminated -- fatal error
encountered (ARNOTE 21)
Tue Apr 16 10:19:00 2002 0 : AR System server terminated normally (ARERR
32)
Tue Apr 16 10:19:00 2002 ARMonitor
Tue Apr 16 10:19:00 2002 0 : AR System server terminated when a
signal/exception was received by the server (ARNOTE 20)
Tue Apr 16 10:19:00 2002 15
"
The signals are 10 and 15.
No one is accidentaly killing the arserverd process using a faulty PID.
I have contacted Remedy and they say the errors 10 and 12 are suggesting a maxdsiz problem.
The maxdsiz is at current set to 512 MB.
They suggest it is a problem with memory but the machine has 1 GB of memory.
That is why I am looking to find how this would be possible.

[De Gucht Helga]

Correction:the signals 10 and 15 suggest a maxdsiz problem according to Remedy. ( not 12 )

[A. Clay Stephenson]

Hi:

Sorry, I mistyped when I said errno=13 was a maxdisiz problem that should have been errno = 12 (ENOMEM). If you see that errno, that is almost always maxdiz coming in to play. In your case however, maxdsiz = 0xC0000000 (~ 3.2GB - I very much doubt that is your problem.)

Now having that, errno has nothing (or at least very little) to do with signals. Signal 15 is a very normal termination signal but signal 10 (SIGBUS) almost always refers to bug in the code itself. Generally, a system call is pointing to a bogus address.

If is it possible, you need to put some ERR=$?
statemenets in your scripts. $? returns the status of the last executed command and in well-behaved code that is set to indicate the value of errno.

[Bill Hassell]

Memory allocation problems are VERY common to 32bit applications. maxdsiz is a protective fence. It can be set to any 32bit limit, typically 1750 megs. Note: HP-UX is a virtual memory design so physical RAM has very little to do with the amount of RAM a program can request. If there isn't enough RAM, the system just pages out to the swap area.

Now Remedy needs to be more explicit: is the RAM error truly maxdsz (ie, it refers to the program's local data area as in malloc requests, or does it refer to shared memory)? In either case, I would make sure maxdsiz is set to at least 940 megs and if Remedy can use large shared memory, increase shmmax. And make sure you have about 2Gb total swap space available (swapinfo -tm).

Then you'll need to read the two white papers on process management and memory management found in the /usr/share/doc directory. Also, 1Gb of RAM is pretty small for a system like remedy--you'll probably have better results with 2Gb or 3Gb of RAM.