Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a workstation that 3 people log into for compiling source code. Our project consists of about 1000 files and GCC compiles that to a ~200MB .elf file (with debug).

Our current workstation is an Intel Core 2 CPU X6800 @ 2.93GHz with 2 software-RAID0 SATA 7.2K RPM drives and 8GB of memory.

The system works well when 1 person is doing a compile, but things slow down dramatically when 2 people try to do a compile at the same time. Using distcc to distribute compilation to other servers helps some, but of course that doesn't help the link time. The link can take a long time.

What would be a good hard-drive/memory configuration for a new server? I'm hoping to spend less than $5-6K total. For example:

  1. Is RAID0 a good idea for this workload? I've heard RAID0 may hurt seek time, which I imagine might hurt when compiling lots of small files?

  2. If I want to support 3 developers, would it be better to buy 3 cheap machines, or 1 big server for my price range?

  3. Given my price range, should I consider 15K SCSI drives? Or would 2 SW/HW-RAID0 SATA 7.2K drives perform almost as well?

Example loading during 2 makes:

Tasks: 238 total,   1 running, 237 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.5% us,  3.5% sy,  0.6% ni, 90.0% id,  4.3% wa,  0.0% hi,  0.1% si
Mem:   8096556k total,  8052960k used,    43596k free,    50248k buffers
Swap:  2040212k total,      224k used,  2039988k free,  6745740k cached

18972 user1     15   0  138m 131m 1076 D   10  1.7   0:03.25 ld
 3414 user2     18   0  6148 1024  476 D    8  0.0   0:14.97 mv
18975 user3     18   0 61672  12m  652 D    6  0.2   0:00.52 make
share|improve this question
up vote 1 down vote accepted

Greetings. This is a good question and I recently had to deal with similar. Although looking at memory and CPU are important you'd be surprised at what a huge difference hard drive I/O makes during compiling code. I was tasked with finding new development machines for our devs, granted the parameters were a bit different... these are C# developers, checking out of SVN and compiling C# code but the end product should be fairly similar. Read the following journal entry from my boss with our findings:

In the end we found that SSD drives, a core i5 or i7 cpu and a 64bit OS made a huge difference.

share|improve this answer
Thanks for the compiler performance data! – user34327 Feb 10 '10 at 4:33

Since you currently have an existing system, take time to look at it. Find out if your current system is cpu, memory, or I/O bound during a compile. Then buy equipment to address the weakest link.

I don't do much compiling, but in most cases I have seen the weakest point tends to be related to CPU/Memory more then I/O.

share|improve this answer
Good point - I updated my description above to show a common "top" output. I'm not sure what's going on, but it doesn't seem CPU-bound. I notice that all I/O (like doing a find or grep) slows down dramatically when someone is doing a compile. Is RAID0 hurting things or making them better? – user34327 Feb 9 '10 at 19:29
When you say software RAID 0 are you using the motherboard RAID controller, or are you using the linux software RAID. It is possible that a poor software RAID0 may actually be worse then what you would get with a single drive. If you are using the motherboard RAID I would try the Linux software RAID instead. Also, you might actually gain performance by separate partitions on your two drives and no RAID. Have one compile process working off a partition off one drive, and one using a partition on the other. – Zoredache Feb 9 '10 at 23:12
We're using the Linux software RAID 0 that comes with RedHat Enterprise Linux 4. Perhaps I'll try putting in another drive and looking at the performance of a single drive. – user34327 Feb 10 '10 at 0:56

I can't comment on what factors contribute to GCC performance for your workload but in general you are looking for more CPU grunt and more RAM\more bandwidth. It might be worth considering just buying a proper server for this.

Cost wise you should be able to get a dual socket server with Xeon 5520's and 12Gig of 1333Mhz DDR3 RAM for that sort of budget (~6k). That gives you quadruple the number of cores, plus the boost from hyperthreading which is easily worth another core or two. Aggregate main memory bandwidth is also about 4 times faster (6 channels @ 1333Mhz, vs 2 @ 1066Mhz). Clock for clock the 5520's leave the Core Duo's in the dust too. And you'll be getting the benefit of a more modern IO subsystem.

Throw in a pair of Intel X25M's in RAID 0 as a scratch workspace for the compiles and you should be able to smoke the performance of the Core2 X6800 workstation with ease. For the size of files you are dealing with even the smallest Flash SSD's should do the trick.

share|improve this answer

I'd tend to agree with Zoredache here, although your CPUs are 90% idle in the top print you've given.

The memory usage of user2 seems quite extensive at 1GB (unless that's in K which I don't think it is, could be wrong though.) If it is 1GB, it'd be interesting to know what they were moving ("mv" command) to take up that much memory.

The link phase does seem to be the most CPU-intensive (as you've already figured out.) If this was my system, I'd be tempted to look at the memory usage, and probably analyse iostat output during a compile.

Is this the quad-core version of the processor, or dual-core? Either way it's quite a powerful workstation, so I don't think chucking any more hardware at it will help that much. Like Zoredache says, better to analyse the system you've got, identify the bottlenecks and work on them.)

share|improve this answer
It's a dual-core system. Thanks - I'll try running iostat and see what information pops up. The values from top of in kb (unless modified by a letter). – user34327 Feb 9 '10 at 20:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.