Some things you need to check:

check /etc/psa/psa.conf  for HTTPD_VHOSTS_D and make sure the path doesn’t contain a trailing slash.

check the hosting,smb_apsProvisionEnvironments,subdomains, sys_users tables in the psa database and make sure the home field points to the right path.

You can use the mysql REPLACE function if not:

update sys_users set home=REPLACE(home,”OLD_PATH”,”NEW_PATH”);

Check that the domain has an entry in the hosting table.

Check that the home field in the sys_users table points to the same path as in the hosting table.
This ended up fixing it for me, in sys_users I had /www/vhosts/domain.com and in hosting /www/vhosts/ANOTHERdomain.com/something

DELETE FROM wp_comments WHERE comment_approved=0;

This deletes all unapproved comments, not necessarily all of them being spam.

SHELL=/bin/sh
SPAM="/path/to/spam/Maildir/"
MAILBOX="/path/to/user/Maildir/"

/^From:.*/
getaddr($MATCH) =~ /^.*/;
MATCH=tolower($MATCH)

if ( lookup($MATCH, "geek.ro-blacklist") )
         to "$SPAM"
if( lookup($MATCH, "geek.ro-whitelist") )
         to "$MAILBOX"
if (/^X-Spam-Status:  *Yes*/)
         to "$SPAM"
to "$MAILBOX"

the geek.ro-whitelist, geek.ro-blacklist files are just regexes to match against the sender’ email address, (e.g. .*@domain\.com), one per line.

I just looked up the manual page for mysql_num_rows and I see where most got their bad habits from.
Why this is bad:
You might not notice the performance problems of this query if you have a small table or if you’re running the mysql server on localhost. What this query does is generate a lot of useless traffic/IO and when you have this query running several times per minute or on a huge table it will have your server crawl no matter the hardware you have behind it. What you are doing is fetching all the rows from the database and then counting them, just imagine selecting 1mil records every time a page loads just to see how many of them you have and you’ll get a sense of whats wrong with this type of approach.
Solution:
$query = “SELECT count(*) FROM table WHERE cond=true”;
$num   = mysql_fetch_row($query);
Same result a lot less overhead.
Case 2:
$query = “SELECT * FROM table WHERE cont=true”;
while ($res = mysql_fetch_assoc($query)) {
array_push($ids,$res['id']);
}
Why this is bad:
Again you are selecting an entire dataset when you need only a fraction of it.
Solution:
$query = “SELECT id FROM table WHERE cond=true”;
while ($res = mysql_fetch_assoc($query)) {
array_push($ids,$res['id']);
}

Keep in mind that all snippets you find on the net are just examples and are made so that they apply for a wide variety of cases, this doesn’t mean that it is the best approach for your scenario. Keep all things minimal and work only with the data you really need.

After a bit of debugging it turns out amavis keeps an open connection to mysql and depending on your wait_timeout setting it might lose the connection and need to reconnect.
In order to fix this you just need to increase your wait_timeout to a comfortable value.

mysql set global wait_timeout=28800;
Query OK, 0 rows affected (0.00 sec)

You also need to edit your my.cnf file to make sure the change is persistent across mysql restarts.