Just moved my forum over to the 512 package and we barely have 100 users at any given time and things couldn't be worse. The server itself doesn't pass 4-6% cpu, avg's 130-160MB of ram and the bandwidth is around 1-200K up. Tried every apache config I could think of but nothing seems to work.

Are these packages being oversold?

They most definitely are not being oversold.

It will be a configuration issue, on your part, that is causing the bad performance. Or bad webapp software. Or both.

You didn't tell us anything about your configuration, so there's not much we can do to help you.

Not a chance. Either you're badly misconfigured, or someone on your host is hogging resources extremely badly.

What kind of setup do you have? The tuning wizards here will need to know a little more information before they can diagnosis more clearly.

Sorry for the lack of info, been a long few days.





Was using the following for apache:



Same thing.

On the server I'm running VB4, Mysql, Postfix (outgoing only) , Apache.

You probably want to crank MaxClients waaaaay down (~20-25 or so), be sure KeepaliveTimeout is very low (1 second, vs. the default of 15 seconds), and ensure you're using adequate caching. 512 MB is not a huge amount of memory, and Apache's default configuration (for mpm_prefork, required to work around PHP's shortcomings) assumes you have an infinite amount of it.

Also be sure to use whatever caching is appropriate for your software, and consider mysqltuner.pl to make sure your MySQL configuration is optimal.

Randomly picking any thread in this forum has a 50% chance of finding a thread about this exact problem. It's an Apache+PHP problem more than a Linode problem, but PHP is a common enough affliction that this issue is addressed every few hours.

_________________

/* TODO: need to add signature to posts */

What forum software are you using? Are you using any sort of caching?

~JW

Using Vbulletin which is already a resource hog.

Just upgraded to the 768mb today and the same time out issues exist. At the moment I'm just got though all error logs in case I've overlooked something obvious.

You definitely have something misconfigured.

I run a vBulletin site that generally has 200+ users with 600+ during spikes, and I'm on a 2048...

(wait, I'm not done explaining, I realize you're on a smaller box).

When I first started it up, I noticed the same problems you had. Once you get Apache tuned, you'll have no problems. I'm going to downgrade to a 1024 or a 768 in the near future.

Did you follow HoopyCat's instructions to lower your MaxClients significantly?

I'd suggest the following changes:
MaxClients to 20
KeepAliveTimeout to 2

Performance improved slightly. Just looking into other ways to reduce the amount of requests per load on the server. Nginx as a reverse proxy might be the solution.

are you serving a lot of static content? or is it mostly the php pages?

did you install apc?

I would say its about 50/50. I have apc & memcache installed but the problem is way too many requests on each page load. First I'm going with the nginx as a frontend for the static content and possibly installing a file server (or CDN) for the images. I'll post back with my results.

I am anxiously awaiting the solution to this problem.

I currently have shared hosting at HostGator and a VPS here at Linode. I had started with a 768 but moved to a 512 after Linode changed the resources included with each.

The 768 was overkill and the 512 continues to be much faster than anything that I have ever had with HostGator.

In my experience, the VPS here respond as if they have very little load.

Jeff

Finally found the issue, my firewall rules for SYN attacks were a bit too restrictive. I've used a similar rule on other forums & blogs but it seems VB needed a bit more wiggle room. Still plan on adding nginx as a reverse proxy and php fqm for apache. I'll try and compile a mini how to with links to a few sources that helped me along the way.

Consider using Squid as a front-end transparent proxy/cache, forwarding dynamic requests to Apache.

Apache processes tend to be large and have lingering closes which can swamp a server.

By letting a front end proxy handle the static stuff, Apache is freed up to do the few (percentage wise) dynamic requests.

On our servers, over 90% of requests to our servers are handled by Squid and never make it to Apache.