Difference between revisions of "Designing a Server"
| Line 26: | Line 26: | ||
== Database Server == | == Database Server == | ||
| − | In this sense, a 'database server' is anything that is both write and read intensive. I remember planning out a piece of software that for awhile I thought was innovative until I realized | + | In this sense, a 'database server' is anything that is both write and read intensive. I remember planning out a piece of software that for awhile I thought was innovative until I realized I had just invented filesystems. It doesn't need to run a bona-fide 'database' to qualify, it could be something that just manipulates files a lot. |
In any case, a db server is generally the heavyweight of the bunch. They need a lot of RAM, they use a lot of disk I/O, and compared to file/backup servers, are actually somewhat CPU intensive. | In any case, a db server is generally the heavyweight of the bunch. They need a lot of RAM, they use a lot of disk I/O, and compared to file/backup servers, are actually somewhat CPU intensive. | ||
Revision as of 01:31, 14 May 2014
So, you have got yourself a domain and have picked a hosting company. Possibly an active site already - either way, you decide you need a server, either dedicated or colocated.
The CPU almost always gets top billing from every hosting company out there.
CPU power is cheap. Disk space is cheap. Memory is cheap. Bandwidth is precious.
Unless you have a specific situation that you know alleviates it, the limiting factor of your server is going to be your disks' (yes, plural) bandwidth. The more you have, and the faster they are, the better your server will perform. It should be your primary consideration when purchasing a server.
Memory should be your second consideration. RAM can help alleviate disk bandwidth, especially for platter drives. The less writing that will be done on your drives, the more memory can have an impact.
While it is possible to run into cpu-limiting situations, this is something you will generally be aware of ahead of time, and can plan accordingly. If you just want something for your website, however large, chances are the CPU will not be your problem.
About RAID
My first experience with a RAID controller was when the controller died on my first webhost.
My fourth experience with a RAID controller went okay, but RAID 10 turned out to be barely faster than a single drive plugged straight into the motherboard, since caching was disabled, and was only 40% faster than a single RAID 1 pair.
Since my primary I/O activities were because of my databases, I could easily divide my I/O into near-equal halves. My twin RAID 1 setup was both faster and more reliable than my RAID 10 design.
What I do currently, instead of subjecting my servers to another potential point of failure, is to simply mirror all of the content onto a slave server. If my main server fries, I have an up-to-the-second backup, and can bring that backup live in an hour or so while the main server gets fixed.
"An hour or so" may not be an option for some businesses. Even still, my temptation at this point would be to look into load balancing first.
Database Server
In this sense, a 'database server' is anything that is both write and read intensive. I remember planning out a piece of software that for awhile I thought was innovative until I realized I had just invented filesystems. It doesn't need to run a bona-fide 'database' to qualify, it could be something that just manipulates files a lot.
In any case, a db server is generally the heavyweight of the bunch. They need a lot of RAM, they use a lot of disk I/O, and compared to file/backup servers, are actually somewhat CPU intensive.
I am not kidding above about dividing database i/o in half:
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 1.48 19.98 14.46 458222973 331670564 sdb 12.56 11.67 189.13 267644581 4336877660 sdd 4.56 1.15 402.12 26346994 9220655384 sdc 31.83 104.94 405.29 2406284973 9293350004
sda hosts my boot, root, and home partitions (which includes my websites proper), and is an SSD. sdb primarily holds logs - including the binlogs, InnoDB redo logs, standard MySQL logs, etc. and is a 10krpm Raptor drive. sdc hosts my databases proper, and is an SSD. sdd hosts InnoDB's doublewrite buffer (ibdata1), and not much else. As you can see, the write rate of sdd and sdc are nearly identical.
As a result, if you have three or more physical drives available, and you are using MySQL, dedicating two of them to InnoDB is a solid plan. If you only have two drives, you'll want to be careful about dividing the load between them. If you only have one drive... why do you only have one drive in your database server?
Regardless of software, however, you want to try to share load between physical disks. RAID (1)0 and 5/6 makes this easier, but they are not necessarily faster, at least for smaller servers like mine.