1 |
On Sun, Nov 20, 2016 at 8:45 AM, Harry Putnam <reader@×××××××.com> wrote: |
2 |
> "J. Roeleveld" <joost@××××××××.org> writes: |
3 |
> |
4 |
>> Also, overcommitting CPUs has a bad influence on performance, |
5 |
>> especially if the host wants to use all cores as well. |
6 |
> |
7 |
> That is what I asked advice about. What do you call |
8 |
> `overcommitting'. For example with only 1 Vbox vm started and no |
9 |
> serious work being done by the windwos-10 os. On an HP xw8600 with |
10 |
> older 2x Xeon 5.60 3.00Ghz with 32 GB ram |
11 |
> |
12 |
|
13 |
IMO over-committing CPU isn't actually THAT bad. The CPU obviously |
14 |
gets divided n ways, but that's as far as it goes. There isn't that |
15 |
much overhead switching between VMs (though there certainly is some). |
16 |
|
17 |
Over-committing RAM on the other hand can definitely cause more |
18 |
serious issues, because then you're dealing with swap. Dividing 1 CPU |
19 |
3 ways gives you 1/3rd of a CPU (but collectively the 3 VMs are |
20 |
putting out close to a full CPU's worth of work). If you're |
21 |
over-committing RAM and you go into swap, then the performance of all |
22 |
your hosts might drop considerably, adding up to WAY less than the |
23 |
total your box is capable of. |
24 |
|
25 |
If your host is windows then this isn't an option for you (seriously, |
26 |
you should re-consider that), but if you could use a linux host |
27 |
another solution is containers. In general they are FAR more flexible |
28 |
around RAM use and of course RAM tends to be the most precious |
29 |
commodity when you're running guests of any kind. With a container |
30 |
you don't have to pre-allocate the RAM, so if Gentoo needs 8GB of RAM |
31 |
right now it isn't as big a deal because in 15min when you're done |
32 |
building it will go back down to 100MB or whatever it actually needs |
33 |
to run. |
34 |
|
35 |
In general Gentoo doesn't need a lot of RAM to operate, it is a fairly |
36 |
minimal distro in general. Now, obviously if you're running webkit |
37 |
then you're running it as more of a desktop and that is going to |
38 |
consume a lot more RAM than a console-based system, on any distro. If |
39 |
anything you could still tweak USE flags and CFLAGS to reduce your RAM |
40 |
footprint compared to most distros (whether this is worthwhile is |
41 |
another matter). However, the one exception to this is when you're |
42 |
building things. Ideally when you're building you want to use lots of |
43 |
cores, which means more gcc instances using more RAM each, and you |
44 |
want to be doing all of this on a tmpfs that uses even more RAM. |
45 |
|
46 |
Back when I was running Gentoo VMs I would typically set the RAM use |
47 |
to something fairly minimal (think ~1GB or less). Then when I was |
48 |
doing updates I'd up the setting to basically all the free RAM on my |
49 |
host and allocate multiple CPU cores to it, then mount a tmpfs on |
50 |
/var/tmp. When I was done building I'd shrink it back down to a |
51 |
normal config. And I wouldn't be doing builds on multiple hosts at |
52 |
once. |
53 |
|
54 |
These days with containers I just run emerge on a few at a time and I |
55 |
don't worry about it (still with /var/tmp on a tmpfs in each). Now, I |
56 |
wouldn't go building chromium and libreoffice in multiple containers |
57 |
at once that way, but for typical server-like guests very few packages |
58 |
use THAT much RAM. |
59 |
|
60 |
|
61 |
-- |
62 |
Rich |