(IMHO) In order of importance: #1 Disk I/O #2 Network I/O #3 Disk Space #4 RAM #5 CPU Disk I/O is a biggie with the more open source projects you add on to your mirror. You'll be doing a lot of reading, and potentially a lot of writing during periods when your mirror is fetching large chunks of new content (point releases tend to do that). At least in our experience any load average spikes have been related to disk i/o or network i/o (ie, pushing 800mbits on a 1gbit link without a tcp offload engine). Ram is also not a huge deal if you configure your httpd to be memory efficient. You'll be serving up mostly static content so the usual memory hogs like php, perl, etc.. are a non-issue. That and if you're network and disk i/o aren't the source of the bottle neck then these files are in and out of memory very very quickly. -- Ben On Tue, 2012-03-27 at 13:59 -0700, Tom Perrine wrote: > On 3/27/12 1:48 PM, John 'Warthog9' Hawley wrote: > > As much ram as you can reasonably afford and fast, and large, disk. The > > number of cores doesn't really play as much of a roll in a normal mirror > > as those two factors do. > > I was thinking 32G RAM and maybe 600G (2x300G) in RAID0. I figure I need the spindles and read speed more than I need > redundancy; I can always just re-mirror the content. > > > > _______________________________________________ > CentOS-mirror mailing list > CentOS-mirror at centos.org > http://lists.centos.org/mailman/listinfo/centos-mirror -- Benjamin Hamilton, RHCE Systems Engineer MetroCast Cablevision