1 |
Mick wrote: |
2 |
> On Friday, 25 October 2019 06:31:03 BST Raffaele BELARDI wrote: |
3 |
>> 8-core CPU: |
4 |
>> |
5 |
>> EMERGE_DEFAULT_OPTS="--quiet-build --keep-going --jobs 9 --load-average 9" |
6 |
>> |
7 |
>> MAKEOPTS="-j9 -l9" |
8 |
>> |
9 |
>> Works fine except when both Firefox and Thunderbird need update, in that |
10 |
>> case emerge typically tries to build them in parallel and one gets OOM |
11 |
>> killed due to insufficient swap space (1G swap, 16G RAM). I will increase |
12 |
>> the swap but I'd like to know: Is there a way to tell emerge to normally |
13 |
>> run 9 parallel jobs but limit to 1 when it is building one of the two |
14 |
>> monsters? |
15 |
>> |
16 |
>> Thanks, |
17 |
>> |
18 |
>> raffaele |
19 |
> Good advice has already been given, but here are some supporting thoughts |
20 |
> based on my experience of trying to emerge mammoth builds on old systems with |
21 |
> low RAM. |
22 |
> |
23 |
> I can't recall how much memory each thread of a FF or TB compile chews up, but |
24 |
> if you allow for up to 2G per thread, with -j9 your 16G RAM *will* be |
25 |
> exhausted at some point. Swapping will commence then in earnest and a I/O |
26 |
> offloading of RAM into swap and back again as threads gasp for adequate memory |
27 |
> will be sustained, while demand for more RAM than available is present. This |
28 |
> creates a bottleneck which will prolong the emerge duration. With enough swap |
29 |
> you won't suffer any more OOMs, but you could find emerge times increase |
30 |
> exponentially. Therefore reducing the total number of jobs for these two |
31 |
> packages will help in both cases. |
32 |
> |
33 |
> Setting up an env directive as already advised in previous responses to |
34 |
> restrict both packages to fewer jobs will work, but in some cases it can be |
35 |
> suboptimal. When only one package needs updating, why should it be emerged at |
36 |
> a lesser speed than your system can support? Even when both packages are |
37 |
> emerged at the same time, the memory crunch may only take place for a limited |
38 |
> period, at a time when both packages will be using maximum memory per thread. |
39 |
> To make matters worse ebuilds and source code changes, compilers change and |
40 |
> trying to optimise your emerge soon becomes a moving beast, so some |
41 |
> experimentation will be necessary. |
42 |
> |
43 |
> I think reducing your job/load count to 1 would be excessive. Reducing it |
44 |
> down to 5 ought to be adequate, but I suggest to increase your swap. You |
45 |
> could just use a swap file for this purpose. |
46 |
> |
47 |
> PS. In an ideal AI world, portage would know how much memory is necessary for |
48 |
> a given package and would auto-adjust the number of jobs to minimise swapping |
49 |
> given any amount of RAM. In an even more ideal world, it would be able to do |
50 |
> this in real time. :-) |
51 |
> |
52 |
|
53 |
|
54 |
I agree that it would be nice if emerge could do that automatically, |
55 |
although I have no clue how to do that or even if it can be done at |
56 |
all. Back when I had less memory, I could let FF, LOo or another |
57 |
package run at full speed but only if it was only one of those packages |
58 |
at a time. Thing is, on occasion two or more of those updates would hit |
59 |
and due to the long compile times, end up compiling at the same time. |
60 |
Do you think there is a way for the devs to set up a method to tell |
61 |
emerge not to emerge certain packages at the same time? In other words, |
62 |
if Firefox is emerging, LOo is held until it is done or vice versa. |
63 |
Maybe even have it so others can be listed. The list of large packages |
64 |
are likely small but they can have a huge impact on systems with less |
65 |
memory. |
66 |
|
67 |
You think that a feature worth asking the devs about? Maybe they can |
68 |
figure out a way to implement that?? |
69 |
|
70 |
Dale |
71 |
|
72 |
:-) :-) |