VMCHIS wrote:
Has there been any solutions to this issue? I am also experiencing the same problem and recreated the SQL jobs and that did not work. I too have my 5 Minutes stats interval set to Save For 1 Days and Stats Level set too 2 for use with our Foglight software. I would really like to get rid of these pesky errors.
Yes, I received a "solution" from engineering... sorry for never updating and finishing this thread. Engineer suggest that I try the following:
The following are two parameters that are designed for user to configure. We can increase this parameter values and see if it can help improve the situation. Edit the VC configuration file (vpxd.cfg) by adding the following parameters under the <vpxd> tag and restart VC service for them to take effect.
- e.g.
<vpxd>
<stats>
<maxProcessingThreads>3</maxProcessingThreads>
</stats>
</vpxd>
------------------------
- vpxd.stats.maxProcessingThreads -- Number of concurrent temp
table processing stored procedures can be invoked. Default 1.
To do: Increase the default value from 1 to 3 and see if it helps.
- vpxd.stats.maxTableAcqTimeSec -- How long should a thread
wait to get a table before giving up on persisting a set of
stats to the DB. This limit should only be hit is all the
temp tables are pending for processing indicating an overly
loaded DB. Default 30
To do: Increase this value to 600
I asked Engineering why they don't just supply this information in a KB article and they said that they look at this problem on a case by case scenario. They look at the specific logs and then try to suggest a solution. So, apparently for us, this was what they suggested for or situation and it DID seem to work. We were able to run our 5-min logging level back up to "2" and the insertion errors disappeared. Not saying this will fix your problem but it's pretty easy change to implement and then check. Hopefully this helps!
