sdlvx wrote:
I think there might be something wrong with my mpm after googling around. If my ServerLimit and MaxClients is not really high, it takes forever for pages to load.
How much processing is required for you to deliver a page? It sounds like individual requests take a long time to render, in which case, yes, a configuration to only support a few simultaneous requests will cause queuing.
But that still doesn't mean that setting a value that permits your Linode to go into heavy swapping isn't going to be counter-productive. In other words, as long as you don't overflow memory, more processes are fine, but beyond that point you're actually going to hurt yourself.
Quote:
After reading about MPM, I'm thinking I messed it up and I don't have any MPM, and each apache process is a single request. I was googling and I couldn't find out how to see which MPM my server is running.
Well, you definitely have an MPM since any apache is going to have at least one MPM selected, but it's certainly true often the default is prefork which is a single process per request. Depending on distributions you can probably tell by what packages you installed. Or I believe "apache2 -V" should show the MPM configured into the server.
Quote:
I recall reading that maximum simultaneous users should be MaxClients * number of threads in your mpm. It seems like I'm only getting Max Clients * 1.
If you're using prefork, that would be right, as it only has one thread/client per process.
Quote:
I ran ps -ef |grep apache2 |wc and I think it said I had 222 processes open.
Given the resource demands per-worker in your prior posting, I have to imagine you were thrashing/swapping horribly with that many. Not sure how you hit 222 with a MaxClients of 150, but it could be you were thrashing so badly the system wasn't able to clean up the old processes fast enough, especially as with MaxRequestsPerChild it has to shut down and start a new child process for each incoming request.
Quote:
EDIT: One last edit. I gave up and just restored backups and it seems to be working now that I set
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>
and I removed MaxClients and ServerLimit from httpd.conf
For what it's worth, that's still almost certainly too high a MaxClients value for your environment.
The fact that it's working now is more likely due to the reload/restart (which cleared all the processes) than any configuration correction. You're just sitting on a time bomb whose clock you have reset, but it's likely to blow up again as soon as you get enough load in terms of simultaneous requests being processed.
Again - your best bet is to tune Apache so that under full load you are barely swapping, taking into account all processes. That will most likely require dropping MaxClients.
You could increase MaxRequestsPerChild (as recommended by another poster) which won't change the simultaneous request limit nor peak memory footprint, but helps minimize process creation since it lets a child handle that many requests before restarting it. That should be safe unless you have "messy" code running per request or a buggy request processing chain.
You could also try switching to a threaded MPM model, since multiple threads per child process are a little lighter weight, but not all embedded interpreters may like that, nor do I suspect it'll make a massive difference in throughput, since if you're tying up a 720's worth of memory with apache processes, the individual rendering of a page is likely bottlenecked elsewhere.
The bottom line in all this is to find the sweet spot of configuration where you are maximally using your available resources, but not exceeding them. As you approach that point in tuning you will see your performance (requests/second you can service) steadily increase, but if you cross past it, your performance is going to tank like going off a cliff. So when in doubt, start conservatively. You may be a little more sluggish than you need to be, but at least you won't tank.
One thing you could do to provide yourself with more room for experimentation is to temporarily allocate a second 720. Clone your current box over (sounds like you have backups, so just restore to the new box and tweak hostnames and what not), and then experiment against that. Tools such as ab can help load down your server (be sure to request URLs that exercise your full database path), and help find an appropriate tuning point.
I really do suspect you'll be able to get quite good performance out of a 720 even with a reasonably inefficient rendering path, while still protecting yourself against becoming overloaded, but you really do want to find an appropriate configuration that won't let the box fall over the cliff if load gets too high. In such a case, it's better to queue (or even drop) requests since at least only a few suffer rather than killing everyone's performance and making your site essentially unusable.
-- David