topic Re: SYSGEN in Operating System - OpenVMS

SYSGEN

FOX MULDER_2 — Tue, 20 Mar 2007 07:08:11 GMT

Hi,
Can you please let me know how to find process that are swapped out of memory?

The users sessions are getting hanged often & CPU usage is ~ 100%,so I took a lok at balsetcnt...

The value of MAXPROCESSCNT is 521 & BALSETCNT is 207...which I find is not correct.
Total memory is ~ 1GB

But,when I run
$ Show mem/slots

swapped is zero.
So,I guess no swapping is occuring.
Is the value of balsetcnt right or should be changed to 519....Please advice..

Thanks,

Re: SYSGEN

Wim Van den Wyngaert — Tue, 20 Mar 2007 07:27:18 GMT

Bal set should be maxproc - 2. So 519.

Help show sys/state will help you.
The state you need is RWSWP but it could be one of the others too.

Wim

Re: SYSGEN

Wim Van den Wyngaert — Tue, 20 Mar 2007 07:29:47 GMT

And this explains the states.

http://ftp.openvms.compaq.com/doc/83final/6552/6552pro_016.html

Wim

Re: SYSGEN

Uwe Zessin — Tue, 20 Mar 2007 07:48:45 GMT

It's been a long time I have played with this and I am a bit short on time - others can be more helpful, but allow me a quick warning:

Please do NOT blindly raise BALSETCNT !
You risk that your system does not boot.
This can be fixed via conversational boot, but you do need access to the console.

Re: SYSGEN

Steven Schweda — Tue, 20 Mar 2007 08:21:18 GMT

I've heard that there's this AUTOGEN thing
which can help when changing SYSGEN
parameters.

Re: SYSGEN

Uwe Zessin — Tue, 20 Mar 2007 08:26:32 GMT

I heard too ;-)

But maybe it was AUTOGEN which lowered BALSETCNT because there is a large VA configured and the system might otherwise run out of S0 space. I have seen this on OpenVMS VAX V7.1 many years ago and I don't recall what platform FOX is working on.

Re: SYSGEN

Hoff — Tue, 20 Mar 2007 08:34:03 GMT

I would encourage a system-wide evaluation of resources, current load, system capabilities, and local requirements.

Based on the available information, the system requires some tuning, additional hardware, reduced load, replacement, or a combination.

