For Server gurus

[codymc12]

This will seem like a silly question to many - but it's genuine.

What are the KEY factors, in building a server, that determine it's ability to handle a heavy load, not just in terms of traffic, but in processing heavy requests, eg, video, php/mysql, etc?

CPU? RAM? Both? What's recommended in terms of those for a server that can really take a beating?

[RFlagg]

CPU (s) (as much as you can afford)

RAM (as much as you can afford)

Disk i/o, RAID if you're gonna run SQL

the faster the disk(s) the better off you will be.

Production SQL clusters running on quad Xeon 2GHz ea w/1GB RAM and 10K rpm drives (RAID 5 for the data) 8 SCSI drive array.

Production Web Servers, CPU not so important, but RAM and fast disk i/o more important.

[codymc12]

Thanks!

[SweetT]

Cody....

How have you been, dude? Please tell Mona I said "Hi".

I would be happy to help you figure out anything you need to know....as long as we can talk about some things that I have been wanting to ask you about ;)

Give me a call at the office 1.877.471.9075 x222


Thanks!


--T

[Fabuleux]

Originally posted by RFlagg
CPU (s) (as much as you can afford)

RAM (as much as you can afford)

Disk i/o, RAID if you're gonna run SQL

the faster the disk(s) the better off you will be.

Production SQL clusters running on quad Xeon 2GHz ea w/1GB RAM and 10K rpm drives (RAID 5 for the data) 8 SCSI drive array.

Production Web Servers, CPU not so important, but RAM and fast disk i/o more important.

This guy should win a prize for the best first post ever made...

[liquidmoe]

RAM will limit the number of processes you can run, so it will limit the number of connections if you run a ton. CPU is mainly for CGI, php, and other script processing, so if you plan to do alot of SQL or other scripts then make sure that you have enough cpu power to handle it.

Disk I/O is not usually that important for a lot of things so you can avoid having to go for a RAID, but if you want a boost in performance get a 15K drive. Again though if you want to squeeze the most out of your system go for RAID, but then only do it if your scripts require a lot of disk access, for plain reads and HTML,images it may not be as necessary, but it also depends on how many files you serve, etc.

Focus on RAM, then CPU, harddrives are almost never the bottleneck. And if you run more scripts then focus on CPU before RAM.

Hit me up on icq at 36837470 if you have any questions.

[codymc12]

T - Great talking to you again.

Moe - sent auth request on ICQ.

[RFlagg]

Originally posted by Fabuleux


This guy should win a prize for the best first post ever made...

Thx...

10 Yrs in the IT biz...

last 3 yrs in the Adult biz...

lurking on GFY fer a year...

I thought it was time...

[toddler]

wow, i'm glad ya'll do porn. Look,
all of the components of a machine are important. Disk _IS_ important. Where do you think you DB lives? Slow diskhahahahaslow
dbhahahahaslow site.

Also pay attention to bus speed and link. The fastest proc/ram/disk in the world won't do you much good on a 100Mhz bus.

I'd be curious to see how many of the people with 'super huge' machines actually really need them. My experience in mainstream and _some_ adult work is that they don't. They DO however need to write better code, and learn how to build a db that makes sense and use indexes.

[keyDet79]

Originally posted by RFlagg
Production SQL clusters running on quad Xeon 2GHz ea w/1GB RAM and 10K rpm drives (RAID 5 for the data) 8 SCSI drive array.

Production Web Servers, CPU not so important, but RAM and fast disk i/o more important.

Why? Databases run in ram, don't they?

[toddler]

Originally posted by keyDet79


Why? Databases run in ram, don't they?

I hope you're kidding.

[keyDet79]

Originally posted by toddler


I hope you're kidding.

I don't think so, large DBs require lots of RAM, *fast* RAM (but dual servers only accept ECC/REG memory anyway). Also, a RAID is only interesting if you need a *fast* drive (serving movies or large files for example), if you are serving html or php you probably need faster access times and less speed (ie SCSI or Serial ATA if your budget is smaller). Also keep in mind Xeon 2.0 has a much slower bus than the new generation 2.4. Always go for that one instead of 2.0. For the rest liquidmoe was right.

[Mr. Porno King]

