| 1 |
Am Sun, 19 Feb 2017 13:53:49 +0100 |
| 2 |
schrieb Helmut Jarausch <jarausch@××××××.be>: |
| 3 |
|
| 4 |
> Hi, |
| 5 |
> |
| 6 |
> sometime I have some memory hungry ebuilds in the background, when I |
| 7 |
> start (e.g.) Chromium which needs very much memory if you have a lot |
| 8 |
> of open tabs. |
| 9 |
> |
| 10 |
> In that case my system nearly freezes. I cannot even kill chrome. |
| 11 |
> What can I do in that case. (Remote login doesn't work either) |
| 12 |
> |
| 13 |
> Can I have any additional program (like Chromium) die if there is |
| 14 |
> not enough memory. |
| 15 |
|
| 16 |
You may want to switch to the deadline scheduler and see if it improves |
| 17 |
things. For my setup, it did (bcache involved). |
| 18 |
|
| 19 |
But I'm pretty sure my usage pattern is a bit different, I'm emerging |
| 20 |
in a tmpfs (I have 16 GB of RAM), so every big ebuild probably forces |
| 21 |
data going to swap. Actually, all my three hard disks have a 10 GB swap |
| 22 |
partition in front with same priority. The file system itself is cached |
| 23 |
through bcache, so it should be mostly decoupled (this means, put swap |
| 24 |
to mostly idle disks). But I was still seeing extensive freezes until I |
| 25 |
switched to the deadline scheduler. Kernel 4.10, which brings write-back |
| 26 |
throttling, will probably help also (and maybe I can switch back to |
| 27 |
CFQ then to benefit from ioprio again). |
| 28 |
|
| 29 |
The problem is something like buffer bloat known from networking: |
| 30 |
Writes queue up in a long queue, and even small writes will block your |
| 31 |
applications. CFQ tends to build really long such queues while it tries |
| 32 |
to maintain "fairness". Deadline instead tries to service write |
| 33 |
requests as fast as possible after a short timeout (which can be |
| 34 |
configured in sysfs). Even then, a huge queue can still pile up, so I |
| 35 |
suggest you reduce dirty_background_bytes to a sane value (the default |
| 36 |
percent values really don't play well with amounts of RAM installed |
| 37 |
today): |
| 38 |
|
| 39 |
vm.dirty_background_bytes = 134217728 |
| 40 |
|
| 41 |
This makes processes with dirty data block much earlier and should |
| 42 |
reduce the queue. You may want to lower it even more and see how your |
| 43 |
system behaves. There's a chance that these shorter queues can be |
| 44 |
written before the whole system blocks (because dirty_bytes is |
| 45 |
exhausted). At least it should reduce the time until the system becomes |
| 46 |
responsive again. |
| 47 |
|
| 48 |
I think that swap space is there and is cheap to use most of the time, |
| 49 |
so you should encourage your system to use it and use it early (prefer |
| 50 |
caching over parking dead memory blocks in RAM). The problem comes when |
| 51 |
your system is already stalled by other IO - which apparently is the |
| 52 |
case most of the time when the system needs to start using swap. The |
| 53 |
only fix is to keep the IO queues short. The knobs mentioned above |
| 54 |
should help you with that. |
| 55 |
|
| 56 |
-- |
| 57 |
Regards, |
| 58 |
Kai |
| 59 |
|
| 60 |
Replies to list-only preferred. |
Archives