1 |
On Sunday, November 20, 2016 09:06:26 AM Rich Freeman wrote: |
2 |
> On Sun, Nov 20, 2016 at 8:45 AM, Harry Putnam <reader@×××××××.com> wrote: |
3 |
> > "J. Roeleveld" <joost@××××××××.org> writes: |
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 |
> IMO over-committing CPU isn't actually THAT bad. The CPU obviously |
13 |
> gets divided n ways, but that's as far as it goes. There isn't that |
14 |
> much overhead switching between VMs (though there certainly is some). |
15 |
|
16 |
True, it's not too bad. The problem is, however, that the host-OS is special |
17 |
as it has to manage access to the various resources. For this reason, I tend |
18 |
to dedicate specific CPU-cores to the host. |
19 |
|
20 |
> Over-committing RAM on the other hand can definitely cause more |
21 |
> serious issues, because then you're dealing with swap. Dividing 1 CPU |
22 |
> 3 ways gives you 1/3rd of a CPU (but collectively the 3 VMs are |
23 |
> putting out close to a full CPU's worth of work). If you're |
24 |
> over-committing RAM and you go into swap, then the performance of all |
25 |
> your hosts might drop considerably, adding up to WAY less than the |
26 |
> total your box is capable of. |
27 |
|
28 |
VMWare actually did this worse with their desktop version a few years ago. Not |
29 |
sure if they still do this. |
30 |
What they did was to synchronize RAM with an on-disk copy. Only way to disable |
31 |
that was to edit the VM-config file using undocumented flags. I stopped using |
32 |
VMWare shortly after that. |
33 |
|
34 |
> If your host is windows then this isn't an option for you (seriously, |
35 |
> you should re-consider that), but if you could use a linux host |
36 |
> another solution is containers. In general they are FAR more flexible |
37 |
> around RAM use and of course RAM tends to be the most precious |
38 |
> commodity when you're running guests of any kind. With a container |
39 |
> you don't have to pre-allocate the RAM, so if Gentoo needs 8GB of RAM |
40 |
> right now it isn't as big a deal because in 15min when you're done |
41 |
> building it will go back down to 100MB or whatever it actually needs |
42 |
> to run. |
43 |
|
44 |
Containers are nice, I agree. Although I tend to see it more as a much better |
45 |
implementation of a chroot-jail. |
46 |
|
47 |
> Back when I was running Gentoo VMs I would typically set the RAM use |
48 |
> to something fairly minimal (think ~1GB or less). Then when I was |
49 |
> doing updates I'd up the setting to basically all the free RAM on my |
50 |
> host and allocate multiple CPU cores to it, then mount a tmpfs on |
51 |
> /var/tmp. When I was done building I'd shrink it back down to a |
52 |
> normal config. And I wouldn't be doing builds on multiple hosts at |
53 |
> once. |
54 |
|
55 |
Or use a dedicated build-server/VM. And only install binary packages on the |
56 |
VMs. This has the benefit of speeding up updates on the VMs themselves. |
57 |
|
58 |
> These days with containers I just run emerge on a few at a time and I |
59 |
> don't worry about it (still with /var/tmp on a tmpfs in each). Now, I |
60 |
> wouldn't go building chromium and libreoffice in multiple containers |
61 |
> at once that way, but for typical server-like guests very few packages |
62 |
> use THAT much RAM. |
63 |
|
64 |
That would be a good way to stress-test hardware though. :) |
65 |
Especially to check if the cooling is working as expected. |
66 |
|
67 |
-- |
68 |
Joost |