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.
