CTLIMGLIM sysgen parameter

[Sk Noorul Hassan]

CTLPAGES determines the size of the pool and CTLIMGLIM limits the amount of the pool that can be used for the image control structures.

We are getting an error "%SYSTEM-F-INSFMEM, insufficient dynamic memory" in our VAX server 4105A running Open VMS 7.1 and supporting SCADA application.

The current setting of CTLPAGES = 100 & CTLIMGLIM = 35 . Will it be a good idea to increase CTIMGLIM to 60 and what would be it's impact on application on wider aspect.



Pls suggest ...

[Kris Clippeleyr]

Hi,

I wouldn't touch those two system parameters.
I would rather investigate the quota of the process running this application. Check for PGFLQUOTA, either in SYSUAF for the account, or the system parameters PQL_MPGFLQUOTA & PQL_DPGFLQUOTA. Increase them as necessary.

OTOH, your paged pool might be too small, or too fragmented, do a SHOW MEM/POOL and check the PAGEDYN parameter.

According to "the Wizard":
The INSFMEM message can arise from a variety of sources: culprit quotas and parameters can include PGFLQUOTA, PAGEDYN, NPAGEDYN, and potentially CTLPAGES and CLISYMTBL.

Regards,
Kris (aka Qkcl)

[Kris Clippeleyr]

Just remembered that you've already asked a similar question a while back.

See the discussion in thread:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1119000261008+28353475&threadId=876629

Regards,
Kris (aka Qkcl)

[Volker Halle]

Hi,

the difference between CTLPAGES and CTLIMGLIM guarantees a minimum number of pages exclusively for EXE$ALOP1PROC usage. By just increasing CTLIMGLIM, you would reduce the P1 pool size for other allocations from the process allocation region in P1 space.

I would strongly suggest to FIRST find out, which kind of pool is exhausted, when you see the INSFMEM error message. Can you determine (from the error message), which routine in your application is generating this message and/or which routine call has failed with this status ?

You have entered a couple of threads in this forum in the past for the same kind of problem and I've tried to provide troubleshooting information. Unfortunately, the information requested has not yet been supplied.

Please have a look at your previous entries and provide the information.

Volker.

[Antoniov.]

I'm with Kris.
I strong discourage changing CTIMGLIM value.

Antonio Vigliotti

[Sk Noorul Hassan]

Hi, Thanks for your reply.

1."%SYSTEM-F-INSFMEM, insufficient dynamic memory" -- It is a SCADA system, getting data from field through FEPs. My system talks to FEP over TCPIP. We get this error on few occasions(not every time) when my system locks up due to FEP processes going to MWAIT state. As per the previous suggesions I have checked SH MEM/POOL, which looks ok, the ratio of free/used is perfect.

