Doudt regrading the veritas5.1

[ajsakthivel]

hi,

we have upgraded our veritas setup to 5.1 package. we have observed the following error codes are constantly  printed on my engine_A.log file.

V-16-1-50086 Swap usage on t1000-5 is 91%

V-16-2-13027  , V-16-2-13026 , V-16-2-13210. please let me whether we need to apply any patches on veritas5.1 to work properly.

machine swap usage and cpu usage is below 10%  almost idle but still  it is giving this kind of error.

Thanks and Regards,
Sakthivel.A

[Marianne]

I found the following on VOS:
https://vos.symantec.com/ecls/umi/V-16-1-50086

This message occurs when the HostMonitor daemon reports that the CPU or SWAP usage is beyond the limits allowed by VCS. When the CPU or SWAP usage is 60%, 70%, 80%, and 90%, this message appears. This message is useful for root cause analysis (RCA).

If the system reports high CPU or SWAP usage, attempt to reduce the load. If the message occurs, but the load on the system is not high, contact Symantec Technical Support.

Not sure of your O/S version:
Rolling Patch 1 (sfha-sol_sparc-5.1RP1) is available : https://vos.symantec.com//patch/detail/3321
I don't see anything in the patch README that indicates a fix for HostMonitor:
ftp://ftp.veritas.com/pub/support/patchcentral/Solaris/5.1/sfha/sfha-sol_sparc-5.1RP1-patches.tar.gz_doc/sfha_notes.pdf

If this is not your O/S version, find correct version here: https://vos.symantec.com/patch/matrix

It is always recommended to install the latest patches. If this does not solve your problem. please log a call with Symantec Support.

[Gaurav_S]

Hi,

Applying latest patches would be recommended ofcourse..

However did u actually monitor your swap space ?  It is quite possible that for a peculiar time swap usage is going high which is being reported correctly by VCS ..

I have seen in many situations where someapplication load or backup running in background causes swap usage to shoot up & resulting in above mentioned VCS alerts... This might be correct behaviour by VCS...


Gaurav

[ajsakthivel]

can Any One Please  Update whether there is any solution for this  error also 

V-16-2-13027  
V-16-2-13026
V-16-2-13210

Whether applying patches will  solve my problem.

Thanks in advance.
Sakthivel.A

[g_lee · Accepted solution]

You can use the following website to lookup error codes/UMIs (Unique message identifiers):
https://vos.symantec.com/search?&ft=umi

In your case:
https://vos.symantec.com/ecls/umi/V-16-2-13027
Resource(%s) - monitor procedure did not complete within the expected time.

https://vos.symantec.com/ecls/umi/V-16-2-13026
Resource(%s) - monitor procedure finished successfully after failing to complete within the expected time for (%s) consecutive times.

https://vos.symantec.com/ecls/umi/V-16-2-13210
Agent is calling clean for resource(%s) because %s successive invocations of the monitor procedure did not complete within the expected time.
Description: The resource’s Monitor entry point is not completing within the number of seconds specified by the value of the MonitorTimeout attribute.

You need to look at why the monitor is not completing in the expected time. eg: if the system is busy, or if the timeout is set to a very low value. If it's due to performance/system constantly busy, then you need to address what's causing the delay. If there are patches for your system that resolve known performance issues related to the delay then this may help; otherwise you will need to perform further investigation to determine the cause, and possibly adjust monitoring/timing if appropriate.

[Marianne]

In addition to g_lee's post, please see the following recommendation in the VCS Admin Guide:

The attributes MonitorTimeout, OnlineTimeOut, and OfflineTimeout indicate the maximum time (in seconds) within which the monitor, online, and offline functions must complete or else be terminated. The default for the MonitorTimeout attribute is 60 seconds. The defaults for the OnlineTimeout and OfflineTimeout attributes is 300 seconds.
For best results, Symantec recommends measuring the time it takes to bring a resource online, take it offline, and monitor before modifying the defaults.
Issue an online or offline command to measure the time it takes for each action. To measure how long it takes to monitor a resource, fault the resource and issue a probe, or bring the resource online outside of VCS control and issue a probe.

[Gaurav_S]

If you are getting monitor procedure failures continously, to me it looks to be a symptom of something causing system busy..

I would suggest to do a full check on performance factors..

a) CPU usage
b) Mem usage (Real + swap)
c) Iostat
d) netstat


Gaurav