Keep Alive is off and Server limit is 40.

MaxClients/ServerLimit of 40 is too high for a Virtuozzo box with less than 1GB of RAM. Some of your httpd processes are using more than 40MB of RAM each. Imagine 40 processes using 40MB of RAM each. It's obviously more than 1GB. (It doesn't always work that way, but it's close enough since SHR is low and you're at the mercy of Virtuozzo's weird memory management policies.)

Also, are you using a 64-bit OS? (Apache usually doesn't have VIRT values of over 300M on a 32-bit OS.) Using 64-bit in a VPS with less than 4GB of RAM is a bad idea.

Cut it down to 20.

I remember putting it down low before and it got to a point where the site wasnt allowing anyone to hit it, but I wil try it.

This is what I will set


<IfModule prefork.c>
StartServers 3
MinSpareServers 1
MaxSpareServers 1
ServerLimit 20
MaxClients 20
MaxRequestsPerChild 500
</IfModule>

And yeah it is 64bit, I have no control over that though.


Linux version 2.6.18-028stab069.5 (root@rhel5-build-x64) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Tue May 18 17:26:16 MSD 2010

That should be fine you should increase max requests per child unless you're worried about memory leaks from your app.

My advise is to create a linode 512 (32 bit), copy your app to it, then run benchmarks against it (google apache's ab). You're running red hat which linode doesn't supply (it's not free), if you want something similar use centos which is a red hat derivative containing free software.

It'll only cost you a few dollars to test so give it a go!

The web server is CentOS it just uses the Red Hat Kernel. The application is Wordpress, it seems to use a lot of memory.

Here's a novel suggestion: Try replacing Total Cache with Super Cache and enable the mod_rewrite option. This could potentially make a lot of difference.

Why? Super Cache has one thing that Total Cache doesn't. It allows you to completely bypass PHP by serving static versions of your blog to non-logged-in users. This can save you a lot of memory. By comparison, the Total Cache plugin itself is a huge bloated monster with tons of options, all of which takes RAM to load up and execute. I think I've heard of VPS's running out of memory using Total Cache, but I've never heard of VPS's running out of memory using Super Cache.

I don't know how much difference this will make in your particular case, but it's worth a try.

Hybinet's right I use supercache, also if you server a lot of static files and feel adventurous, serve them using nginx it's very good at that.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

Now the reason I use Total Cache is mostly for its CDN feature, it lets me create my own self hosted CDN on another server. Also I had issues with Super Cache actually refreshing the cache on time.

I'm confused by the information in these posts. I apache benched a WP blog front page on a 512 server. It is a normal blog, so it just has posts and images and stuff. I did 1000 hits with concurrency of 50 (so that swamped it nicely). Now it didn't like it much (pages took a few seconds to be served), but they were all served. That is without page caching (well, mysql should have cached the query), just an nginx proxy for static files.

If you're running total cache with CDN, how can you have a problem with 2k page impressions in an hour?

I've just benched my 512 node (nginx with fasctcgi_cache):

Server Software:        nginx/0.8.53
Server Port:            80

Document Path:          /
Document Length:        45151 bytes

Concurrency Level:      50
Time taken for tests:   57.811294 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Total transferred:      227961725 bytes
HTML transferred:       226703225 bytes
Requests per second:    86.49 [#/sec] (mean)
Time per request:       578.113 [ms] (mean)
Time per request:       11.562 [ms] (mean, across all concurrent requests)
Transfer rate:          3850.77 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      108  113   6.7    112     148
Processing:   444  460  31.1    448    1356
Waiting:      108  112  10.2    112     252
Total:        556  573  31.2    564    1468

Percentage of the requests served within a certain time (ms)
  50%    564
  66%    584
  75%    584
  80%    584
  90%    588
  95%    596
  98%    604
  99%    668
 100%   1468 (longest request)

[edit]I put in the wrong results, they weren't cached either. Have added cached result. No siginificant load or ram usage during bench.[/edit]
I'll let someone else comment on whether those are good results not not.

Like right now, the site is slashdotted again and the site is almost unresponsive. I want to know if swap will fix that.

You still have plenty of RAM left; your CPU usage is low; and there's no IO contention ("wa"). I don't see any reason in that picture why the site would be unresponsive.

Do you have any plugins that connect to a remote service (e.g. Twitter) at every page view?

Anything in the MySQL slow query log? (You have to enable it first)

Also, it seems you haven't switched to Linode yet. There's a limit to what we Linoders can do to help you solve a non-Linode problem. For all we know, the problem might have to do with an overloaded host machine or the virtualization technology. Memory management in Xen is completely different from Virtuozzo/OpenVZ.

Would it help if I created a linode account and duplicated the site for testing before actually switching the DNS over. I need this to be responsive and handle around 1k hits an hour or more for CES in january.