Mosso's cycle monitor is very poor, marketing says 2.8, other sources a 1.2 and others a dedicated at 10% load constant.

My take, a 256 slice didn't cough at load once in several months, same load pattern on mosso, ate 27,000 cycles, since cancelled.

Anyhow, to answer above, it's raid 50, dell eqilogic.

Everything is allocated so greedy neighbour should be impossible to occur, except on the san.

I can't at the moment see a reason not to set up a simple test vm, divert the ip and use our current ded as the db host Or the otehr way round, more risky for me though.

SO that's

webserver - vm1

||

db server - ded1

If vm1 gets bogged down, I could I guess although it's then 3 vm's move to mod_proxy or equiv out to two vm's. Need shared nfs then too.

The problem is this site's load is low, it really is. But then lunch, evening and pub spikes slay it, which is why I was looking at bigger chunky box solution

But I have to say I prefer the more complicated setup at the moment...but not the maintenance of it.

Give it a go for a mirror site and get the mirror website to access the database running on the main server.

That means you can have a select few accessing brisky through another website and see how that works, then if all good move the web load over on the whole.

All IMHO of course.

How old is the hardware in the current server? Is it likely to run into any hardware issues in the near future?

Will you see any drop in performance in having db requests sent cross network?

Would it make any noticeable difference splitting static content and dynamic content as well as web and db? Something like nginx for static and apache for dynamic?

I am assuming that the majority of load on the server is the db? So will removing the web server bit really free up all that much, taking into account the growth of the site. Is there any benefit in running your own VM's on the sun box allocating resources to each VM as its needed?

Edited 20 January, 200917 yr by apinner

dynamic and static are already split. I don't use apache, really it's a beast compared to the new kids on the block.

network, hardly, gigabit vlans.

hardware is not an issue, it's how much work everything does at peaks, db and web + cache...hardware will go on for ages, nothing wrong with it

touches wooden things quickly.

Mark,

pffft that sounds like testing... I'd certainly get that going, then an nfs mount over ssh for attachments as there are several gig. Few other considerations along the way, but enough for a see how it goes.

How old is the hardware in the current server? Is it likely to run into any hardware issues in the near future?

Should be fine for a while from what colin said and if it start to struggle you can just migrate the DB to the VM system.

Will you see any drop in performance in having db requests sent cross network?

Statistically' date=' yes a small one as the internal link is faster due to not needing to go out of the box, however you won't notice it on the end of an internet connection.

I am assuming that the majority of load on the server is the db? So will removing the web server bit really free up all that much, taking into account the growth of the site. Is there any benefit in running your own VM's on the sun box allocating resources to each VM as its needed?

To be fair most of the saving will be in the saved context switches that are very processor intensive, due to having to flush the registers, TLB etc.

As above you can always migrate to VM's and sell the old hardware or re purpose it if there is still more CPU needed.

Add to that the fact that PC hardware (I know it's a sun, but the main parts are still x86) is only getting cheaper and a test of the VM option won't actually add significantly to the costs if at all.

Mark' date='

pffft that sounds like testing... I'd certainly get that going, then an nfs mount over ssh for attachments as there are several gig. Few other considerations along the way, but enough for a see how it goes.[/quote']

Testing you say :eek: my bad