many com processes

[simon_164]

Dear guys, why we see many com processes, all these processes are waiting to be current ?

[Garry Fruth · Accepted solution]

Processes in a COM state are waiting to be CUR on a processesor. They may be waiting because
all the CPUs are busy with higher priority processes.

There may be a lot of them because there is a lot of work to do and they are competing for a limited number of CPUs. Or, perhaps the base priority of some of the processes is low compared to a cpu-bound higher priority process.

Process priority and how processes are scheduled to CPUs is not too difficult a subject, but it warrants more than a short answer (sorry, perhaps the next person may give a more thorough explaination).

[Hein van den Heuvel]

Yes. COM is Computable. Ready to go.
Buy more CPU's :-).

Now if you have lots of COM then you would expect a 100% busy system. If this is not the case, it could be a timing fluke.
Some timer, or (common) event flag flipping and changing several processes (including monitor ?!) from waiting to runnable. Each of those might only need a millisecond to run, but you happen to look just when they all become runnable.
This may sound like unlikely... but it happens.

Hein.

[Lawrence Czlapinski]

simon, It is normal for some of our systems to sometimes have a high number of COM processes even for several minutes or more.
First you have to have some idea of what is normal CPU usage for the processes that are getting the CPU usage. Are one or two processes getting most of the CPU time?
1. I monitor our systems with AVAIL_MAN. I have frequently observed high CPU queues on some of our systems. When it happens I bring up the CPU screen for that system. This situation is usually due to higher priority tasks being computable as others have stated. So the lower priority tasks have to wait. CPU usage will show as 99 or 100%. The key is how long does the CPU stay maxed out and does it cause performance problems. It can stay this way for minutes and still not be a problem depending on well the priorities were defined.
2. Sometimes a process will become a CPU hog, tieing up 90-100% of a CPU. If a process (or parent/subprocess) is hogging the CPU, you may have a runaway process. Usually it is a process running a DECwindows session from a PC. Something funky happens to DECwindows.
3. Occasionally a CPU hog can happen with a non-Decwindows process(es). We haven't figured out why it happens. You then have to make an educated guess as to whether this is normal for the process or something may have gone wrong. If I suspect something has gone wrong I call the Production Applications Support person(s). We also developed a crash_dump.com procedure that the responsible production applications support person can run on certain systems that they are responsible for to help them pinpoint the cause(s).
4. If the high CPU queue is causing problems, you need a knowledge of the system and the companies priorities. Is this a temporary problem or a chronic problem?
If it is a chronic problem, what is the normal CPU usage? If it is always over say 90% CPU usage, you may not have enough CPU power and will have to investigate the reasons for the high CPU usage. You may have too many interactive compute intensive processes for the CPUs. The CPU intensive jobs may all be running during primary work hours. You may have high CPU usage jobs running as interactive jobs which should be running as lower priority batch jobs.
Lawrence

[Antoniov.]

Simon,
usually many com processes means cpu busy but it's not absolute law.
If you have a lof of processes which don't make i/o (unusually) you can see them in com state.

Antonio Vigliotti

[Robert Gezelter]

Simon,

If system response times are reasonable, having many processes in the COM state can be unimportant. High numbers of processes in COM can also be the result of:
- running many batch jobs in the background at a low priority,
- having very efficiently configured processes (I have one procedure that is very efficient efficient at using the system, it can make effective use of the system on a totally idle machine, if I run it as a batch job, any otherwise idle CPU time will be soaked up)
- one or more inefficiently configured or coded applications
- a run-away process or processes in some form of a loop

The first two possibilities in the preceding list are completely normal, the last two are indicative of problems.

Troubleshooting these problems requires determining where the CPU time is being consumed, and is the usage correct. Using nothig more than the tools available in a base OpenVMS system, you can:

- use MONITOR PROCESS/TOPCPU to identify those processes that are consuming signficant CPU time (there may be more than one such process in a multi-CPU system, which can also hide the severity of the problem)
- use the SHOW PROCESS/CONTINUOUS command on that process to identify what image is being executed, and a rough approximation of where the PC (program counter) is.
- then use the MAP file produced by LINK to see which part of the code is being executed.

I hope that the preceding is helpful.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

I decrease the priority of a cpu consumming process (more than 80% of cpu) unless it is an allowed one (db server, zip and a few applic programs). After 10 min : prio=prio - 1 and this is repeated every 10 minutes until prio = 1 or the process stays under 80%. I also give an alarm so that investigation is triggered.

Looping "bad programs" may be killed based upon the program name or are suspended (only 1 : dtsession).

To many COM processes can also lead to network timeouts for processes that don't get the CPU.

Wim