2. SYSTEM-W-EXLNMQUOTA, logical name table is full -- This perticular error is comming when operator is trying to generate the report( the subsystem creates it's own process, mailbox, logical printer channel before printing)

All the system processes run from same account.

Physical memory is 128 MB, WSMAX is 16K, WSextent of the account is 8K, JTquota is 1K, PGFLQUO is 40000

Output of SH MEM/POOL

NONPAGED DYN MEM -18579968(total), 6691840(free), 11888128(in use), 4315968(largest)

Paged Dyn Mem - 8763392(total), 7115376(free), 1648016(in use), 7098224(largest)

Pls suggest, how to go abt it.

[Sk Noorul Hassan]

Hi, In continuation with my previous question...

My PQL_DPGFLQUOTA is 32768 & PQL_MPGFLQUOTA is 16384 .

[Antoniov.]

Help insfmem hints increase nonpaged pool memory. You have 18Mb of memory and 6Mb of free memory. I feel your memory is enough. For me you can focus on user/process quotas.
Increase PGFQUOTA and JTQUOTA.

Antonio Vigliotti

[Volker Halle]

Hi,

to prevent the EXLNMQUOTA error, consider to increase the JTQUOTA of the user account:

UAF> MOD user/JTQUOTA=2000

The users need to logout and login again for the new Job Table quota to become effective.

Your nonpaged pool seems to be currently o.k., did you also check nonpaged pool AFTER the error has happened ?

In your previous reply, you talk about your FEP processes going into MWAIT state. If your system is in that state, could you use SDA to check those processes ?

$ ANA/SYS
SDA> READ SYS$SYSTEM:SYSDEF.STB
SDA> SET PROC/IND=
SDA> SHOW PROC
SDA> EXA PCB+PCB$L_EFWM

You can also issue those commands against a forced crash, which you should take, if you need to reboot your system anyway to recover from such a situation.

Volker.

[Volker Halle]

Please also consider to check the process pool (P0/P1) of those processes with:

$ sho proc/mem/id=

Note that the INSFMEM error could also happen, if enough pool is available, but the requested byte size is somehow corrupt and exceeds available pool.

Which version of TCPIP or UCX are you running ? Does UCX SHOW COMM/MEM show buffer waits or drops ?

Volker.

[Sk Noorul Hassan]

Hi,

UCX version is 4.2 on vms 7.1. UCX sh comm/mem does not show any waits/drops also.

What exactly should be the value for PGFLQUO and WSextent?

[Volker Halle · Accepted solution]

Hi,

please check UCX SHOW COMM/MEM again, after the problem (INSFMEM) has happened.

There are no 'good or bad' absolute values for PGFLQUOTA or WSEXTENT. It all depends on the resource need of your application.

For monitoring page file quota usage, look at the remaining pagefile quota of the running processes with SHOW PROC/QUOTA/ID=

Paging file quota: will list the no. of pages remaining for the process to be charged against PGFLQUOTA. If it's a small (in relation to PGFLQUOTA) value, increase PGFLQUOTA for the user, e.g. if only 10% of pagefile quota is free, double PGFLQUOTA.

WSEXTENT is different. Process workingsets can grow beyound WSQUOTA, if the process is heavily paging and enough free pages are available. Check with SHO SYS (last column), if any of those processes have a workingset size near WSQUOTA or even bigger than WSQUOTA. Are you seeing lots of pagefaults ($ MONI PROC/TOPFAULT) for those processes ? If not, don't bother to increase WSEXTENT.

Volker.

[Sk Noorul Hassan]

so, I can increase the Pgflquo to 80000 from current 40000 and Jtquota to 2000 from 1024 and can observe the performances.

Volker, Kris and Antonio thanks for the suggestions

[Robert_Boyd]

Just as a side note about JTQUOTA - I have worked with some applications where it was much easier to do interprocess communication using only DCL by using the Job Logical Name Table. For the usernames involved with those applications I usually boosted JTQUOTA to 40000 or 60000. There is almost no cost for boosting the quota. On many systems it was easier to boost the quota for all the users so as to avoid this problem.

There's very little good reason to limit the size of the JOB logical name table other than the fact that it might become a resource problem if it were completely unbounded. However -- there's no practical limit on the process logical name tables other than virtual address space. I've often found the default JTQUOTA limitation to be more of a pain than a help. This is especially true that for performance reasons it is much better to populate most of the logical names a process might need into the JOB table if all the subprocesses in the job tree are going to share the same translations.

Robert

[Antoniov.]

I suspect your UCX version is too old.
On V7.x of vms, usually I see UCX V5.x

Antonio Vigliotti

[David Jones_21]

Concerning JTQUOTA, as the job table is shared, won't lots of entries in all the job tables add a corresponding number of entries to the system lnm hash table?

[Ian Miller.]

note that JOB logical names are created in paged pool which is why there is a process quota to limit the amount of a system wide resource (paged pool) used by a process.

process logicals are created from the process dynamic memory region sized by CTLPAGES.

[Jan van den Ende]

Re Antonio:

Starting VMS 7.2 you are right: UCX (from there on officially TCPIP Servives) MUST be V5+

But the normal and default UCX up until VMS 7.1,x is UCX V4.x
TCPIP V5 _CAN_ be installed on VMS 7.1-some.
I am not sure of the exact value of "some" though.

Proost.

Have one on me.

jpe

[Jan van den Ende]

Summing up on low JTQUOTA:

the mechanism in itself, and the tight settings, were just NEEDED in the days of scarse and expensive memory.
Nowadays if in any doubt just be generous.
The cost of investigating deeper is manyfold the cost of any potential extra memory.

Proost.

Have one on me.

jpe

[Ian Miller.]

Setting JTQUOTA to 0 removes
the limit.