mrarrow

Now that a suitable amount of time has elapsed, I can confirm that the following sorted my particular issues:

Resetting my global PHP.ini file to following:
CORE: memory_limit = 96Mb
OPTIONS & INFORMATION: max_execution_time = 60secs

For sites with any significant traffic, I also disabled wp-cron in the wp-config.php file and set up cron jobs in cPanel (for each site and subdomain) to run at regular intervals, generally 4-6hrs. All as detailed above.

This then fixed the issues almost immediately.

Further to that, I recently noticed that 1Gb of RAM had “dropped off” my VPS (should’ve had 2Gb. but it was only operating with 1Gb!!!!). So I politely requested my hosting provider find the extra RAM and reapply it…

This actually may have been the catalyst for the problems in the first place, but clearly the first two actions fixed the server load before I noticed the missing RAM and WP leaner and meaner the first place.

I’m currently running about 15-20 separate WP installs on the same VPS, most with multiple subdomains.

Cool. Thanks for confirming.

Anyway, when I said “normal Admin rights”, I did mean Network Admin (sorry, loose terminology on my behalf).

Useful to know that both methods are compatible – shame there’s not more made of this in the documentation.

Well it seems to be happening to the installs that have had recent activity on them in terms of content being generated or edited (but as I say, not necessarily at that time – coz I’m getting spikes during the night too).

By default I set them up as multisite (even though I may not immediately need the multisite capability – I come at it from WPMU!). I don’t use multidomain installs now – I set each one up in separate accounts on the server.

There’s no common themes being used and the installs have varying amounts of traffic and user-generated activity.

In general the only common plugins I use across all these sites are:

Unfiltered MU 1.3.1
Defensio 2.5.9

I’m not sure if this helps!

OK, well I’ve now upgraded all installs to WP 3.0.3 and I’m still getting these errors e.g.

Time:          Sun Dec 12 02:23:19 2010 +0000
Account:       <nameofuser>
Process Count: 11 (Not killed)

Process Information:

User:<nameofuser> PID:9259 Run Time:216(secs) Memory:172296(kb) exe:/usr/bin/php cmd:/usr/bin/php /home/<nameofuser>/public_html/index.php
User:<nameofuser> PID:9293 Run Time:213(secs) Memory:172288(kb) exe:/usr/bin/php cmd:/usr/bin/php /home/<nameofuser>/public_html/index.php
User:<nameofuser> PID:9701 Run Time:206(secs) Memory:150268(kb) exe:/usr/bin/php cmd:/usr/bin/php /home/<nameofuser>/public_html/index.php
User:<nameofuser> PID:17796 Run Time:67(secs) Memory:13876(kb) exe:/opt/suphp/sbin/suphp cmd:/opt/suphp/sbin/suphp
User:<nameofuser> PID:17933 Run Time:55(secs) Memory:13876(kb) exe:/opt/suphp/sbin/suphp cmd:/opt/suphp/sbin/suphp
User:<nameofuser> PID:19521 Run Time:51(secs) Memory:13876(kb) exe:/opt/suphp/sbin/suphp cmd:/opt/suphp/sbin/suphp
User:<nameofuser> PID:19523 Run Time:51(secs) Memory:13876(kb) exe:/opt/suphp/sbin/suphp cmd:/opt/suphp/sbin/suphp
User:<nameofuser> PID:19534 Run Time:50(secs) Memory:13876(kb) exe:/opt/suphp/sbin/suphp cmd:/opt/suphp/sbin/suphp
User:<nameofuser> PID:19536 Run Time:50(secs) Memory:13876(kb) exe:/opt/suphp/sbin/suphp cmd:/opt/suphp/sbin/suphp
User:<nameofuser> PID:19903 Run Time<nameofuser>:22(secs) Memory:13876(kb) exe:/opt/suphp/sbin/suphp cmd:/opt/suphp/sbin/suphp
User:<nameofuser> PID:26372 Run Time:355(secs) Memory:171188(kb) exe:/usr/bin/php cmd:/usr/bin/php /home/<nameofuser>/public_html/index.php

The files being reported can vary, but they’re generally the index.php or cron.php with some su php mixed in for good measure.

When several accounts are reporting these errors at the same time it then increases our server load immensely (and I mean 35/40-fold) which grinds everything to a halt. This normally happens during the night which I guess does indicate that its some kind of cron process running, as usage stats show that all of our sites generally don’t get much external traffic during night hours.

However, one time it happened during the day on an install that I was working on at the time (just simple CSS stuff). I found the server load just increasing exponentially for no apparent reason. When it was getting beyond a joke, I quit out of all my browser sessions (only a couple of tabs open for that site) and that seemed to immediately have an effect i.e. within a very short space of time, the server load had dropped back down to normal levels.

Coincidence – I dunno? Something’s odd and it also seems to be also happening on accounts that aren’t actually live yet i.e. they’re not having users generating content/logging in etc.

Any ideas or thoughts?

OK – well I’m just upgrading each one to 3.0.2 via Subversion, so I’ll see if that fixes it.

Thanks

Yes there is a ‘Reset’ button, but it takes you back to the home page.

I notice elsewhere in this forum that you can change the URL of ‘Reset’ link by doing:

function my_qmt_base_url() {
	return get_page_link( YOUR_PAGE_ID );
}
add_filter( 'qmt_base_url', 'my_qmt_base_url' );

But would it not be even simpler to just clear the dropdowns and remain on whatever page you were currently on. The closest analogy would be like the familiar <input type="reset" value="Reset"> in a standard HTML form?