Reese Knowledgebase

How to troubleshoot PVA agent related issues

View Kristian Reese's profile on LinkedIn


If you like this article, please +1 or Recommend via FB with the provided buttons above:

Article ID: 51
by: Reese K.
Posted: 30 Jul, 2012
Last updated: 18 Dec, 2012
Views: 2585
If you like this article, please +1 or Recommend via FB with the provided buttons above:

To troubleshoot PVA Agent related issues, check these logs:

/var/log/pva/agent/YYYY.MM.DD-vzagent.log

The PVA Agent database is located at /vz/pva/agent/etc/VZAgentDB.sqldb and I find that the larger the DB is, the more lagged connections to the vzcp become.  To circumvent the issue, I used to reinstall the PVA Agent, but that has proven to become cumbersome and even so, customers would continue to complain about lagged connections once the database grew again.

To put a finger on proving the theory, I ran an strace and found hangups while attempting to run queries against VZAgentDB.sqldb and googled the term "VZAgentDB.sqldb".  Finally, parallels has posted an kb article related to this issue: http://kb.parallels.com/en/114345

Prior searches of "VZAgentDB.sqldb", or "lagged connectivity to 4643 vzcp" turned up nothing.  Only after reinstalling the PVA Agent did I know that it had something to do with the agent, and from prior experience as an admin, I began to suspect the database since the file was so large, that it would make sense for performance to degrade as VZAgentDB.sqldb grew in size and observing that it was never rotated.

In any case, I opt'd not to follow parallels recommendations, and instead, keep copies of the database file on a 30 day rotation.  This way, reference can be made back (up to 30 days) just in case.

My Solution:

Follow my kb on how to reinstall the PVA Agent.  This will only need to be done once.  The idea is to create a fresh copy of the VZAgentDB.sqldb file to use in this outlined solution.  This has a benefit in that the fresh copy is very small.  If the existing DB is cleansed as noted in the parallels kb article, you'll quickly notice that the file size itself does not change and consumes just as much disk space as it did before.  If there's a way to adjust the size of the file as a reflection of the actual size of the DB, I'm not aware of it.

1. After the PVA Agent has been reinstalled, make a copy of the freshly installed VZAgentDB.sqldb:

/bin/cp /vz/pva/agent/etc/VZAgentDB.sqldb /root/scripts/hotfixes/VZAgentDB.sqldb.template

2. Make a directory to store 30 days worth of backed up VZAgent databases:

mkdir /vz/pva/agent/etc/VZAgentDB_backups

3. Add the following to roots cronttab

# m h dom mon dow command
59 23 * * * /root/scripts/hotfixes/vzagentdb.sh > /root/scripts/hotfixes/vzagentdb-cron.log 2>&1

4. Create /root/scripts/hotfixes/vzagentdb.sh and set permission to 754:

#!/bin/bash
#
# Kristian T Reese
# 10.8.2012
# rpm -q pva-release
# pva-release-4.6-1722
#
# http://kb.parallels.com/en/114345
# Large database issues:application errors and slowdowns in PVA and Power Panel
#
# Current version of PVA does not have the feature of log rotation, so the
# PVA Agent SQLite database performance degrades as it grows
#
# Instead of following the kb, this kludge will backup the current VZAgentDB.sqldb
# and restore a template, copied from a fresh pva install
#

NOW=$(date +"%m-%d-%Y")

/usr/sbin/pvaagent stop
/bin/gzip -9 /vz/pva/agent/etc/VZAgentDB.sqldb
/bin/mv /vz/pva/agent/etc/VZAgentDB.sqldb.gz /vz/pva/agent/etc/VZAgentDB_backups/VZAgentDB.$NOW.sqldb.gz
/bin/cp /root/scripts/hotfixes/VZAgentDB.sqldb.template /vz/pva/agent/etc/VZAgentDB.sqldb
/usr/sbin/pvaagent start

#clean up backed up files older than 30 days
/usr/bin/find /vz/pva/agent/etc/VZAgentDB_backups -mount -type f -mtime +30 -name VZAgentDB*.sqldb.gz -exec rm -f {} \; -print

This article was:   Helpful | Not Helpful
Prev   Next
How to locate vzagent.conf     How to troubleshoot Power Panel vzcp related issues

RSS