How do you attribute the 50% sys usage to that one process? That is for all processes is it not? BTW - when ANY process runs it spends time in kernel code (sys) when invoking a syscall, .e.g. open(). That means vmstat and sar would normally show a summed % sys for all processes system wide.
Doesn't mean that the daemon is or is not using most of that %.
My mistake. I was trying to say the same thing you just did. The usage is around 50%.
Using tools such as lsof or truss, if you have them installed.
Code:
truss -rall -wall -p PID
Examine the calls, perhaps some file is missing and program runs continuously in loops or similar issues (could explain the large %sys usage)
Also issue a find to perhaps to locate from which script is that spawned as rbatte suggested.
Something in the line of :
Code:
find /sbin/init.d -type f -exec egrep "svhptdaemon|svhpt" {} /dev/null \;
If you get a match, examine that script for possibility to disable that and what that is actually.
Perhaps i can offer more assistance in couple of days when i get to hpux box.
Unfortunately I don't have lsof nor truss installed on this box.
I issued the find command but it came back with no results.
---------- Post updated at 04:04 PM ---------- Previous update was at 03:57 PM ----------
I decided to run find on the entire / fs. This came up, not sure what to make of it. This came from a file in the /tmp directory. /tmp/toolset/spin.0509
Code:
Running Threads (TSRUNPROC) and idle Processors
===============================================
TICKS TICKS I TICKS
SINCE SINCE C SINCE NREADY
TID PID PPID RUN IDLE PRI SPU STATE S MIGR FR LO AL COMMAND
------- ----- ----- --------- --------- ---- --- ----- - --------- -- -- -- -------
9822392 9922 9804 0 414 231 0 SYS ? 1104611 7 0 -- crashinfo
Processor #0
TICKS TICKS I TICKS
SINCE SINCE C SINCE NREADY
TID PID PPID RUN IDLE PRI SPU STATE S MIGR FR LO AL COMMAND
------- ----- ----- --------- --------- ---- --- ----- - --------- -- -- -- -------
57 28 0 425067099 425067099 152 1 SYS ? 425067116 0 7 -- svhptdaemon
I can only guess that shptdaemon belongs to some clustering software.
And it is certainly misbehaving.
Please contact HPE support! Or Oracle if you run the Oracle RAC software.