If your server has enough RAM to cache the files used in the most common requests, then io bottlenecks are meaningless.. but when you start optimizing servers in this way, you have to analyse the application more closely than the general description you gave.

When you are planning on serving large numbers of requests, you get multiple servers, each optimized to its task.

[RFlagg]

Originally posted by keyDet79


I don't think so, large DBs require lots of RAM, *fast* RAM (but dual servers only accept ECC/REG memory anyway). Also, a RAID is only interesting if you need a *fast* drive (serving movies or large files for example), if you are serving html or php you probably need faster access times and less speed (ie SCSI or Serial ATA if your budget is smaller). Also keep in mind Xeon 2.0 has a much slower bus than the new generation 2.4. Always go for that one instead of 2.0. For the rest liquidmoe was right.

How exactly are you getting faster access time with less speed?

and the Xeon 2GHz was an example of a box in service already, not a shopping list for a new SQL box.

When building hardware for general internet consumption & use it has been my experience that using IDE drives is french for go back to the store 2 monthes from now and buy SCSI this time, they are built for multi-user(process) reads & writes, an IDE drive just can't take the beating (for long). You can put the OS on an IDE but anything served should be on a SCSI...

[toddler]

Originally posted by keyDet79


I don't think so, large DBs require lots of RAM, *fast* RAM (but dual servers only accept ECC/REG memory anyway). Also, a RAID is only interesting if you need a *fast* drive (serving movies or large files for example), if you are serving html or php you probably need faster access times and less speed (ie SCSI or Serial ATA if your budget is smaller). Also keep in mind Xeon 2.0 has a much slower bus than the new generation 2.4. Always go for that one instead of 2.0. For the rest liquidmoe was right.

Yes, large DB's should have lots of RAM. However, I've personally played with multi hundred Gig databases. Trust me, you need fast disk, with good seek times. Remember, you have to get your data off the disk, down the bus, and into ram before you can use it.

RAID is NOT interesting if you need 'speed' alone. In fact in many cases RAID will slow you down, but in those cases the integrity of your data is/should be more important to you.

Should probably throw out here that I deal with a LOT of solaris and linux machines, some free/open bsd, and very little windows.

[keyDet79]

Originally posted by toddler
RAID is NOT interesting if you need 'speed' alone. In fact in many cases RAID will slow you down, but in those cases the integrity of your data is/should be more important to you.

It would only slow you down if you use software raid instead of hardware. Raid just increases (or doubles if its 2 drives) your rpm so to speak. And a lot of rpm (rotations per minute) is not very useful if you are serving small files / web pages.

'Multi hundred Gig databases'? Best choice would be a separate mysql server with SCSI RAID, preferably on a 64bit CPU (like dual AMD Opteron) and OS, certainly. Considering the speed increase if you use the 64 bits version of mysql. But if we are talking about databases of a few gigs or less, that shit just gets loaded into RAM.

[toddler]

Originally posted by keyDet79


It would only slow you down if you use software raid instead of hardware. Raid just increases (or doubles if its 2 drives) your rpm so to speak. And a lot of rpm (rotations per minute) is not very useful if you are serving small files / web pages.

'Multi hundred Gig databases'? Best choice would be a separate mysql server with SCSI RAID, preferably on a 64bit CPU (like dual AMD Opteron) and OS, certainly. Considering the speed increase if you use the 64 bits version of mysql. But if we are talking about databases of a few gigs or less, that shit just gets loaded into RAM.

I think you may need to go reread some documentation.

[keyDet79]

Originally posted by toddler


I think you may need to go reread some documentation.

If you say so

[senseidru]

keyDet79 vs. toddler

we must settle this with mortal combat

[Azathoth]

This is funny

I'm with toddler on this one.

Plenty of RAM and CPU power is good but
it also heavily depends on how the site(s)
is/are written.

keyDet79 needs to do some reading on
RAID and it's different levels aswell as how
MySQL caches queries/data in memory.
Not whole databases/tables

[toddler]

Originally posted by Azathoth
This is funny

I'm with toddler on this one.

Plenty of RAM and CPU power is good but
it also heavily depends on how the site(s)
is/are written.

keyDet79 needs to do some reading on
RAID and it's different levels aswell as how
MySQL caches queries/data in memory.
Not whole databases/tables

