Day before yesterday, two other sites I run had bogged down to slower than a crawl, while this one, which gets roughly 100 times the traffic of the other two combined, was whizzing along as usual. I assumed this was a cache issue, inasmuch as this site is cached and the others aren’t, so I duly installed a cache plugin, and, while I was at it, moved up to WordPress 3.4. The gain in speed was microscopic, and after sweating it for entirely too long, I turned in a trouble ticket to the host.
The response was quick, and somewhat unexpected. The nature of WordPress is somewhat bifurcated: you have your Web server, but most of what it’s serving is coming from a separate database machine. I had guessed that communication between the two boxes had been severed, or at least impaired, and when a couple of tracert runs timed out, I was sure of it. Well, no: the requests weren’t getting to the database because procwatch was killing them. It goes like this:
The problem is not necessarily with either of the domains you listed, but with any domain or combination of domains hosted under [user name]. If domain-A is using 99% of the allotted memory and domain-B uses the other 1%, it will be domain-B’s scripts that get killed, even though domain-A is the one using all the memory. (For this reason, it may be sufficient to simply split up some of your domains among multiple users.)
See “100 times the traffic,” supra. And, of course, being lazy, I’d set them up over the years under the same user name, failing to anticipate that for convenience in administration they might eventually put them all on the same shared server. (I don’t have the traffic to justify anything more than that.)
So new users were created, and behavior returned to normal in a matter of minutes. And I’ve installed a little gizmo that calls out the memory usage at any given moment, along the bottom of the admin screen. (Which, of course, uses some memory, but TANSTAAFL applies, as it always must.)