ps -ef very slow

[Ronny_7]

Hi,

I have a GS160 running on Tru64 Unix V5.1A which has such problem.

Whenever I issue process related command, e.g.
ps -ef, the response takes a while before listing out the process.
This only happens today.

Also I found out, there are a lot of this process "dia etm" when I issue the ps -ef command. They are all dated 26 Aug.

These look like decevent processes but I cannot find any decevent command with etm.

Any advise what could cause the ps command slow and what are the "dia etm"?

Regards,
Ronny

[Ralf Puchner · Accepted solution]

first check who is the parent of the processes and which state they have (run/stopped/defunc etc.)

The ps output could be slow if a resource limit occurs or machine is under heavy load/usage.

Use the "trace" or "truss" command to debug the ps process during runtime and maybe this will give you a hint what is going on.

[Ronny_7]

Hi Ralf,

Thank you for the reply.

It looks like the oracle is taking up a lot of the CPU usage, will this cause the slowness?

For the "dia etm" processes, all with PPID 1.
Any idea what processes are these?

Regards,
Ronny

Below is the output of the oracle,
load averages: 27.30, 25.55, 24.43
835 processes: 26 running, 579 sleeping, 229 idle, 1 zombie
CPU states: 87.8% user, 0.0% nice, 9.7% system, 2.4% idle
Memory: Real: 9076M/47G act/tot Virtual: 80619M use/tot Free: 35G

PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND
392690 engine 57 0 2496K 57K run 357.5H 99.90% ksh
256363 engine 44 0 11G 10M run 84:11 99.90% oracle
256724 engine 44 0 11G 10M run 84:05 99.90% oracle
258847 engine 44 0 11G 10M run 62:46 99.90% oracle
259244 engine 44 0 11G 12M run 47:06 99.90% oracle
256615 engine 44 0 11G 10M run 84:15 99.70% oracle

[Michael Schulte zur Sur]

Hi Ronny,

it seems, your system if very loaded.
2,4% idle, also cpu average load is high,
which means, the queue for a process to get the cpu is long, hence the time to wait.
You seem to have a big machine.
How many cpu??s?

Michael

[Joris Denayer]

Ronny,

You should also verify the ksh with pid 392690. It consumed already more than 300 hours CPU time.
Most likely, it is in a loop. Probably, due to a not correctly closed telnet/rlogin session. There exist a patch for this problem.
This will free at least one CPU.

Joris

[Michael Schulte zur Sur]

Is this problem solved?

[Ronny_7]

As per replies.