My linode has been going into swap and crashing at peak times for the past few months. It was happening at least 5 times per week.

I am running a django app on Apache with a MySQL db. I bumped my swap image to 2GB and it helped somewhat but it still crashes and requires a reboot at least 2 or 3 times per week.

I know a move to nginX or Cherokee will help, due to Apache being such a memory hog, but in the meantime I am interested in setting up a Nodebalancer to help prevent downtime.

I have a few questions:

- Do I need a static IP address to set up a NodeBalancer?
- How does a NodeBalancer help if I stick with only one Linode?
- If I opt for getting a second linode, do I need to replicate/clone my current linode on the new one also?

- See the graph below:


[++++++++++ NodeBalancer +++++++]

[+++ Linode 1 +++] [+++ Linode 2 +++]



- If I was to run on a setup like this, on what linode should my MySQL DB live?

ie: Is it preferable to set up a third Linode, independent of the above setup solely for the MySQL DB & would that need it's own static IP address?

I appreciate any help or advice you can offer!

Kind Regards,
Paul

Increasing swap is the WRONG thing to do.

Tune your apps to be more efficient.

Apache is just fine, when it's setup correctly.

There are at least half a zillion forum posts on tuning a LAMP stack, try a few and see if they help before throwing more hardware at the problem.

The correct approach is to fix your Apache config, not to throw money at the problem. And even if that was the right way to fix the problem, getting more RAM would be the solution, not more linodes.

Thanks for the tips folks. Will drop my swap image back to the recommended level of 512MB.

I take your point on more RAM, not more linodes, but the NodeBalancer + 2 Linodes idea was in preparation for scale.

At some point I will need this kind of setup so I was thinking ahead. Possibly too early to be investing in it, but there you go.

For now, I have tuned MySQL & Apache based on the tips here:
http://library.linode.com/troubleshooti ... networking

Next up: fine tune our App to plug some memory leaks.