1 |
On Friday, 30 April 2021 02:30:51 BST Adam Carter wrote: |
2 |
> On Wed, Apr 28, 2021 at 7:58 PM Kai Peter <kp@×××××××××××.org> wrote: |
3 |
> > Hi, |
4 |
> > |
5 |
> > I have an issue with a machine where I'm not able to detect the real |
6 |
> > root cause. It hangs up totally. It seems like it was running out of |
7 |
> > memory - but why? Hopefully somebody can give me some insight. As far I |
8 |
> > can see right now, it hangs up a few hours after an `emerge --update |
9 |
> > --newuse --deep --with-bdeps=y @world`. |
10 |
> > |
11 |
> > The machine is an Intel Atom with 8 GB RAM (physical, max) and 24 GB |
12 |
> > swap (a file). So 32 GB RAM in total. |
13 |
> |
14 |
> Might be worth adding zswap using zstd or lz4 to your config (uses more CPU |
15 |
> for less IO) |
16 |
> https://www.kernel.org/doc/html/latest/vm/zswap.html |
17 |
|
18 |
Zswap will help optimise the swapping of cold pages out of RAM into the |
19 |
compressed zswap cache and eventually push these out to the disk. This won't |
20 |
help with the problem of not having enough RAM to start with for compiling |
21 |
packages with large resource requirements, like e.g. Chromium. |
22 |
|
23 |
With monster packages where more RAM is needed even for a single compilation |
24 |
job, after all cold pages have been swapped out, hot pages will start being |
25 |
swapped out/in. I think at this point the same I/O race condition will ensue |
26 |
as if no zswap were available, plus a compress/decompress CPU load. I guess |
27 |
the point of starting to thrash the on-disk swap trying to free RAM may start |
28 |
sooner, since RAM which would otherwise be available for the single |
29 |
prioritised compilation job is now being used by zswap. So, there would be a |
30 |
sweet spot in using zswap to improve I/O performance, but it could end up |
31 |
becoming a disbenefit on compilation of RAM hungry packages. |
32 |
|
33 |
Please correct my reasoning above if I have misunderstood how zswap works. |
34 |
|
35 |
However, the OP problem here seems to be with a leaky BIND? |
36 |
|
37 |
I found this mentioned upstream - but have not check BGO: |
38 |
|
39 |
https://gitlab.isc.org/isc-projects/bind9/-/issues/446 |
40 |
|
41 |
|
42 |
> If you want to see which processes are using the most memory, run top then |
43 |
> type 'M' to have top sort by memory instead of CPU. You can also type 'm' |
44 |
> to make top show the memory numbers as an ascii bar graph. The man page |
45 |
> explains what VIRT RES SHR mean. |