[webvet]

>What is the actual bottleneck?

As mentioned in OP, it is MySQL.

>you can't run a massive database on crappy hardware and expect it to work smoothly.

Absolutely... but we do wish to milk the VPS for every cent of its worth and we're not sure we've got there yet.

Thanks for your input.

[stevekemp]

> As mentioned in OP, it is MySQL.

That's not specific enough.

Yes, the problem is manifesting itself via MySQL, but the bottleneck will be somewhere else; whether RAM, CPU, or I/O-wait.

[cpncrunch]

Exactly. If the OP can post the output of top, vmstat and iostat both when the problem occurs and after restarting the processes, that would be a start. There might be some simple thing you can tweak to improve things.

[webvet]

Will try and post within a few hours. Thanks.

[webvet]

For now, we're making our code/queries/optimization take the blame rather than the hardware.

[cpncrunch]

I can't really see how your code or queries could cause mysql or apache to gradually slow down and then speed up when you kill the processes. It sounds more like virtual memory of some process is growing too high causing thrashing, or apache has too many children, or you're running out of some resource, or something is leaking memory.

Regarding apache/mysql: are you using stock distributions, or did you build them yourself? Are you using any unusual configuration in either of them?

You say you kill both mysql and apache, but what happens if you just kill one or the other? I'm just wondering if it is some buggy cgi script that is leaking resources.

[webvet]

>I can't really see how your code or queries could cause mysql or apache to gradually slow down and then speed up...

Actually, we've ascertained that it is not the code or queries that cause this per se, but it is the traffic patterns - human visitors + SE crawlers... at times, there are (natural) traffic bursts and that's when the server starts choking.

apache/mysql - stock distros, with some config tweaks, mainly in my.cnf.

>what happens if you just kill one or the other?

Good call. Actually, restarting just apache does the trick most of the times. What we suspect is, abrupt flooding in http requests causes MySQL to slow down which causes http requests to get queued up and finally choke the service.

[cpncrunch]

Ok, I still think you probably need to spend some money on better hardware, but here are a few ideas for eeking out some more performance from your existing setup:

- Limit the max apache child processes/threads to what your server can easily handle. That way during busy periods people will get an occasional error connecting to your server (or wait a while), but at least mysql won't be thrashing your server so it might improve overall performance during the busy times.

- Figure out which queries are using the most cpu time and optimize those.

- Have a look at your most frequently accessed pages and see if you can optimize database access in those pages.

However if your users are still sometimes getting error messages accessing your site you have to ask yourself whether that is going to hurt your business.

[AznHisoka]

Are you sure you have a database connection pool in place? Ensure the # of active connections remain constant no matter how many http requests are coming in.