On Fri, Jan 31, 2020 at 10:22 AM stakanov <stakanov@eclipso.eu> wrote:
In data venerdì 31 gennaio 2020 08:04:27 CET, Andrei Borzenkov ha scritto:
the system turns responsive" it is far too vague to make any useful comment. It
On this one: when you have the aforementioned condition (that is curiously triggered always when you use the touchpad (but that can be a causality thing because you will note consciously it does not respond any more, while if you do not use the touchpad probably you wont). But for the sake of it: what happens if it is unresponsive and what do I mean with responsive:
Unresponsive: heavy disc activity, no response of the mouse pointer. No possibility to change between sessions with alt + cntrl + Fn. No applications do open. That is, you can (after a while (about 5 minutes) and with a 30 seconds delay) execute commands and open applications. But caution is needed because two commands in this time will make it much worse. If you do not kill at least one application that consumes a lot of cpu time, then you are done. The system will go down (shutdown for oom condition). You know that it happened again because it switched off during your absence while on sector.
OOM does not switch system off. According to your dmesg output OOM just killed one of processes related to web browsing. And system apparently was up and running after that for quite some time. And you also were able to collect dmesg output.
At the time that happened the last time, the application was used was firefox. But it does not mean it has to be firefox. The CPU time was 24%. After killing it (because application do respond too slow to avoid the complete freeze) the system turned normal. That is, cursor has normal speed, more applications could be opened, you can shift between sessions. However what you can't do: leave it like that. If you sudo swapoff -a and wait (takes about half an hour) to discharge the amount that is still in swap to the ram, then it is over, you might work for hours, after also sudo swapon -a.
Was that dmesg output you provided after "swapoff"?
No new swap will accumulate.
Without any more details the obvious guess - some rogue process that over-allocated memory was killed during this procedure. Process list before and after would certainly be useful. As well as logs after swapoff finished.
But if you do not this procedure, that starts over after a short time... and you are left with the same problem. Or, if you leave it, the best you can hope is for slow growth of swap. I fairly never saw the swap written back.
I am not sure what "swap written back" means. If you mean "swap is freed" - this happens when process memory is freed which almost always means, process is ended (normal high level memory allocators do not actually return memory back to system). Or when page content changes in RAM. So once some pages were swapped out, they almost certainly remain there - unless application reads them back. So it is entirely up to application. Swap is memory that application does not use currently but used at some point in the past. You can monitor swap in/out rate using vmstat or install sar (I think part of sysstat package).
If you tell me how to quantify unresponsiveness quantitatively then please tell me the command and next time (and no problem, there will be) I give you the values.
Frequency: happens on a "regular irregular" basis. That is, it is repetitive, quite frequent (from several times per week to one time per week). When using suspend to disk and long uptimes then it is much more frequent, about after an uptime of 2 days, very frequent.
In this case I would certainly install sar (and changed stats collection interval to be more frequent than default 15 minutes) to see how situation evolves. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org