We have a code build server, fedora 13, which was working at medium speed for 4 users. Speed means building a code branch took 1.5 hrs max duration. It was having one quad core, 8gb ram, 200gb hdd.

To increase the performance as well as the number of users to 8, its hw config is increased to 8 cores, 47gb ram, 2tb hdd. But now even when a single user is using the server it is very slow, it takes > 7hrs to build a code.

For increase in hw it is supposed to be faster. What can make it slow? If I reduce the swappiness 'll it help? Or a reinstallation of os isneeded?

Please help. New to linux server.

$ df -h  
Filesystem            Size  Used Avail Use% Mounted on
                       50G   32G   16G  67% /
tmpfs                  24G  204K   24G   1% /dev/shm
/dev/sda1             485M   47M  414M  11% /boot
                      213G   64G  138G  32% /usr2
/dev/sdb1             1.8T  158G  1.6T  10% /usr3

$ free -tg
              total       used       free     shared    buffers     cached
Mem:            47         43          3          0          3         35
-/+ buffers/cache:          4         42
Swap:            5          0          5
Total:          53         43          9

"Build the code" means what?

MOST compilersare terribly IO bound because they run through a lot of files. You would be a lot better to totally ditch the HD and get a decent SSD - which is more than 100 times faster in terms of IOPS thn the hard disc (and it is about IOPS, nearly never about MB/S).

You should be able to check that with the appropriate system tools (windows guy here) - but I am willing to bet your hard disc was inadequate to start with.

Now you upped the old slow hard disc with a bigger but prett ymuch same speed hard disc. Overload improoved - to more overload.

  • Build the code - The compiler runs through thousands of c++ files in a repository. Thanks! That is what I wanted to know that just increasing the HDD means IO takes too much time to do frequent read/write operation.
    – Bala
    Jul 8 '14 at 5:09
  • Yeah. ESPECIALLY C++ is terrible because you not only have tons of files, you also generate tons of interim files in C++, which the linker then combines. Generally you pretty much MUST use an SSD - any alternative is a lot more expensive (15k rpm SAS discs in a Raid 10) and will not keep up performance wise. C++ is known to be a disc burner during larger codebase compilations.
    – TomTom
    Jul 8 '14 at 5:11

There are too many things which can cause this. It could be one or even several of them at once. It sounds like you use VPS (Virtual Server) instead of a real physical hardware. VPS is known for things like you described since the actual underlying host could affect the performance as well. If your build is I/O bound, it may help to switch to a dedicated machine (with a proper RAID maybe) or find a better VPS. Also, you may want to look into your build system for additional optimizations (i.e. using more cores).

Without any specific information, there is no specific suggestion.

  • It is not VPS, it is a local dedicated build server accessed through LAN. The build system is highly optimized and as I mentioned it was able to build in 1.5 hrs before(in a very high end server 24 cores + 100 gb ram, it takes only 30 mins).We use "make -j8", which efficiently uses all 8 cores at a time to build.
    – Bala
    Jul 8 '14 at 4:28
  • In this case I would look into the build optimizations. Try -j12/-j16, RAM disk for temporary and/or build files, etc. I optimized one large build in the past which took about 2 hours to build. The changing storage space did not make much difference in the speed, but the build optimization decreased the build time to about 40 minutes when used RAM disks and finer tune up of -j switch. I also used ccache, but that may not be good for your build environment.
    – nochkin
    Jul 9 '14 at 0:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.