From: Christian Gagneraud <chgans@gna.org>
To: Chris Tapp <opensource@keylevel.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: Server specs for a continuous integration system
Date: Wed, 04 Sep 2013 14:45:53 +1200 [thread overview]
Message-ID: <52269EE1.5040801@gna.org> (raw)
In-Reply-To: <90830908-76F2-4548-97F1-E9BF53E16597@keylevel.com>
On 04/09/13 07:22, Chris Tapp wrote:
>
> On 3 Sep 2013, at 00:29, Christian Gagneraud wrote:
>
>> On 03/09/13 10:16, Chris Tapp wrote:
>>> On 2 Sep 2013, at 22:45, Christian Gagneraud wrote:
>>>
>>>>
>>>> On 03/09/13 00:35, Burton, Ross wrote:
>>>>
>>>> Hi Ross,
>>>>
>>>>> On 2 September 2013 06:05, Christian Gagneraud <chgans@gna.org> wrote:
>>>>>> So right now, I'm thinking about:
>>>>>> - CPU: Xeon E5, maybe 2 x E5-2670/90, for a total of 16 cores (32 threads)
>>>>>> - Hard drives: 500GB, 1 TB or 2 TB (ideally with RAID if it can speed up the
>>>>>> builds)
>>>>
>>>> RAID-5 seems to be what i am after.
>>
>> Hi Chris,
>>
>>> Isn't RAID-5 going to be slower, especially if it's software? RAID 1
>>> is probably better as you'll potentially double the write speed to disk.
>>> I use a couple of Vertex SSDs in RAID 1 giving a theoretical write speed
>>> near to 1GBs. Write endurance is possibly a concern, but I've not had
>>> any issues using them on a local build machine. I would probably look at
>>> some higher end models if I was going to run a lot of builds. A lot less
>>> noise than hard drives ;-)
>>
>> Thanks for the info, i will have a look at RAID-1, as you can see, I know absolutely nothing about RAID! ;)
>
> Did you see my correction to this? I meant to say RAID 0. Sorry for the confusion.
No problem, at least it forces me to look at RAID-5, RAID-1 and now
RAID-0, thanks! ;)
>
>> Does SSD really help with disk throughput? Then what's the point of using ramdisk for TMPDIR/WORKDIR? If you "fully" work in RAM, the disk bottleneck shouldn't be such a problem anymore (basically, on disk, you should only have your yocto source tree and your download directory?).
>
> Running from RAM would be fastest - it really comes down to how much you have and how much you want to keep.
>
>>
>>>
>>>>>> - RAM: i don't really know, maybe 8 or 16 GB or more?
>>>>>
>>>>> At least 16GB of RAM for the vast amount of disk cache that will give
>>>>> you. 32GB or more will mean you can easily put the TMPDIR or WORKDIR
>>>>> into a tmpfs (there's been discussion about this a few weeks ago).
>>>>
>>>> Yes, I remember that one now, well spotted!
>>>>
>>>>> I've 16GB of RAM and a 8GB tmpfs with rm_work was sufficient for
>>>>> WORKDIR which gave a 10% speedup (and massive reduction on disk wear).
>>>>
>>>> I'm a bit surprise to see only a 10% speedup.
>>>
>>> I looked at this a while back on a quad core + hyper-threading
>>> system(so 8 cores). Depending on what you're building, there are significant
>>> periods of the build where even 8 cores aren't maxed out as there's not
>>> enough on the ready list to feed to them - basically there are times
>>> when you're not CPU, memory or I/O bound. I've estimated that being able
>>> to max out the CPUs would cut 20-25% of the build time, but the
>>> build-time dependencies mean this isn't easy/possible. At one point I
>>> inverted the priority scheme used by the bitbake scheduler and it (very
>>> surprisingly) made no difference to the overall build time!
>>
>> I have the same configuration here (4 cores, 8 threads), although, i didn't try to tweak bitbake, but i've noticed the same phenomenon as you: even with "aggressive" parallelism settings, the machine wasn't optimally loaded over time.
>>
>>>
>>> I ran builds with 16 threads and 16 parallel makes and the peak
>>> memory usage I see is something like 8GB during intensive
>>> compile/link phases, so 16GB for RAM and tmpfs sounds like a
>>> reasonable minimum. The tmpfs would reduce SSD wear quite a bit ;-)
>>
>> The quantity of RAM boils down to the budget, after a (very) quick search, i have estimated the cost of 64GB of RAM to be 1500 to 2000 US$.
>
> That sounds high - I generally get 16GB DDR 1600 for less that 150 US$ - it was quite a bit lower a year back!
>
>>
>> Thanks.
>> Chris
>>
>>
>>>
>>>>
>>>>> Others have machines with 64GB RAM and use it for all of TMPDIR, at
>>>>> which point you'll be almost entirely CPU-bound.
>>>>
>>>> OK, so 16GB sounds like a minimum, 32GB or 64GB being even better, at that size, this is not that cheap...
>>>>
>>>> Thanks,
>>>>
>>>> Chris
>>>>
>>>>>
>>>>> Ross
>>>>>
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>> Chris Tapp
>>>
>>> opensource@keylevel.com
>>> www.keylevel.com
>>>
>>>
>>>
>>
>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
next prev parent reply other threads:[~2013-09-04 2:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-02 5:05 Server specs for a continuous integration system Christian Gagneraud
2013-09-02 12:35 ` Burton, Ross
2013-09-02 21:45 ` Christian Gagneraud
2013-09-02 22:16 ` Chris Tapp
2013-09-02 23:29 ` Christian Gagneraud
2013-09-03 1:04 ` Elvis Dowson
2013-09-03 3:06 ` Christian Gagneraud
2013-09-03 8:55 ` Elvis Dowson
2013-09-04 3:02 ` Christian Gagneraud
2013-09-03 19:27 ` Chris Tapp
2013-09-03 19:22 ` Chris Tapp
2013-09-04 2:45 ` Christian Gagneraud [this message]
2013-09-04 3:47 ` Elvis Dowson
2013-09-13 5:58 ` Khem Raj
2013-09-03 11:57 ` lothar
2013-09-03 19:17 ` Chris Tapp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52269EE1.5040801@gna.org \
--to=chgans@gna.org \
--cc=opensource@keylevel.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.