exactly. Cacheing is great. Esp in the later versions of mysql (>4.0) Sure, some data will be in RAM, but most will be on disk.

[SinisterStudios]

I have 10 years IT experience, the last 4 in designing and building websystems for IBM. Buy the most you can afford, the Xeon processors machines are your best bet, they can handle many more instructions than the normal pentium 4 processors and the faster cache and bus speed will make a huge difference. Also whatever you do DO NOT RUN WINDOWS on the server if you want the best performance, we have had the best luck running Debian linux on dual processor cheaper servers (dual 800mhz servers with 1 gig of ram in each and 2 18 gig scsi drives) setup in a lvs cluster (so you can pop in machines as your traffic grows)
All this software is free and availible on the web and with just alittle linux experience you can have a smoking system for very little money. ICQ me and i can explain it more to anyone interested

ICQ 3583065

[footguy]

I didn't see a mention of a real operating system.. What good is all that hardware if you aren't running FREEBSD?

[toddler]

Originally posted by footguy
I didn't see a mention of an operating system.. What good is all that hardware if you aren't running FREEBSD?

Free is great. Best network stack in production right now. My largest issue with free/open and even linux is that a lot of sw vendors don't right code to them. Standard apps sure, but the kinds of thins that I run (very large CAD apps) tend to run on solaris/hpux. In some cases linux, in fact more vendors are porting their code, but it takes time. Now with RH doing their fuckall pricing dance with Advanced Server....well, suffice it to say I'm not at all happy with RH right now. Nor are many of my cohorts.

[footguy]

Code.... yes true...

BSD runs virtually all Linux binaries and in some cases a lot faster than Linux.

We keep throwing kudos around in here.. I think the folks at FreeBSD and Apache deserve metals.

Honestly though all operating systems have progressed to the point where they are decent.... BSD they are not but definitely quite stable and useful.

[toddler]

Originally posted by footguy
Plus BSD runs virtually all Linux binaries and in some cases a lot faster than Linux.

We keep throwing kudos around in here.. I think the folks at FreeBSD and Apache deserve metals.

Honestly though all operating systems have progressed to the point where they are decent.... BSD they are not but definitely quite stable and useful.

Expand that to include mysql and PHP and I wholly agree

[footguy]

I can't believe I just spelled medals meTals........

[toddler]

Originally posted by footguy
I can't believe I just spelled medals meTals........

Hey, an award is an award....better real platinum than fake silver...

[dnsmonster]

Disk i/o, RAID if you're gonna run SQL

What does RAID have to do with running an SQL server? RAID is imporant for redundance. 99.99% of RAID controllers are in fact slower that straight-up single drive solution but that's the hit you take by ensuring your data is stored more reliably. If you buy a standalone RAID controller make sure you get the one with the most cache since that usually elevates some load from the drives.

Nobody mentioned redundant power supplies. Most colocation facilities have 2 power backbones, A and B. If you get redundant supplies you are pretty much secure as far as power goes, provided your facility has reliable battery and diesel backup.

My toys:



If you have more than 1 server, connecting them with fiber and intalling MOSIX might be a very good idea, solves a lot of heavy traffic issues.

Cluster-up baby!

[toddler]

Originally posted by dnsmonster
[B]

What does RAID have to do with running an SQL server? RAID is imporant for redundance. 99.99% of RAID controllers are in fact slower that straight-up single drive solution but that's the hit you take by ensuring your data is stored more reliably. If you buy a standalone RAID controller make sure you get the one with the most cache since that usually elevates some load from the drives.

Nobody mentioned redundant power supplies. Most colocation facilities have 2 power backbones, A and B. If you get redundant supplies you are pretty much secure as far as power goes, provided your facility has reliable battery and diesel backup.

See? Not just me that says it...

You need to make damn sure those dual lines are from seperate feeds however. I can tell you we moved 400 servers out of verio SD because they told us they did, and they didn't.

Also a good thing to make sure you see their maint schedule for that backup gen. and enough fuel either on hand, or a preagreed contract for the petrol for a few days running at load. Many colo's I know personally don't.

[PbG]

Nobody mentioned the nick card either. The wrong one and/or lack of two will most definitely present a bottleneck when trying to push 100+GB per day out of a server P4, Xeon or otherwise regardless of the OS.