# Apache/mongrel/mysql -master-slave on xen/memory allocation **URL:** \ **Category:** Rails\ **Created:** [September 27, 2006, 8:27pm UTC](https://www.ruby-forum.com/t/apache-mongrel-mysql-master-slave-on-xen-memory-allocation/70259 "2006-09-27T20:27:27Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [September 27, 2006, 8:27pm UTC](https://www.ruby-forum.com/t/apache-mongrel-mysql-master-slave-on-xen-memory-allocation/70259/1 "2006-09-27T20:27:27Z")
ive got a server with 6gb of memory which i plan on setting up with apache (handling static - w/ mod\_security) proxying to a mongrel cluster with mysql databases setup on seperate xen instances with master/slave replication. my question is 1. any opinions as far as whether this would be the optimal config. and 2. ideas as to how to distribute memory… im thinking 3gb for the apache/mongrel cluster and 1.5gb for each of the xen instances running the databases. and 3. what kind of loads -guesstimate- this could reasonably handle… ballpark guess ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [September 27, 2006, 9:54pm UTC](https://www.ruby-forum.com/t/apache-mongrel-mysql-master-slave-on-xen-memory-allocation/70259/2 "2006-09-27T21:54:00Z")
I’m wondering - what is the advantage of running xen over just running all your processes on one instance of an OS. You’re still using all the same hardware resources, plus overhead of running Xen. Maybe this is obvious, but I don’t get it. Can anyone explain this to me? ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [September 27, 2006, 10:28pm UTC](https://www.ruby-forum.com/t/apache-mongrel-mysql-master-slave-on-xen-memory-allocation/70259/3 "2006-09-27T22:28:06Z")
Not speaking for Joe here but… The reason to go with Xen is one of hardware mobility. Once the configuration is in place, if you need to add in more hardware, moving the instance is a no-brainer operation. I, for one, will _never_ install on bare hardware ever again. Properly configured, the Xen overhead is amazingly low. – – Tom M., Engine Y. ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [September 27, 2006, 10:34pm UTC](https://www.ruby-forum.com/t/apache-mongrel-mysql-master-slave-on-xen-memory-allocation/70259/4 "2006-09-27T22:34:07Z")
On Sep 27, 2006, at 12:48 PM, Jason N. wrote: > > cluster Splitting up a server with 6 gigs of ram using Xen is a great way to make it easy for yourself to scale later. It also separates concerns so they run independently of each other. It is true that since it is all on the same piece of hardware that you still have a single point of failure if your hardware crashes. But it makes it much easier to scale to more servers later. You can actually move a running Xen instance to another physical server _while it is still running_. ``` Also Xen is a serious performance leader in the virt server field. ``` You really only have about 5% perf loss compared to raw hrdware and Xen VM’s. We have built our entire business around Xen based rails hosting [http://engineyard.com](http://engineyard.com) . And even when we sell dedicated servers to people we are still running Xen even if they only have one Xen VM that takes up the entire server. This allows for much easier migration to different hardware in the future. ``` Xen is awesome and I think it is a good idea to split up your server ``` like you are thinking about. You haven’t given enough details about the hardware(processor type et al) and your app for me to give you any performance or capacity estimates. But you will be able to serve quite a lot of traffic off of a box like you have. ``` I would recommend if you haven't bought the hardware yet that you ``` consider getting two servers with maybe 2 or 4 gigs of ram each. And then split up your app across two servers. Run identical VM’x on each server so you have one DB VM on each server and a few App server VM’s on each server and two Web static file VM’s on each server. This will give you much more reliability then one server. Cheers- -Ezra ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [September 27, 2006, 11:57pm UTC](https://www.ruby-forum.com/t/apache-mongrel-mysql-master-slave-on-xen-memory-allocation/70259/5 "2006-09-27T23:57:53Z")
Ezra Z. wrote: > On Sep 27, 2006, at 12:48 PM, Jason N. wrote: > > > > cluster > > Splitting up a server with 6 gigs of ram using Xen is a great way to > make it easy for yourself to scale later. It also separates concerns > so they run independently of each other. It is true that since it is > all on the same piece of hardware that you still have a single point > of failure if your hardware crashes. But it makes it much easier to > scale to more servers later. You can actually move a running Xen > instance to another physical server _while it is still running_. > > Also Xen is a serious performance leader in the virt server field. > You really only have about 5% perf loss compared to raw hrdware and > Xen VM’s. We have built our entire business around Xen based rails > hosting [http://engineyard.com](http://engineyard.com) . And even when we sell dedicated > servers to people we are still running Xen even if they only have one > Xen VM that takes up the entire server. This allows for much easier > migration to different hardware in the future. > > Xen is awesome and I think it is a good idea to split up your server > like you are thinking about. You haven’t given enough details about > the hardware(processor type et al) and your app for me to give you > any performance or capacity estimates. But you will be able to serve > quite a lot of traffic off of a box like you have. > > I would recommend if you haven’t bought the hardware yet that you > consider getting two servers with maybe 2 or 4 gigs of ram each. And > then split up your app across two servers. Run identical VM’x on each > server so you have one DB VM on each server and a few App server VM’s > on each server and two Web static file VM’s on each server. This will > give you much more reliability then one server. > > Cheers- > -Ezra you guys hit the nail on the head as far as the reasoning for the databases running on xen. scalability/portablility. while it is true there is still a single point of hardware failure, this is a new ibm box we’re not anticipating having hardware failures with initially.(also why we’re going with 1 box instead of 2, as well as 1 is max horsepower for the price e.i cheaper, and they’re paying by th u) the company we’re building this for is hoping to need to scale/ have the $$ to scale shortly which speaks to the use of xen… we can get two more boxes and create 2 xen instances on each -migrate live- and have 4 node array w/ 2 points of hardware failure and then use heartbeat to monitor/redirect between the two; maybe go cluster instead of master/slave… or something like that, thats down the road 🙂 and then we can leave the proxy/apps on this box… add another proxy/app box after that w/ a hardware load balancer etc. the point is scalability/portablility of the databases. and no data -per se- will be on the bare hardware, we can run normal backups, create copies of the xen database vm’s, etc as necessary; and for the proxy/app fw/mongrel cluster, that can run bare -and not have to take 1 more performance hit from xen- 'cause i can just keep copies of the config, same w/ rails(capistrano) and mongrel. monitor/restart processes via script etc. etc. and when a new box gets introduced -bingo- live vm migrate. easy. and as far as the performance you guys hit it to, from what i’ve read xen handles resources quite well -much better than vmware- with the way it interacts w/ said resources and with the horsepower we’re running the hit will be negligible compared to the benefits. along w/ the 6gb ram, procs are twin dual core 3.0gb xeons. can’t get into the app, sorry… the company is launching the app we’re building in a few weeks… which leads me to another, kinda amateur, question(sorry, haven’t lurked this forum myself long:); when we get them/ they launch the beta whats the policy regarding “hey, we launched this beta built on rails, check it out see what ya think, give some input etc.” in this forum… generally… and any suggestions on any good forums for that -rails, web 2.0-; we’ve got a bunch but the more the merrier:) don’t wanna spam. nobody likes that. thanks all, joe