cancel
Showing results for 
Search instead for 
Did you mean: 

vxdbd high cpu usage @ hpux

  There is evidence vxdbd daemon is consuming too much cpu and following its behaviour has many EPIPE errors on writes.

See first column:

$ grep " write" ./pid.12331  | awk '{print $4,$5, $7, $9, $16,$17}' | sort | uniq -c | sort -rn

45355 pid=12331 ktid=20116 write err=32 A0=0 A1=6

45219 pid=12331 ktid=20117 write err=32 A0=0 A1=10

43862 pid=12331 ktid=20118 write err=32 A0=0 A1=11

40211 pid=12331 ktid=20121 write err=32 A0=0 A1=13

39893 pid=12331 ktid=20120 write err=32 A0=0 A1=12

 

We think restarting the service could eliminate such condition. Of course the above as a workaround. There is a patch which has some fixes for it , i.e.

PHCO_41073;

Before trying a restart of the service i.e. as per manual documentation:

To start the vxdbd daemon

 Use the vxdbdctrl start command:

/opt/VRTSdbcom/bin/vxdbdctrl start

 

To stop the vxdbd daemon

As root, use the vxdbdctrl stop command:

/opt/VRTSdbcom/bin/vxdbdctrl stop

Our question is:

Q. Is it safe to restart vxdbd daemon with no colateral impact on production services due the nature or extension of vxdbd's functionality?

Best Regards.

1 Solution

Accepted Solutions
Accepted Solution!

Restarting vxdbd should be safe under normal conditions.

Hi Alizarra,

 

Restarting vxdbd should be safe under normal conditions. This daemon is responsible for communication

between SF-ORA products. Stopping this daemon should not cause any I/O issues to database or filesystems.

 

Hope this helps.

Srini

View solution in original post

1 Reply
Accepted Solution!

Restarting vxdbd should be safe under normal conditions.

Hi Alizarra,

 

Restarting vxdbd should be safe under normal conditions. This daemon is responsible for communication

between SF-ORA products. Stopping this daemon should not cause any I/O issues to database or filesystems.

 

Hope this helps.

Srini

View solution in original post