Looking at the slots and processes is a factor, but there's a whole lot more information required. It's not clear (to me) around the thought sequence that led from from hung processes and max CPU load to the balance set. (You're going to have to explain that.)

Start with either the T4 tools or a monitor recording pass (or both), and start gathering baseline data on the current system load. And at what the application(s) are doing, and at the particular hangs and aberrant behavior.

Given the discussion of the balance set slots and the reported physical memory, I have to assume that this is an OpenVMS VAX box, and specifically VAX 6000 Model 600, VAX 7000, or VAX 10000 series box. Old and slow. Big and power-hungry, too. By coincidence, I posted some details of VAX XPA and XVA just a week ago, over at: http://64.223.189.234/node/131

Do you have the source code for your applications, or a way to move off these boxes? You're working very near or even at the architectural limits of VAX here, which means that if tuning doesn't work, you are left to either off-load or re-schedule or migrate the applications to OpenVMS Alpha or OpenVMS I64. An rx2660 would likely greatly outperform this VAX box, for instance.

Stephen Hoffman
HoffmanLabs

Re: SYSGEN

labadie_1 — Tue, 20 Mar 2007 08:37:46 GMT

A swapped process can be in a state like HIBO or LEFO (even COMO).

But first some tuning is needed, and may be some memory should be added.

Re: SYSGEN

FOX MULDER_2 — Tue, 20 Mar 2007 09:03:22 GMT

Thanks to all for prompt replies.

The problem is a suspended process is taking ~100% CPU usage.

There is a parent process which is creating a sub process & after a while the sub process becomes non existent but when monitored using mon proc/topcpu that process is consuming 100% cpu usage.

I guess that is the reason other user is getting hanged sessions.

The VMS box is DS20E running on 7.3-2.
It was working fine but only after patching with update 11....these problems are occuring.

So,I while going through sysgen parameter noticed balsetcnt.....

Any suggestion would be very helpful.

Thanks

Re: SYSGEN

Jan van den Ende — Tue, 20 Mar 2007 09:41:58 GMT

Fox,

so it is Alpha - that is good news.
The balsetcount vs. VA problem does not apply.

My guess: either someone changed SYSGEN params without using AUTOGEN, or, in MODPARAMS MAXPROCESSCNT as well as BALSETCNT are hard-coded values, and the AUTOGEN warnings were ignored.
In the latter case, simply remove BALSETCNT from modparams.dat (and files invoked by it, if applicable) and let AUTOGEN recalculate it.

Probably it is best to first do a
@AUTOGEN SAVPARAMS TESTFILES FEEDBACK
which reports, does not yet change anything, and review the report.

hth

Proost.

Have one on me.

jpe

Re: SYSGEN

Hoff — Tue, 20 Mar 2007 10:49:15 GMT

Stay away from SYSMAN PARAMETER, AUTOGEN and MODPARAMS.DAT for the present. (Please don't take that the wrong way -- while there might well be a parameter issue here -- it appears far too early to be tweaking parameters.)

A "suspended" process accumulating CPU would initially appear to be a lost I/O, or lost quota, or other kernel-level error. A much more detailed look at the process and at the loop is going to be required here. This may well prove to be a bug in the UPDATE kit, for instance.

If these systems have a support contract in place, you will want to avail yourself of its benefits; to contact the HP customer support center.

Re: SYSGEN

Wim Van den Wyngaert — Tue, 20 Mar 2007 10:58:43 GMT

"sub process becomes non existent but when monitored using mon proc/topcpu that process is consuming 100% cpu usage."

Is the process gone or isn't it ? Use sh proc/id=xxx to verify. Is mon proc/topcpu giving the same pid for the process ? What do you find in process accounting ? Operator log ? Audit trail ?

Did you reboot after installing the patches ?

Are all slots taken when you do show mem/slot ?

Wim

Re: SYSGEN

Rob Young_4 — Tue, 20 Mar 2007 11:01:21 GMT

Thanks to all for prompt replies.

The problem is a suspended process is taking ~100% CPU usage.

---

See this thread for similar spinning process
discussion:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1105743

Re: SYSGEN

Andy Bustamante — Tue, 20 Mar 2007 11:02:22 GMT

If it worked before the ECO and doesn't work after . . .

Did you install the patch with /save_recovery? Type:

$ PRODUCT SHOW RECOVERY_DATA

You can use PRODUCT UNDO PATCH to restore your system to it's previous state, this can be a quick way to eliminate the ECO as the cause or confirm the cause issue.

I've used UNDO and it really annoys the Windows types.

Andy

Re: SYSGEN

Hoff — Tue, 20 Mar 2007 14:12:35 GMT

>>>
I've used UNDO and it really annoys the Windows types.
<<<

Microsoft Windows XP restore points have provided this capability for some time now.

Re: SYSGEN

Jess Goodman — Tue, 20 Mar 2007 16:23:55 GMT

A truly suspeneded process should not be using the CPU. Do SHOW SYSTEM and see what state the process is really in. Also go into ANALYZE/SYSTEM and SHOW that PROCESS there.

DCL's SHOW PROCESS command gives the highly-misleading message "process is suspended" if you use it on a process stuck in any of the MWAIT states (MUTEX, RW*) or for any process that has the delete-pending bit set.

Re: SYSGEN

Uwe Zessin — Wed, 21 Mar 2007 00:42:26 GMT

> Microsoft Windows XP restore points have provided this capability for some time now.

For the whole system, yes. But even on Windows 2000 I was able to roll back (uninstall) a single patch.

Re: SYSGEN

FOX MULDER_2 — Wed, 21 Mar 2007 04:59:46 GMT

Hi,
When I issue the command
$ sh proc/id=XXXXXXX
The message appears suspended and after a while it becomes non existent but,when
$ sh sys
is issued that process is listing as current.
Each time the process becomes non-existent, anew sub-process is created.This event is repeating.

Memory slots are not taken completely,there are free slots available.
I did install the patches using /sav qualifier.

Once the processes attains 100% CPU usage,it goes into suspended mode....How does this happen?
I think for this reason other users are affected.

Thanks.

Re: SYSGEN

Volker Halle — Wed, 21 Mar 2007 05:33:22 GMT

Hi,

SHOW PROC/ID=xxx may issue a 'supended' message, if it can't get data from the remote process. Only SHOW SYS will tell the true status of that process.

Do you have a system with more than 1 CPU ? Only in that case, you could see another process in a CUR state - otherwise, it will always be your process, in which you have issued the SHOW SYS command.

Are you saying, that there is some process in your system, which seem to be creating sub-processes, which then consume 100% of CPU time and then disappear ?

You can look at accounting to find out, why those subprocesses disappear (exit status) and how long they were active and how much CPU they consumed:

$ ACC/FULL/SINCE=time/TYPE=PROCESS/PROCESS=SUBPROCESS

Volker.

Re: SYSGEN

Wim Van den Wyngaert — Wed, 21 Mar 2007 05:34:11 GMT

What is "after a while" ?
I've seen process termination taking 5 seconds (due to cleaning up ?).

Did you reboot ?

Wim