[opensuse-support] Unresponsive desktop
Hi, Last December I reported this problem on my laptop, and now my desktop also exhibits it. After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted. A week before it also froze, but that time I could not observe anything. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [02-03-19 08:34]:
Hi,
Last December I reported this problem on my laptop, and now my desktop also exhibits it.
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
A week before it also froze, but that time I could not observe anything.
I have noticed firefox on occasion to decide to use all the memory it could find and had to kill/restart firefox, but never to the point of requiring a reboot. but I have no swap and 36gb of memory. but you don't say which system version or DT or firefox Tumbleweed Plasma5/KDE5 MozillaFirefox-64.0-1.2 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2019-02-03 at 08:46 -0500, Patrick Shanahan wrote:
* Carlos E. R. <> [02-03-19 08:34]:
Hi,
Last December I reported this problem on my laptop, and now my desktop also exhibits it.
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
A week before it also froze, but that time I could not observe anything.
I have noticed firefox on occasion to decide to use all the memory it could find and had to kill/restart firefox, but never to the point of requiring a reboot. but I have no swap and 36gb of memory.
I had no chance to kill firefox, system froze while I tried to issue the command. The laptop has 4 gigs, the desktop has 8, so it takes longer to crash. I might have to start firefox with ulimit, but I don't know what limits to give it.
but you don't say which system version or DT or firefox
Yes, I do. See signature. Firefox is the default version that comes with it: MozillaFirefox-60.4.0-lp150.3.30.1.x86_64 Desktop is XFCE. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXFbzGBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVpUEAn0K6hsdddd+9VDOF4QFA nM1oyQ2TAKCZYek45GCZhWpBYyNJTExjTUrHTw== =Fwqx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Carlos E. R. wrote:
I had no chance to kill firefox, system froze while I tried to issue the command.
The laptop has 4 gigs, the desktop has 8, so it takes longer to crash.
I might have to start firefox with ulimit, but I don't know what limits to give it.
This sounds similar to my hangs when my image processing started using more RAM than physically available, and it pushed anything from the GUI into swap. So any UI interaction would need swap-in, but that one had been busy due to the processing. In my case it was 'dead' for almost an hour - and then came back as if nothing happened.... My solution had been to limit the process using cgroups to not use more than MEM-2GB physical RAM. In other words, as soon as it wants more than that amount, it starts using swap. That leaves enough memory for the GUI to remain responsive. For my machine here (16GB) the setup script looks like this: lux:~ # cat bin/mk14Ggroup #!/bin/sh mkdir /sys/fs/cgroup/memory/14G echo 15032385536 > /sys/fs/cgroup/memory/14G/memory.limit_in_bytes chown root.users /sys/fs/cgroup/memory/14G/cgroup.procs chmod 775 /sys/fs/cgroup/memory/14G/cgroup.procs Any user can then echo $PID > /sys/fs/cgroup/memory/14G/cgroup.procs and the process $PID will be limited that way. I've even considered doing this on the main level, i.e., echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes Then no process at all can use up all memory. I have not checked though if that works as intended. You might give it a try (of course with some smaller limit, something like 6.5-7GB for the 8GB machine) -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 03/02/2019 17.35, Peter Suetterlin wrote:
Carlos E. R. wrote:
I had no chance to kill firefox, system froze while I tried to issue the command.
The laptop has 4 gigs, the desktop has 8, so it takes longer to crash.
I might have to start firefox with ulimit, but I don't know what limits to give it.
This sounds similar to my hangs when my image processing started using more RAM than physically available, and it pushed anything from the GUI into swap. So any UI interaction would need swap-in, but that one had been busy due to the processing. In my case it was 'dead' for almost an hour - and then came back as if nothing happened....
My solution had been to limit the process using cgroups to not use more than MEM-2GB physical RAM. In other words, as soon as it wants more than that amount, it starts using swap. That leaves enough memory for the GUI to remain responsive.
Yes, but for that you have to know which process to limit. I don't have a clear culprit. I had been sleeping, the machine was idling. As I recall, I sat on my computer, had a glance at Thunderbird, there was an unsent usenet post, so clicked to send. Machine was responding normally, maybe a bit slow; I noticed on the "Multiload" applet that it was loaded on i/o, so I pressed the key combination to go one workspace to the left, where one terminal was running top, to have a look. Bamm! A terminal was white, failed to refresh. The log terminal displayed content of several hours earlier. The one with top did not respond to keys, as I wanted to kill firefox, which had 10.5 GB of virtual memory. Things finally froze completely.
For my machine here (16GB) the setup script looks like this:
lux:~ # cat bin/mk14Ggroup #!/bin/sh mkdir /sys/fs/cgroup/memory/14G echo 15032385536 > /sys/fs/cgroup/memory/14G/memory.limit_in_bytes chown root.users /sys/fs/cgroup/memory/14G/cgroup.procs chmod 775 /sys/fs/cgroup/memory/14G/cgroup.procs
Any user can then echo $PID > /sys/fs/cgroup/memory/14G/cgroup.procs and the process $PID will be limited that way.
I've even considered doing this on the main level, i.e., echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes
Then no process at all can use up all memory. I have not checked though if that works as intended. You might give it a try (of course with some smaller limit, something like 6.5-7GB for the 8GB machine)
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
Yes, but for that you have to know which process to limit. I don't have a clear culprit. I had been sleeping, the machine was idling.
In that case you *might* try the top-level limit, I think that should not allow *any* process to use all physical space. You'd still be f****d if two of those would start competeing heavily, but it should be better...
As I recall, I sat on my computer, had a glance at Thunderbird, there was an unsent usenet post, so clicked to send. Machine was responding normally, maybe a bit slow; I noticed on the "Multiload" applet that it was loaded on i/o, so I pressed the key combination to go one workspace to the left, where one terminal was running top, to have a look. Bamm! A terminal was white, failed to refresh. The log terminal displayed content of several hours earlier. The one with top did not respond to keys, as I wanted to kill firefox, which had 10.5 GB of virtual memory. Things finally froze completely.
Yes, exactly the same. Try a switch, content and applications on that other screen are swaped out already, and the culprit process is hitting the swap that hard that there's no chance the needed swap is read back :(
I've even considered doing this on the main level, i.e., echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes
Then no process at all can use up all memory. I have not checked though if that works as intended. You might give it a try (of course with some smaller limit, something like 6.5-7GB for the 8GB machine)
So in your case (6GB limit) # echo 6442450944 > /sys/fs/cgroup/memory/memory.limit_in_bytes As I said, it would not limit the amount of (total) memory the process uses - it just starts swapping when that limit is reached, before all physical mem is used up. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2019-02-04 at 14:03 +0100, Peter Suetterlin wrote:
Carlos E. R. wrote:
Yes, but for that you have to know which process to limit. I don't have a clear culprit. I had been sleeping, the machine was idling.
In that case you *might* try the top-level limit, I think that should not allow *any* process to use all physical space. You'd still be f****d if two of those would start competeing heavily, but it should be better...
Firefox is divided in five processes. One master and four childs. I don't see how to limit the total of them.
As I recall, I sat on my computer, had a glance at Thunderbird, there was an unsent usenet post, so clicked to send. Machine was responding normally, maybe a bit slow; I noticed on the "Multiload" applet that it was loaded on i/o, so I pressed the key combination to go one workspace to the left, where one terminal was running top, to have a look. Bamm! A terminal was white, failed to refresh. The log terminal displayed content of several hours earlier. The one with top did not respond to keys, as I wanted to kill firefox, which had 10.5 GB of virtual memory. Things finally froze completely.
Yes, exactly the same. Try a switch, content and applications on that other screen are swaped out already, and the culprit process is hitting the swap that hard that there's no chance the needed swap is read back :(
Sorry, I don't understand this paragarph. What switch? I didn't have a chance to find who was hitting swap heavily.
I've even considered doing this on the main level, i.e., echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes
Then no process at all can use up all memory. I have not checked though if that works as intended. You might give it a try (of course with some smaller limit, something like 6.5-7GB for the 8GB machine)
So in your case (6GB limit)
# echo 6442450944 > /sys/fs/cgroup/memory/memory.limit_in_bytes
As I said, it would not limit the amount of (total) memory the process uses - it just starts swapping when that limit is reached, before all physical mem is used up.
I don't think anything was using 6 GB. But it is possible that the 5 firefox processes in total were hitting it. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXFg+vRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVYH0AoJVB0d/S8SwMlpBnQOj8 5SP39Fb2AJ0bh+XYjgZ/qOxlk/0C7V3aqopq/g== =5x0A -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Carlos E. R. wrote:
Firefox is divided in five processes. One master and four childs. I don't see how to limit the total of them.
Good question. I don't really know how the cgroup stuff works :(
Yes, exactly the same. Try a switch, content and applications on that other screen are swaped out already, and the culprit process is hitting the swap that hard that there's no chance the needed swap is read back :(
Sorry, I don't understand this paragarph. What switch?
Argh. Sorry for my sloppy wording. Yes, *I experienced* exactly the same. I tried to switch *to another virtual screen*, *swapping blocks further gui interaction*
I didn't have a chance to find who was hitting swap heavily.
Doesn't even help if you know (I did). There's no way to do something. Either press the power button, or wait. (In my experience) the system is still running, just slow as if it were doing computations using an Abakus.... -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Peter Suetterlin <pit@astro.su.se> [02-03-19 11:37]:
Carlos E. R. wrote:
I had no chance to kill firefox, system froze while I tried to issue the command.
The laptop has 4 gigs, the desktop has 8, so it takes longer to crash.
I might have to start firefox with ulimit, but I don't know what limits to give it.
This sounds similar to my hangs when my image processing started using more RAM than physically available, and it pushed anything from the GUI into swap. So any UI interaction would need swap-in, but that one had been busy due to the processing. In my case it was 'dead' for almost an hour - and then came back as if nothing happened....
My solution had been to limit the process using cgroups to not use more than MEM-2GB physical RAM. In other words, as soon as it wants more than that amount, it starts using swap. That leaves enough memory for the GUI to remain responsive.
For my machine here (16GB) the setup script looks like this:
lux:~ # cat bin/mk14Ggroup #!/bin/sh mkdir /sys/fs/cgroup/memory/14G echo 15032385536 > /sys/fs/cgroup/memory/14G/memory.limit_in_bytes chown root.users /sys/fs/cgroup/memory/14G/cgroup.procs chmod 775 /sys/fs/cgroup/memory/14G/cgroup.procs
Any user can then echo $PID > /sys/fs/cgroup/memory/14G/cgroup.procs and the process $PID will be limited that way.
then to include firefox, replace "echo $PID" with echo $(pidof firefox) or a script using at or cron or systemd-timer to repeatedly check for the presence in cgroup.procs of firefox pid's and add/remove to reflect current situation.
I've even considered doing this on the main level, i.e., echo 15032385536 > /sys/fs/cgroup/memory/memory.limit_in_bytes
Then no process at all can use up all memory. I have not checked though if that works as intended. You might give it a try (of course with some smaller limit, something like 6.5-7GB for the 8GB machine) -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Sun, 3 Feb 2019 14:56:40 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday, 2019-02-03 at 08:46 -0500, Patrick Shanahan wrote:
* Carlos E. R. <> [02-03-19 08:34]:
Hi,
Last December I reported this problem on my laptop, and now my desktop also exhibits it.
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
A week before it also froze, but that time I could not observe anything.
I have noticed firefox on occasion to decide to use all the memory it could find and had to kill/restart firefox, but never to the point of requiring a reboot. but I have no swap and 36gb of memory.
Hmm, I haven't seen this but sometimes when I have a large number (for me, anyway) of tabs & windows open, the system slows down to the point where I think "I must close all the Firefox pages and restart it". Occasionally Firefox has crashed but I've never understood why so just let it report the crash and restart itself.
I had no chance to kill firefox, system froze while I tried to issue the command.
Whenever I try to debug problems like this I find it can be helpful to ssh into the machine with the problem as soon as it is started, su to root and keep the session open in the background. Frequently when the problem machine subsequently 'hangs' it has proven to just be extremely sluggish and it has been possible to kill or suspend the most likely culprit process to recover the machine. Sometimes I have waited for half an hour or more whilst the command executes. Sometimes it is also possible to run things like top or strace through the ssh session to gather more information.
but you don't say which system version or DT or firefox
Yes, I do. See signature.
You're right in the letter of the law but not the spirit, IMHO. Many people don't notice the signature, or may not even display it to avoid taking offence at some of the things people post there. And the suspicion always remains about whether details in the signature are accurate for the system with the problem, as opposed to the system from which the message is being posted. So I think it's better to be explicit in the body of the message.
Firefox is the default version that comes with it:
MozillaFirefox-60.4.0-lp150.3.30.1.x86_64
Desktop is XFCE.
FWIW, I'm using the same OS and FF but run LXDE. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 03/02/2019 21.44, Dave Howorth wrote:
On Sun, 3 Feb 2019 14:56:40 +0100 (CET) "Carlos E. R." <> wrote:
Hmm, I haven't seen this but sometimes when I have a large number (for me, anyway) of tabs & windows open, the system slows down to the point where I think "I must close all the Firefox pages and restart it". Occasionally Firefox has crashed but I've never understood why so just let it report the crash and restart itself.
I had no chance to kill firefox, system froze while I tried to issue the command.
Whenever I try to debug problems like this I find it can be helpful to ssh into the machine with the problem as soon as it is started,
I tried. It did not connect.
Firefox is the default version that comes with it:
MozillaFirefox-60.4.0-lp150.3.30.1.x86_64
Desktop is XFCE.
FWIW, I'm using the same OS and FF but run LXDE.
I have two machines that started having problems after upgraded to 15.0. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Mon, 4 Feb 2019 13:20:20 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 03/02/2019 21.44, Dave Howorth wrote:
On Sun, 3 Feb 2019 14:56:40 +0100 (CET) "Carlos E. R." <> wrote:
Hmm, I haven't seen this but sometimes when I have a large number (for me, anyway) of tabs & windows open, the system slows down to the point where I think "I must close all the Firefox pages and restart it". Occasionally Firefox has crashed but I've never understood why so just let it report the crash and restart itself.
I had no chance to kill firefox, system froze while I tried to issue the command.
Whenever I try to debug problems like this I find it can be helpful to ssh into the machine with the problem as soon as it is started,
I tried. It did not connect.
Then investigate that problem first! If you boot a machine and cannot immediately ssh into it then there's something seriously wrong. (Unless it hasn't finished booting or sshd isn't enabled, of course). The whole point is to establish the ssh connection long before any problems arise.
Firefox is the default version that comes with it:
MozillaFirefox-60.4.0-lp150.3.30.1.x86_64
Desktop is XFCE.
FWIW, I'm using the same OS and FF but run LXDE.
I have two machines that started having problems after upgraded to 15.0.
Other possible variables are any add-ons you use in FF and the video hardware and drivers. I'd suggest running without add-ons, or at least only a few basic ones, and using the most basic video driver that works. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 03. 02. 19, 14:33, Carlos E. R. wrote:
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
Sometimes, this gets logged as OOM. Have you checked logs from the boot right before the reboot? regards, -- js suse labs -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 05/02/2019 10.54, Jiri Slaby wrote:
On 03. 02. 19, 14:33, Carlos E. R. wrote:
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
Sometimes, this gets logged as OOM. Have you checked logs from the boot right before the reboot?
Yes, nothing. The word "OOM" is nowhere in the logs from 2019-01-28 to 2019-02-05. /var/log/messages during the event: <3.6> 2019-02-03 13:00:01 Telcontar dbus-daemon 1537 - - [system] Activating service name='org.opensuse.Snapper' requested by ':1.10447' (ui d=0 pid=29269 comm="/usr/lib/snapper/systemd-helper --timeline ") (using servicehelper) <3.6> 2019-02-03 13:00:01 Telcontar dbus-daemon 1537 - - [system] Successfully activated service 'org.opensuse.Snapper' <10.6> 2019-02-03 13:00:01 Telcontar cron 29258 - - pam_unix(crond:session): session opened for user cer by (uid=0) <10.6> 2019-02-03 13:00:01 Telcontar cron 29257 - - pam_unix(crond:session): session opened for user cer by (uid=0) <9.6> 2019-02-03 13:00:01 Telcontar CRON 29292 - - (cer) CMD (/home/cer/bin/dar_la_hora_en_cron hora) <10.6> 2019-02-03 13:00:01 Telcontar CRON 29257 - - pam_unix(crond:session): session closed for user cer <10.6> 2019-02-03 13:00:05 Telcontar CRON 29258 - - pam_unix(crond:session): session closed for user cer <3.6> 2019-02-03 13:06:46 Telcontar smartd 1473 - - Device: /dev/sdc [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 7 8 to 79 <3.6> 2019-02-03 13:06:46 Telcontar smartd 1473 - - Device: /dev/sdc [SAT], SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 7 8 to 79 <3.6> 2019-02-03 13:09:28 Telcontar systemd 1 - - Started Leafnode NNTP server (127.0.0.1:35362). <3.6> 2019-02-03 13:09:28 Telcontar systemd 1 - - Started Leafnode NNTP server (127.0.0.1:35360). <10.6> 2019-02-03 13:20:01 Telcontar cron 30074 - - pam_unix(crond:session): session opened for user cer by (uid=0) <10.6> 2019-02-03 13:20:01 Telcontar CRON 30074 - - pam_unix(crond:session): session closed for user cer <10.6> 2019-02-03 13:24:05 Telcontar unix2_chkpwd - - - gkr-pam: unlocked login keyring <3.6> 2019-02-03 13:24:11 Telcontar systemd 1 - - Started Leafnode NNTP server (127.0.0.1:35744). <3.6> 2019-02-03 13:24:11 Telcontar systemd 1 - - Started Leafnode NNTP server (127.0.0.1:35742). <10.3> 2019-02-03 13:28:54 Telcontar cron 30378 - - pam_systemd(crond:session): Failed to create session: Connection timed out 2019-02-03 13:34:47+01:00 - Booting the system now ================================================================================ Linux T "Started Leafnode NNTP server" is probably when I successful sent one nntp (news) post on Thunderbird on workspace 2, instants before it hanged. Going to the "/var/log/allmessages-20190204.xz" log, I can see some more details: <63>1 2019-02-03T13:24:16.583416+01:00 Telcontar fetchnews 30228 - - <211 0 451 450 comp.os.linux.announce <63>1 2019-02-03T13:24:16.583442+01:00 Telcontar fetchnews 30228 - - >GROUP comp.os.linux.embedded <63>1 2019-02-03T13:24:16.633080+01:00 Telcontar fetchnews 30228 - - <211 4 1842 1845 comp.os.linux.embedded <62>1 2019-02-03T13:24:16.633109+01:00 Telcontar fetchnews 30228 - - comp.os.linux.embedded: no new articles <63>1 2019-02-03T13:24:16.633372+01:00 Telcontar fetchnews 30228 - - >QUIT <62>1 2019-02-03T13:24:16.782370+01:00 Telcontar fetchnews 30228 - - wrote active file with 46702 lines <63>1 2019-02-03T13:24:16.782824+01:00 Telcontar fetchnews 30252 - - Process forked. <62>1 2019-02-03T13:24:16.823734+01:00 Telcontar fetchnews 30228 - - child has process ID 30252 <86>1 2019-02-03T13:24:16.832408+01:00 Telcontar CRON 30219 - - pam_unix(crond:session): session closed for user news <30>1 2019-02-03T13:24:16.837939+01:00 Telcontar systemd 1 - - Stopping User Manager for UID 9... <86>1 2019-02-03T13:24:16.856877+01:00 Telcontar systemd - - - pam_unix(systemd-user:session): session closed for user news <30>1 2019-02-03T13:24:16.857733+01:00 Telcontar systemd 1 - - Stopped User Manager for UID 9. <30>1 2019-02-03T13:24:16.858306+01:00 Telcontar systemd 1 - - Removed slice User Slice of news. <63>1 2019-02-03T13:24:17.825814+01:00 Telcontar fetchnews 30252 - - Process done. <63>1 2019-02-03T13:25:40.081855+01:00 Telcontar leafnode 30240 - - <POST <63>1 2019-02-03T13:25:40.081890+01:00 Telcontar leafnode 30240 - - rereading /var/spool/news/leaf.node/groupinfo <63>1 2019-02-03T13:25:40.443816+01:00 Telcontar leafnode 30240 - - >340 Go ahead. <63>1 2019-02-03T13:25:40.566794+01:00 Telcontar leafnode 30240 - - >240 Article posted, now be patient <22>1 2019-02-03T13:26:23.993497+01:00 Telcontar dovecot - - - imap(cer)<30193><dXLxcPyAnoF/AAAB>: Logged out in=3526 out=9193 deleted=0 exp unged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 <22>1 2019-02-03T13:26:25.188125+01:00 Telcontar dovecot - - - imap-login: Login: user=<cer>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mp id=30339, TLS, session=<rS8QfPyAPoJ/AAAB> <30>1 2019-02-03T13:28:29.454128+01:00 Telcontar systemd 1 - - Created slice User Slice of news. <30>1 2019-02-03T13:28:29.964244+01:00 Telcontar systemd 1 - - Starting User Manager for UID 9... <30>1 2019-02-03T13:28:30.608901+01:00 Telcontar systemd 1 - - Started Session 4871 of user news. <83>1 2019-02-03T13:28:54.199886+01:00 Telcontar cron 30378 - - pam_systemd(crond:session): Failed to create session: Connection timed out <86>1 2019-02-03T13:28:56.968197+01:00 Telcontar cron 30378 - - pam_unix(crond:session): session opened for user news by (uid=0) <63>1 2019-02-03T13:29:17.142305+01:00 Telcontar fetchnews 30386 - - config: debugmode is 1 <63>1 2019-02-03T13:29:17.279998+01:00 Telcontar fetchnews 30386 - - config: maxfetch is 5000 <63>1 2019-02-03T13:29:17.280033+01:00 Telcontar fetchnews 30386 - - config: maxage is 0 You can see how it is working, then things start to fail at 13:28, yet fetchnews is running correctly <63>1 2019-02-03T13:29:17.280033+01:00 Telcontar fetchnews 30386 - - config: maxage is 0 <63>1 2019-02-03T13:29:17.280053+01:00 Telcontar fetchnews 30386 - - config: postings have max. 500000 bytes <63>1 2019-02-03T13:29:17.280075+01:00 Telcontar fetchnews 30386 - - config: timeout_long is 100 days <63>1 2019-02-03T13:29:17.280097+01:00 Telcontar fetchnews 30386 - - config: timeout_fetchnews is 90 seconds ... trimming <63>1 2019-02-03T13:29:23.735856+01:00 Telcontar fetchnews 30386 - - check_date: News.Individual.NET: server time 1549196963, our time 15491 96963 ... trimming ... trimming <62>1 2019-02-03T13:29:39.454094+01:00 Telcontar fetchnews 30386 - - comp.os.linux.embedded: no new articles <63>1 2019-02-03T13:29:39.581622+01:00 Telcontar fetchnews 30386 - - >QUIT <62>1 2019-02-03T13:29:39.971244+01:00 Telcontar fetchnews 30386 - - wrote active file with 46702 lines <63>1 2019-02-03T13:29:40.107338+01:00 Telcontar fetchnews 30387 - - Process forked. <62>1 2019-02-03T13:29:40.107366+01:00 Telcontar fetchnews 30386 - - child has process ID 30387 <30>1 2019-02-03T13:34:48.596658+01:00 Telcontar systemd 1 - - systemd 234 running in system mode. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN default-hierarchy=hybrid) <30>1 2019-02-03T13:34:48.596706+01:00 Telcontar systemd 1 - - Detected architecture x86-64. <30>1 2019-02-03T13:34:48.596715+01:00 Telcontar systemd 1 - - Set hostname to <Telcontar>. <28>1 2019-02-03T13:34:48.596721+01:00 Telcontar systemd 1 - - nss-lookup.target: Dependency Before=nss-lookup.target dropped <30>1 2019-02-03T13:34:48.596727+01:00 Telcontar apparmor.systemd 632 - - Restarting AppArmor <30>1 2019-02-03T13:34:48.596737+01:00 Telcontar apparmor.systemd 632 - - Reloading AppArmor profiles And that's the reboot. Last entry 2019-02-03T13:29:40.107366+01:00. What I could see in the top display (I should have made a photo with camera) was similar to this, taken last December on the laptop, that also has that problem: PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 38 root 20 0 0 0 0 0 S 25.39 0.000 20:48.33 kswapd0 <=== -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 2/3/19 2:33 PM, Carlos E. R. wrote:
I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
I would observe that RAM starvation seems to be the related to a number of your problems. I also note your fondness for running a local IMAP server, _with_ virus scanning too, on multiple machines. I suggest that these problems are related. I would further suggest: * stop running local IMAP servers. Put them on a dedicated host. Consider putting virus scanning on a separate dedicated host, too. (Others have said this too. I know you don't want to. I know you have reasons. Re-evaluate them. Listen to the advice.) * Investigate compcache and other measures to swap compressed data for greater efficiency. * Buy more RAM. If an old machine won't take more RAM, replace it with a slightly less-old machine. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 05/02/2019 13.02, Liam Proven wrote:
On 2/3/19 2:33 PM, Carlos E. R. wrote:
I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
I would observe that RAM starvation seems to be the related to a number of your problems.
I also note your fondness for running a local IMAP server, _with_ virus scanning too, on multiple machines.
I suggest that these problems are related.
I would further suggest:
* stop running local IMAP servers. Put them on a dedicated host. Consider putting virus scanning on a separate dedicated host, too. (Others have said this too. I know you don't want to. I know you have reasons. Re-evaluate them. Listen to the advice.)
I might move clamav, but not dovecot. It is not memory hungry. And further, I need dovecot on all my laptops, the home server is not accessible to them all time. At worst, dovecot would be served from the desktop machine precisely. And, 42.3 did not exhibit this hanging problem, with the same load. Being slow is one thing, crashing is another.
* Investigate compcache and other measures to swap compressed data for greater efficiency.
* Buy more RAM. If an old machine won't take more RAM, replace it with a slightly less-old machine.
That needs funds. Are you doing a donation for a new PC? :-p -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
And, 42.3 did not exhibit this hanging problem, with the same load. Being slow is one thing, crashing is another.
It might not have been triggered. The problem itself is there if something is using more memory than RAM is installed. Been there, done that :P -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2019-02-05 at 15:20 +0100, Peter Suetterlin wrote:
Carlos E. R. wrote:
And, 42.3 did not exhibit this hanging problem, with the same load. Being slow is one thing, crashing is another.
It might not have been triggered. The problem itself is there if something is using more memory than RAM is installed. Been there, done that :P
Yes, but Linux is prepared for that. I have used in the past (with SuSE) machines with 20 times more used memory than available RAM, swapping like hell. Yes, very slow, but more responsive with a Pentium V than this. It is some sort of race condition, the kernel doesn't manage to assign memory to the processes that need ram or some process is demanding unreasonable amounts. Maybe Firefox or Thunderbird or some unknown demands so much ram that the GUI starves. I have removed btrfsmaintenance package, same as I did on the laptop. No, I don't think it is because it triggereded now and not then. I use the same tools and in the same manner. Two different computers exhibit the same problem after being updated to 15.0, I think that is significative. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXFni6hwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVeF4AnidUwGVUHmC+eMnHO/Pa TZ0J30e+AJ9QZsh6ZclMyE0igYfAIysBdv2Gng== =QuBo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Liam Proven wrote:
On 2/3/19 2:33 PM, Carlos E. R. wrote:
I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
I would observe that RAM starvation seems to be the related to a number of your problems.
Might be, but the core issue is that the system behaves bad when running short of memory. You can easily trigger the behavior by having an application requesting more memory than physically available (though less than RAM+swap), and make (heavy) use of it so stuff gets permanently swapped in and out. For me it happens during image processing. The laptop now has 32GB. I still manage to trigger this if I'm not careful.... JFTR, the system is *not* crashed or dead, just totally unresponsive. One can wait until the heavy swap io is over, and the system will be normal again, without *any* notice in the logs. The proper solution is not to mute the symptoms by running less applications or buying more RAM (although it clearly helps). Somehow a desktop setup should have some sort of protection that makes sure at least the core GUI stuff doesn't get swapped out. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2019-02-03 at 14:33 +0100, Carlos E. R. wrote:
Hi,
Last December I reported this problem on my laptop, and now my desktop also exhibits it.
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
A week before it also froze, but that time I could not observe anything.
Well, it happened tonight and I got data: the culprit appears to be alsa, of all things. I was writing an email. I send it, then I think of seeing a google search I had clicked minutes before, and then I notice the mouse does not respond (nor the keyboard LEDs). I look on another computer that has an ssh open to this one, running top, and top is also frozen. Nevertheless, I type "k" to try kill something. On another tab, I try to open an ssh shell, but does not respond. Back to top, the "k" has responded and asks for the PID. I give the one for Firefox (for no reason, except that it is big ram). Typing is slow, one char per second. A few seconds later I notice that Thunderbird updates and the mouse is again responsive. Recovery! On a terminal, I was running "top -d 60 -b > top_01.log &" for days. I stop it and look at the log - 185M. This is the relevant part: Here think it was acting normal: top - 03:36:13 up 3 days, 13:42, 3 users, load average: 0,20, 0,39, 0,53 Tasks: 438 total, 2 running, 435 sleeping, 0 stopped, 1 zombie %Cpu(s): 9,2 us, 1,7 sy, 0,6 ni, 87,3 id, 1,2 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 457912 free, 6722988 used, 980500 buff/cache KiB Swap: 25165820 total, 20518908 free, 4646912 used. 930768 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5089 cer 20 0 3911352 1,224g 73108 167316 S 14,28 15,72 286:13.57 Web Content 4233 cer 20 0 10,501g 916988 218760 296076 S 7,042 11,24 248:14.02 firefox ... top - 03:37:13 up 3 days, 13:43, 3 users, load average: 0,51, 0,46, 0,55 Tasks: 433 total, 2 running, 430 sleeping, 0 stopped, 1 zombie %Cpu(s): 9,9 us, 1,7 sy, 0,6 ni, 86,7 id, 1,2 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 790104 free, 6544820 used, 826476 buff/cache KiB Swap: 25165820 total, 20515068 free, 4650752 used. 1128644 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5089 cer 20 0 3911352 1,085g 72988 167412 S 12,60 13,94 286:21.14 Web Content 4237 cer 20 0 4469680 989,6m 64872 415528 R 10,17 12,42 270:39.08 thunderbird-bin 4233 cer 20 0 10,515g 839364 196276 296368 S 5,992 10,28 248:17.62 firefox 5118 cer 20 0 4120348 989144 82060 401296 S 5,443 12,12 206:04.71 Web Content 4680 cer 39 19 2066432 17936 0 22908 S 2,730 0,220 141:46.84 tracker-extract 5910 root 20 0 56480 10888 2164 4844 S 2,480 0,133 119:53.00 iotop 5136 cer 20 0 2909700 798180 37236 274392 S 2,330 9,780 123:13.72 Web Content 3868 root 20 0 642944 138192 100996 21996 S 1,531 1,693 28:58.50 X 5041 cer 20 0 3449000 1,048g 22120 404768 S 1,431 13,47 76:04.77 Web Content 5871 cer 20 0 40396 804 0 248 S 0,599 0,010 29:51.17 top 11922 root 20 0 41584 968 172 256 S 0,549 0,012 29:41.31 top 4169 cer 9 -11 2479296 5276 3608 2408 S 0,350 0,065 34:27.52 pulseaudio 4234 cer 20 0 301208 6220 4112 13900 S 0,250 0,076 12:34.62 gkrellm 4324 cer 20 0 523528 15388 8264 15244 S 0,216 0,189 10:18.53 panel-6-weather 52 root 20 0 0 0 0 0 S 0,200 0,000 3:20.59 kswapd0 4330 cer 20 0 523268 15364 8388 13388 S 0,200 0,188 10:21.99 panel-14-weathe 4702 cer 20 0 732548 38432 72 3692 S 0,200 0,471 10:45.17 tracker-store 4196 cer 20 0 473192 5224 1768 9440 S 0,150 0,064 5:13.63 gvfs-udisks2-vo 4242 cer 20 0 738936 31148 8280 21180 S 0,067 0,382 4:18.89 xfce4-terminal 4322 cer 20 0 251216 2840 1952 15268 S 0,067 0,035 2:59.17 panel-23-multil 4181 cer 20 0 425860 11584 6560 15104 S 0,050 0,142 1:11.06 xfce4-panel I say it was normal here because each capture happened at the 13 second. The next one is delayed and kswapd0 is going mad: top - 03:39:26 up 3 days, 13:45, 3 users, load average: 61,19, 21,98, 8,28 Tasks: 436 total, 2 running, 433 sleeping, 0 stopped, 1 zombie %Cpu(s): 7,1 us, 12,7 sy, 0,3 ni, 13,9 id, 65,7 wa, 0,0 hi, 0,4 si, 0,0 st KiB Mem : 8161400 total, 117196 free, 7740016 used, 304188 buff/cache KiB Swap: 25165820 total, 20514556 free, 4651264 used. 20184 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 52 root 20 0 0 0 0 0 D 83,74 0,000 4:17.49 kswapd0 4237 cer 20 0 4491088 1,263g 10332 417144 D 29,80 16,22 270:59.33 thunderbird-bin 5118 cer 20 0 4137756 1,518g 36252 402496 D 17,35 19,50 206:16.50 Web Content 4233 cer 20 0 10,467g 865432 157420 296732 D 9,154 10,60 248:23.84 firefox 5089 cer 20 0 3911352 1,246g 23044 175308 D 5,151 16,01 286:24.64 Web Content 4680 cer 39 19 2066432 17936 0 22908 S 2,414 0,220 141:48.48 tracker-extract 5136 cer 20 0 2909700 767112 7208 274476 D 1,840 9,399 123:14.97 Web Content 5910 root 20 0 56480 8828 0 4808 D 1,413 0,108 119:53.96 iotop 2318 mysql 20 0 1887764 8052 0 63360 S 1,030 0,099 1:24.20 mysqld 5041 cer 20 0 3449000 1,026g 0 405020 D 0,986 13,18 76:05.44 Web Content 3868 root 20 0 636132 124360 86816 21944 D 0,898 1,524 28:59.11 X 6744 cer 20 0 4057688 69632 16 120816 S 0,824 0,853 2:10.61 java 3828 vscan 20 0 882152 0 0 628960 S 0,515 0,000 1:06.06 clamd 5871 cer 20 0 40396 1636 832 248 R 0,515 0,020 29:51.52 top 11922 root 20 0 41584 800 0 252 D 0,515 0,010 29:41.66 top 2307 named 20 0 532424 95288 0 99532 S 0,486 1,168 2:16.24 named 4169 cer 9 -11 2479296 2156 452 2376 S 0,368 0,026 34:27.77 pulseaudio 4234 cer 20 0 301208 2108 0 13900 D 0,309 0,026 12:34.83 gkrellm 4250 cer 20 0 1074168 20364 16 16208 D 0,309 0,250 1:01.59 konversation 4149 cer 20 0 240120 276 0 136 S 0,294 0,003 0:12.73 gpg-agent 4330 cer 20 0 523268 7296 356 13424 D 0,280 0,089 10:22.18 panel-14-weathe 4324 cer 20 0 523528 7504 332 15196 D 0,265 0,092 10:18.71 panel-6-weather 2929 ntp 20 0 53120 188 0 568 D 0,206 0,002 0:10.89 ntpd ... top - 03:40:42 up 3 days, 13:46, 3 users, load average: 57,19, 29,27, 11,83 Tasks: 433 total, 2 running, 430 sleeping, 0 stopped, 1 zombie %Cpu(s): 0,1 us, 7,1 sy, 0,0 ni, 0,0 id, 92,3 wa, 0,0 hi, 0,5 si, 0,0 st KiB Mem : 8161400 total, 130404 free, 7719124 used, 311872 buff/cache KiB Swap: 25165820 total, 20509948 free, 4655872 used. 37236 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 52 root 20 0 0 0 0 0 S 12,26 0,000 4:34.80 kswapd0 4233 cer 20 0 10,436g 865072 157416 297044 D 0,489 10,60 248:24.53 firefox 4237 cer 20 0 4491088 1,265g 10332 418312 D 0,319 16,25 270:59.78 thunderbird-bin 2307 named 20 0 532424 95276 0 99544 S 0,262 1,167 2:16.61 named 5118 cer 20 0 4137756 1,517g 36252 403572 D 0,227 19,49 206:16.82 Web Content 6744 cer 20 0 4057688 69364 16 121084 S 0,212 0,850 2:10.91 java 2318 mysql 20 0 1887764 8052 0 63360 S 0,205 0,099 1:24.49 mysqld 4250 cer 20 0 1074168 20364 16 16208 D 0,149 0,250 1:01.80 konversation 3868 root 20 0 636132 124808 87176 21864 S 0,120 1,529 28:59.28 X 5089 cer 20 0 3911352 1,244g 23044 177360 D 0,120 15,99 286:24.81 Web Content 1 root 20 0 158452 3004 0 772 D 0,113 0,037 1:03.57 systemd 5136 cer 20 0 2909700 766300 7208 275288 D 0,113 9,389 123:15.13 Web Content 5871 cer 20 0 40396 804 0 248 R 0,113 0,010 29:51.68 top 4686 cer 39 19 936648 44816 4 12380 D 0,106 0,549 1:44.15 tracker-miner-f 5041 cer 20 0 3449000 1,026g 0 405288 D 0,106 13,18 76:05.59 Web Content 4234 cer 20 0 301208 2108 0 13900 D 0,085 0,026 12:34.95 gkrellm 4315 cer 20 0 710624 3976 44 15404 S 0,085 0,049 2:44.29 panel-19-pulsea 4322 cer 20 0 251216 1012 44 15188 D 0,085 0,012 2:59.43 panel-23-multil 4772 cer 20 0 463636 6232 0 15788 S 0,078 0,076 0:54.68 contarcorreo 11922 root 20 0 41584 828 0 224 S 0,078 0,010 29:41.77 top 4169 cer 9 -11 2479296 2136 432 2376 S 0,071 0,026 34:27.87 pulseaudio 663 root 20 0 82288 5740 5396 456 D 0,064 0,070 0:44.02 systemd-journal and back to normal after killing firefox: top - 03:41:43 up 3 days, 13:47, 4 users, load average: 24,51, 25,39, 11,62 Tasks: 427 total, 1 running, 425 sleeping, 0 stopped, 1 zombie %Cpu(s): 2,9 us, 2,2 sy, 0,8 ni, 80,3 id, 13,6 wa, 0,0 hi, 0,2 si, 0,0 st KiB Mem : 8161400 total, 5307944 free, 2265236 used, 588220 buff/cache KiB Swap: 25165820 total, 22424060 free, 2741760 used. 5610332 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 4237 cer 20 0 4490112 1,297g 41488 418224 S 5,156 16,67 271:02.92 thunderbird-bin 4680 cer 39 19 2066432 20592 2652 22904 S 2,709 0,252 141:50.13 tracker-extract 52 root 20 0 0 0 0 0 S 2,512 0,000 4:36.33 kswapd0 5910 root 20 0 56480 13328 4472 4792 S 1,839 0,163 119:55.16 iotop 3868 root 20 0 507876 78808 41164 21852 S 0,821 0,966 28:59.78 X 4169 cer 9 -11 1430364 6500 4696 2276 S 0,624 0,080 34:28.25 pulseaudio 5871 cer 20 0 40396 900 96 248 S 0,575 0,011 29:52.03 top 11922 root 20 0 41584 984 156 224 S 0,542 0,012 29:42.10 top 4196 cer 20 0 473192 7124 3676 9464 S 0,509 0,087 5:13.94 gvfs-udisks2-vo 4702 cer 20 0 732548 44488 6116 3660 S 0,296 0,545 10:45.47 tracker-store 4234 cer 20 0 301208 10440 8332 13900 S 0,230 0,128 12:35.09 gkrellm 4242 cer 20 0 738936 32448 9312 20916 S 0,230 0,398 4:19.09 xfce4-terminal 2307 named 20 0 532424 95276 0 99544 S 0,197 1,167 2:16.73 named 23937 cer 20 0 21484 11452 3368 0 S 0,197 0,140 0:00.12 bash 4330 cer 20 0 523268 13144 6208 13428 S 0,181 0,161 10:22.38 panel-14-weathe 4207 cer 20 0 775472 49928 16244 14340 S 0,164 0,612 0:36.44 xfdesktop 4324 cer 20 0 523528 13480 6316 15204 S 0,164 0,165 10:18.90 panel-6-weather 1 root 20 0 240380 7116 3984 688 S 0,115 0,087 1:03.64 systemd 5907 cer 20 0 217984 7020 3144 8828 S 0,115 0,086 0:46.97 dirmngr 663 root 20 0 82592 8028 7416 428 S 0,099 0,098 0:44.08 systemd-journal 4315 cer 20 0 710624 8924 4956 15368 S 0,099 0,109 2:44.35 panel-19-pulsea 4250 cer 20 0 1074168 27412 7064 16208 S 0,082 0,336 1:01.85 konversation 6744 cer 20 0 4057688 69368 16 121080 S 0,082 0,850 2:10.96 java So the issue happened betwen 03:37:13 and 03:39:26 hours. As the 3:38:13 entry is missing, at that moment things were already wrong. Let's go see syslog - as this time I was sitting there and killed something, it is properly registered. This is postfix sending an email, everything normal: <22>1 2019-02-09T03:37:27.328452+01:00 Telcontar postfix 23861 - - A584E3209C9: to=<...@opensuse.org>, relay=mail.gmx.es ... status=sent (250 Requested mail action okay, completed: id=...) <22>1 2019-02-09T03:37:27.330347+01:00 Telcontar postfix 23861 - - > mail.gmx.es[212.227.17.184]:25: QUIT <22>1 2019-02-09T03:37:27.330518+01:00 Telcontar postfix 23861 - - name_mask: resource <22>1 2019-02-09T03:37:27.331005+01:00 Telcontar postfix 23861 - - name_mask: software <22>1 2019-02-09T03:37:27.385482+01:00 Telcontar postfix 23861 - - disposing SASL state information <22>1 2019-02-09T03:37:27.385789+01:00 Telcontar postfix 3974 - - A584E3209C9: removed <39>1 2019-02-09T03:37:34.187629+01:00 Telcontar gcr-prompter 23840 - - 10 second inactivity timeout, quitting <39>1 2019-02-09T03:37:34.187844+01:00 Telcontar gcr-prompter 23840 - - Gcr: unregistering prompter <39>1 2019-02-09T03:37:34.190225+01:00 Telcontar gcr-prompter 23840 - - Gcr: disposing prompter <39>1 2019-02-09T03:37:34.190251+01:00 Telcontar gcr-prompter 23840 - - Gcr: finalizing prompter Here definitely things are going bad (no edited lines here), but we know it started earlier, before 3:38:13 and after 3:37:27 - the gcr-prompter entry above may be suspicious, but the alsa entries below definitely indicate a problem: <30>1 2019-02-09T03:39:04.102993+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 4553784 bytes (25815 ms). <30>1 2019-02-09T03:40:01.963938+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. <30>1 2019-02-09T03:40:29.388806+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: snd_pcm_dump(): <30>1 2019-02-09T03:40:38.256922+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Soft volume PCM <30>1 2019-02-09T03:40:47.447909+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Control: PCM Playback Volume <30>1 2019-02-09T03:40:49.856184+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: min_dB: -51 <30>1 2019-02-09T03:40:49.931352+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: max_dB: 0 <30>1 2019-02-09T03:40:49.931597+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: resolution: 256 <30>1 2019-02-09T03:40:49.931769+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Its setup is: <30>1 2019-02-09T03:40:49.931930+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stream : PLAYBACK <30>1 2019-02-09T03:40:49.932090+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: access : MMAP_INTERLEAVED <30>1 2019-02-09T03:40:49.932249+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: format : S16_LE <30>1 2019-02-09T03:40:49.932408+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: subformat : STD <30>1 2019-02-09T03:40:49.932566+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: channels : 2 <30>1 2019-02-09T03:40:49.932734+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: rate : 44100 <30>1 2019-02-09T03:40:49.932893+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: exact rate : 44100 (44100/1) <30>1 2019-02-09T03:40:49.933052+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: msbits : 16 <30>1 2019-02-09T03:40:49.933222+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: buffer_size : 88192 <30>1 2019-02-09T03:40:49.933396+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_size : 44096 <30>1 2019-02-09T03:40:49.933559+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_time : 999909 <30>1 2019-02-09T03:40:49.933717+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_mode : ENABLE <30>1 2019-02-09T03:40:49.933876+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_type : MONOTONIC <30>1 2019-02-09T03:40:49.934035+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_step : 1 <30>1 2019-02-09T03:40:49.934194+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: avail_min : 84401 <30>1 2019-02-09T03:40:49.934352+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_event : 0 <30>1 2019-02-09T03:40:49.934511+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: start_threshold : -1 <30>1 2019-02-09T03:40:49.934676+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stop_threshold : 6205960286516543488 <30>1 2019-02-09T03:40:49.934841+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_threshold: 0 <30>1 2019-02-09T03:40:49.934999+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_size : 0 <30>1 2019-02-09T03:40:49.935157+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: boundary : 6205960286516543488 <30>1 2019-02-09T03:40:49.935316+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Slave: Hardware PCM card 0 'HDA Creative' device 0 subdevice 0 <30>1 2019-02-09T03:40:49.935560+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Its setup is: <30>1 2019-02-09T03:40:49.935724+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stream : PLAYBACK <30>1 2019-02-09T03:40:49.935886+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: access : MMAP_INTERLEAVED <30>1 2019-02-09T03:40:49.936044+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: format : S16_LE <30>1 2019-02-09T03:40:49.936202+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: subformat : STD <30>1 2019-02-09T03:40:49.936361+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: channels : 2 <30>1 2019-02-09T03:40:49.936524+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: rate : 44100 <30>1 2019-02-09T03:40:50.047919+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: exact rate : 44100 (44100/1) <30>1 2019-02-09T03:40:50.048217+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: msbits : 16 <30>1 2019-02-09T03:40:50.048390+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: buffer_size : 88192 <30>1 2019-02-09T03:40:50.048549+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_size : 44096 <30>1 2019-02-09T03:40:50.048708+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_time : 999909 <30>1 2019-02-09T03:40:50.048866+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_mode : ENABLE <30>1 2019-02-09T03:40:50.049029+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_type : MONOTONIC <30>1 2019-02-09T03:40:50.049189+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_step : 1 <30>1 2019-02-09T03:40:50.049347+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: avail_min : 84401 <30>1 2019-02-09T03:40:50.049505+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_event : 0 <30>1 2019-02-09T03:40:50.049662+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: start_threshold : -1 <30>1 2019-02-09T03:40:50.049919+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stop_threshold : 6205960286516543488 <30>1 2019-02-09T03:40:50.050079+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_threshold: 0 <30>1 2019-02-09T03:40:50.050237+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_size : 0 <30>1 2019-02-09T03:40:50.050400+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: boundary : 6205960286516543488 <30>1 2019-02-09T03:40:50.050571+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: appl_ptr : 12514060050 <30>1 2019-02-09T03:40:50.050729+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: hw_ptr : 12515110304 <30>1 2019-02-09T03:40:50.050892+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: snd_pcm_delay() returned a value that is exceptionally large: -26371280 bytes (-149497 ms). <30>1 2019-02-09T03:40:50.051052+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. <30>1 2019-02-09T03:40:50.051261+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: snd_pcm_dump(): <30>1 2019-02-09T03:40:50.051431+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Soft volume PCM <30>1 2019-02-09T03:40:50.051589+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Control: PCM Playback Volume <30>1 2019-02-09T03:40:50.051747+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: min_dB: -51 <30>1 2019-02-09T03:40:50.051909+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: max_dB: 0 <30>1 2019-02-09T03:40:50.052067+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: resolution: 256 <30>1 2019-02-09T03:40:50.052230+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Its setup is: <30>1 2019-02-09T03:40:50.052394+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stream : PLAYBACK <30>1 2019-02-09T03:40:50.052557+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: access : MMAP_INTERLEAVED <30>1 2019-02-09T03:40:50.052716+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: format : S16_LE <30>1 2019-02-09T03:40:50.052875+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: subformat : STD <30>1 2019-02-09T03:40:50.053033+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: channels : 2 <30>1 2019-02-09T03:40:50.053191+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: rate : 44100 <30>1 2019-02-09T03:40:50.053349+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: exact rate : 44100 (44100/1) <30>1 2019-02-09T03:40:50.053512+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: msbits : 16 <30>1 2019-02-09T03:40:50.053670+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: buffer_size : 88192 <30>1 2019-02-09T03:40:50.053828+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_size : 44096 <30>1 2019-02-09T03:40:50.053987+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_time : 999909 <30>1 2019-02-09T03:40:50.054146+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_mode : ENABLE <30>1 2019-02-09T03:40:50.054305+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_type : MONOTONIC <30>1 2019-02-09T03:40:50.054476+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_step : 1 <30>1 2019-02-09T03:40:50.054635+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: avail_min : 84401 <30>1 2019-02-09T03:40:50.054801+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_event : 0 <30>1 2019-02-09T03:40:50.054959+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: start_threshold : -1 <30>1 2019-02-09T03:40:50.055117+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stop_threshold : 6205960286516543488 <30>1 2019-02-09T03:40:50.055275+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_threshold: 0 <30>1 2019-02-09T03:40:50.055456+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_size : 0 <30>1 2019-02-09T03:40:50.055615+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: boundary : 6205960286516543488 <30>1 2019-02-09T03:40:50.055773+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Slave: Hardware PCM card 0 'HDA Creative' device 0 subdevice 0 <30>1 2019-02-09T03:40:50.081352+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: Its setup is: <30>1 2019-02-09T03:40:50.081608+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stream : PLAYBACK <30>1 2019-02-09T03:40:50.081768+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: access : MMAP_INTERLEAVED <30>1 2019-02-09T03:40:50.081927+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: format : S16_LE <30>1 2019-02-09T03:40:50.082085+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: subformat : STD <30>1 2019-02-09T03:40:50.082243+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: channels : 2 <30>1 2019-02-09T03:40:50.082400+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: rate : 44100 <30>1 2019-02-09T03:40:50.082557+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: exact rate : 44100 (44100/1) <30>1 2019-02-09T03:40:50.082714+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: msbits : 16 <30>1 2019-02-09T03:40:50.082871+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: buffer_size : 88192 <30>1 2019-02-09T03:40:50.083034+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_size : 44096 <30>1 2019-02-09T03:40:50.083192+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_time : 999909 <30>1 2019-02-09T03:40:50.083349+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_mode : ENABLE <30>1 2019-02-09T03:40:50.083537+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: tstamp_type : MONOTONIC <30>1 2019-02-09T03:40:50.083703+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_step : 1 <30>1 2019-02-09T03:40:50.083862+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: avail_min : 84401 <30>1 2019-02-09T03:40:50.084019+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: period_event : 0 <30>1 2019-02-09T03:40:50.084177+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: start_threshold : -1 <30>1 2019-02-09T03:40:50.084337+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: stop_threshold : 6205960286516543488 <30>1 2019-02-09T03:40:50.084501+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_threshold: 0 <30>1 2019-02-09T03:40:50.084665+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: silence_size : 0 <30>1 2019-02-09T03:40:50.084824+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: boundary : 6205960286516543488 <30>1 2019-02-09T03:40:50.084981+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: appl_ptr : 12514102116 <30>1 2019-02-09T03:40:50.085140+01:00 Telcontar pulseaudio 4169 - - E: [alsa-sink-CA0110-IBG Analog] alsa-util.c: hw_ptr : 12520694936 <4>1 2019-02-09T03:40:50.580980+01:00 Telcontar kernel - - - [308811.279237] show_signal_msg: 45 callbacks suppressed <6>1 2019-02-09T03:40:50.580996+01:00 Telcontar kernel - - - [308811.279240] Chrome_~dThread[5139]: segfault at 0 ip 00007fe7cca17cd3 sp 00007fe7c987bb10 error 6 in libxul.so[7fe7cc4fd000+5874000] <6>1 2019-02-09T03:40:50.596756+01:00 Telcontar kernel - - - [308811.303156] Socket Thread[5100]: segfault at 0 ip 0000560342364c51 sp 00007f9566efe670 error 6 in firefox[56034235f000+31000] <6>1 2019-02-09T03:40:50.618242+01:00 Telcontar kernel - - - [308811.324121] Cameras IPC[9191]: segfault at 0 ip 000055c3285a8c51 sp 00007f9ade5fd8b0 error 6 in firefox[55c3285a3000+31000] <6>1 2019-02-09T03:40:50.683429+01:00 Telcontar kernel - - - [308811.390212] Chrome_~dThread[5044]: segfault at 0 ip 00007fef1d717cd3 sp 00007fef1a57bb10 error 6 in libxul.so[7fef1d1fd000+5874000] <30>1 2019-02-09T03:40:51.102534+01:00 Telcontar systemd 1 - - Created slice User Slice of news. <30>1 2019-02-09T03:40:51.103841+01:00 Telcontar systemd 1 - - Starting User Manager for UID 9... <30>1 2019-02-09T03:40:51.104264+01:00 Telcontar systemd 1 - - Created slice system-systemd\x2dcoredump.slice. <30>1 2019-02-09T03:40:51.147417+01:00 Telcontar systemd 1 - - Started Process Core Dump (PID 23890/UID 0). <30>1 2019-02-09T03:40:51.149551+01:00 Telcontar systemd 1 - - Started Process Core Dump (PID 23888/UID 0). <86>1 2019-02-09T03:40:51.156209+01:00 Telcontar systemd - - - pam_unix(systemd-user:session): session opened for user news by (uid=0) <30>1 2019-02-09T03:40:51.156952+01:00 Telcontar systemd 1 - - Started Process Core Dump (PID 23887/UID 0). <30>1 2019-02-09T03:40:51.163051+01:00 Telcontar systemd 1 - - Started Process Core Dump (PID 23889/UID 0). <30>1 2019-02-09T03:40:51.173282+01:00 Telcontar systemd 1 - - Started Session 1722 of user news. <30>1 2019-02-09T03:40:51.180118+01:00 Telcontar systemd 1 - - Started Session 1721 of user cer. <86>1 2019-02-09T03:40:51.186204+01:00 Telcontar cron 23880 - - pam_unix(crond:session): session opened for user cer by (uid=0) <30>1 2019-02-09T03:40:51.275496+01:00 Telcontar systemd-coredump 23896 - - Resource limits disable core dumping for process 5136 (Web Content). <10>1 2019-02-09T03:40:51.288537+01:00 Telcontar systemd-coredump 23896 - - Process 5136 (Web Content) of user 1000 dumped core. <30>1 2019-02-09T03:40:51.294905+01:00 Telcontar systemd-coredump 23894 - - Resource limits disable core dumping for process 5041 (Web Content). <10>1 2019-02-09T03:40:51.295785+01:00 Telcontar systemd-coredump 23894 - - Process 5041 (Web Content) of user 1000 dumped core. <30>1 2019-02-09T03:40:51.306329+01:00 Telcontar systemd-coredump 23898 - - Resource limits disable core dumping for process 5118 (Web Content). <10>1 2019-02-09T03:40:51.306830+01:00 Telcontar systemd-coredump 23898 - - Process 5118 (Web Content) of user 1000 dumped core. <30>1 2019-02-09T03:40:51.308720+01:00 Telcontar systemd-coredump 23895 - - Resource limits disable core dumping for process 5089 (Web Content). <10>1 2019-02-09T03:40:51.309167+01:00 Telcontar systemd-coredump 23895 - - Process 5089 (Web Content) of user 1000 dumped core. <30>1 2019-02-09T03:40:51.379583+01:00 Telcontar systemd 1 - - Started User Manager for UID 9. <86>1 2019-02-09T03:40:51.380313+01:00 Telcontar cron 23881 - - pam_unix(crond:session): session opened for user news by (uid=0) <63>1 2019-02-09T03:40:51.517680+01:00 Telcontar fetchnews 23921 - - config: debugmode is 1 <63>1 2019-02-09T03:40:51.517970+01:00 Telcontar fetchnews 23921 - - config: maxfetch is 5000 <63>1 2019-02-09T03:40:51.517993+01:00 Telcontar fetchnews 23921 - - config: maxage is 0 <63>1 2019-02-09T03:40:51.518051+01:00 Telcontar fetchnews 23921 - - config: postings have max. 500000 bytes <63>1 2019-02-09T03:40:51.518074+01:00 Telcontar fetchnews 23921 - - config: timeout_long is 100 days <63>1 2019-02-09T03:40:51.518095+01:00 Telcontar fetchnews 23921 - - config: timeout_fetchnews is 90 seconds <63>1 2019-02-09T03:40:51.518115+01:00 Telcontar fetchnews 23921 - - config: newsadmin is postmaster@telcontar.valinor <63>1 2019-02-09T03:40:51.518136+01:00 Telcontar fetchnews 23921 - - config: allow_8bit_headers is 1 <86>1 2019-02-09T03:40:52.037118+01:00 Telcontar CRON 23880 - - pam_unix(crond:session): session closed for user cer <63>1 2019-02-09T03:40:54.518456+01:00 Telcontar fetchnews 23921 - - leafnode 1.11.11: verbosity level is 2, debugmode is 1 <63>1 2019-02-09T03:40:54.518488+01:00 Telcontar fetchnews 23921 - - try_lock(timeout=5), fqdn="Telcontar.valinor" <63>1 2019-02-09T03:40:54.707342+01:00 Telcontar fetchnews 23921 - - Last LIST done 1666132 seconds ago: NEWGROUPS <63>1 2019-02-09T03:40:54.831086+01:00 Telcontar fetchnews 23921 - - <200 The server welcomes 208.red-83-32-232.dynamicip.rima-tde.net (83.32.232.208). Authorization required for reading and posting. <62>1 2019-02-09T03:40:54.831118+01:00 Telcontar fetchnews 23921 - - News.Individual.NET: connected to 130.133.4.11:119, reply: 200 <63>1 2019-02-09T03:40:54.831480+01:00 Telcontar fetchnews 23921 - - >AUTHINFO USER robinson <63>1 2019-02-09T03:40:54.892724+01:00 Telcontar fetchnews 23921 - - <381 PASS required <63>1 2019-02-09T03:40:54.892755+01:00 Telcontar fetchnews 23921 - - >AUTHINFO PASS <password not shown> things are back to normal here, as the nntp daemon is starting a fetch loop normally. Telcontar:~ # coredumpctl TIME PID UID GID SIG COREFILE EXE Sat 2019-02-09 03:40:51 CET 5136 1000 100 11 none /usr/lib64/firefox/firefox Sat 2019-02-09 03:40:51 CET 5041 1000 100 11 none /usr/lib64/firefox/firefox Sat 2019-02-09 03:40:51 CET 5118 1000 100 11 none /usr/lib64/firefox/firefox Sat 2019-02-09 03:40:51 CET 5089 1000 100 11 none /usr/lib64/firefox/firefox Telcontar:~ # No coredump files, sorry (I don't remember if I disabled them or it is a system limit not my doing). dmesg -e log has almost nothing registered: [Feb 9 02:51] usb 4-2: USB disconnect, device number 3 [Feb 9 03:41] show_signal_msg: 45 callbacks suppressed [ +0,000003] Chrome_~dThread[5139]: segfault at 0 ip 00007fe7cca17cd3 sp 00007fe7c987bb10 error 6 in libxul.so[7fe7cc4fd000+5874000] [ +0,023916] Socket Thread[5100]: segfault at 0 ip 0000560342364c51 sp 00007f9566efe670 error 6 in firefox[56034235f000+31000] [ +0,020965] Cameras IPC[9191]: segfault at 0 ip 000055c3285a8c51 sp 00007f9ade5fd8b0 error 6 in firefox[55c3285a3000+31000] [ +0,066091] Chrome_~dThread[5044]: segfault at 0 ip 00007fef1d717cd3 sp 00007fef1a57bb10 error 6 in libxul.so[7fef1d1fd000+5874000] cer@Telcontar:~> There are some strange lines above: <4>1 2019-02-09T03:40:50.580980+01:00 Telcontar kernel - - - [308811.279237] show_signal_msg: 45 callbacks suppressed <6>1 2019-02-09T03:40:50.580996+01:00 Telcontar kernel - - - [308811.279240] Chrome_~dThread[5139]: segfault at 0 ip 00007fe7cca17cd3 sp 0000 <6>1 2019-02-09T03:40:50.596756+01:00 Telcontar kernel - - - [308811.303156] Socket Thread[5100]: segfault at 0 ip 0000560342364c51 sp 00007f <6>1 2019-02-09T03:40:50.618242+01:00 Telcontar kernel - - - [308811.324121] Cameras IPC[9191]: segfault at 0 ip 000055c3285a8c51 sp 00007f9a <6>1 2019-02-09T03:40:50.683429+01:00 Telcontar kernel - - - [308811.390212] Chrome_~dThread[5044]: segfault at 0 ip 00007fef1d717cd3 sp 0000 Chrome? I don't remember having Chrome running. I may have started it once to check something, but it should have been exited. Cameras IPC? No idea what is that. My "top" log doesn't show any "chrome" process except this one much earlier, and none afterwards: top - 10:37:54 up 1 day, 20:43, 3 users, load average: 2,05, 1,44, 0,91 ... 10299 cer 20 0 293572 21076 384 0 S 0,000 0,258 0:00.35 chrome-gnome-sh So, what do you think? The system is running, I can do tests. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXF5YYhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVm80AoI8J4x3Q6MvDSE1/4Wmx VwCqBKgbAJoCTCYcCViGl35P8WhE5KOaDavXMA== =5td3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Carlos E. R. wrote:
So, what do you think?
Two things came to my mind looking at those: - I first suspected thunderbird, as it was at higher load than firefox, but then realized that of course a process waiting for swap IO won't use too much CPU... - I don't think alsa is the cause. The messages you get are rather a consequence, as audio is extremely timing critical, and is also affected by the general slowness. I did see similar in my cases of hitting the swap deathmill: Sound started stuttering, until it would eventually stop completely. But it came back once swapping stopped. Maybe not too enlightening, but all I can come up with. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 11/02/2019 12.39, Peter Suetterlin wrote:
Carlos E. R. wrote:
So, what do you think?
Two things came to my mind looking at those:
- I first suspected thunderbird, as it was at higher load than firefox, but then realized that of course a process waiting for swap IO won't use too much CPU...
Right. And that top runs once per minute - possibly the thing tells the average of the minute, or perhaps just that instant.
- I don't think alsa is the cause. The messages you get are rather a consequence, as audio is extremely timing critical, and is also affected by the general slowness.
It is certainly probable.
I did see similar in my cases of hitting the swap deathmill: Sound started stuttering, until it would eventually stop completely. But it came back once swapping stopped.
Maybe not too enlightening, but all I can come up with.
Thanks. I think I will report in bugzilla what I know, and try to update to the tumbleweed kernel. Unless someone knows some command to try when it crashes to obtain more info, and I write it in a postit... Maybe log iotop output as well. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))
Hello, Am Sonntag, 3. Februar 2019, 14:33:24 CET schrieb Carlos E. R.:
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
It's probably not the answer you are looking for, but I'll propose it nevertheless: Disable your swap. Obviously that means that you'll have less "memory" available, but IMHO that has some advantages: - you avoid the "swap to death" situation (freezing the system while swapping) - programs eating up RAM get killed earlier, and you get an OOM killer log entry that tells you which process ate too much RAM Personally, I don't use swap since years [1], and I'm completely happy with it. I remember a few rare cases where a program ate up memory and was killed, but the alternative would have been to let it swap, fill the swap, and then being killed - after freezing the system (aka "swap to death") for a while ;-) Regards, Christian Boltz [1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running -- Aber was macht [KDE] bei mir? Es zeigt xterms und Hintergrundbilder an. Aus meiner Sicht ist letzteres die Funktion, die es am besten beherrscht. Sehr schöne Bilder sind das. [Lars Müller in opensuse-de] -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/02/2019 16.35, Christian Boltz wrote:
Hello,
Am Sonntag, 3. Februar 2019, 14:33:24 CET schrieb Carlos E. R.:
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
It's probably not the answer you are looking for, but I'll propose it nevertheless:
Disable your swap.
Not viable. This minute I have 5 GB of swap in use. Without swap, the system would simple not work, several programs I use would be killed.
[1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running
But I have only 8. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
[1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running
But I have only 8. Like I have, and swap is only touched by suspend. LAMP stack running, most of
Op maandag 11 februari 2019 09:30:10 CET schreef Carlos E. R.: the time both Chrome and FF open, editing video, pictures etc. I'm wondering how many tabs FF has open, what these tabs are. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2019-02-11 at 11:12 +0100, Knurpht-openSUSE wrote: El 2019-02-11 a las 11:12 +0100, Knurpht-openSUSE escribió:
Date: Mon, 11 Feb 2019 11:12:08 +0100 From: Knurpht-openSUSE <knurpht@opensuse.org> To: opensuse-support@opensuse.org Subject: Re: [opensuse-support] Unresponsive desktop
[1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running
But I have only 8. Like I have, and swap is only touched by suspend. LAMP stack running, most of
Op maandag 11 februari 2019 09:30:10 CET schreef Carlos E. R.: the time both Chrome and FF open, editing video, pictures etc. I'm wondering how many tabs FF has open, what these tabs are.
After killing firefox (I restarted Thunderbird half an hour ago) I still have 2.3 GB in swap. After killing Th it is the same figure (using alpine to post this). Telcontar:~ # free -h total used free shared buff/cache available Mem: 7.8G 950M 5.6G 28M 1.3G 6.6G Swap: 23G 2.2G 21G Telcontar:~ # But, I get 5.6G free, and 1.3 in buff/cache temporarily. With no swap, free would be 2.2 less. Having swap increases free memory, not the other way round. It makes the system actually faster. That's a common misconception, that having swap makes the system slower. No. What makes it slower is needing to use swap because there is not enough ram. None of you have looked at the logs in the other post that indicate that the culprit of my problems can be alsa. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXGFMphwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVJfkAniLexS9MJDkdnDwRbx+h OCOzUysHAJ93QWa/3alPJtG6UZeLSd/m/9SUIg== =MBkH -----END PGP SIGNATURE-----
* Carlos E. R. <robin.listas@telefonica.net> [02-11-19 05:23]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2019-02-11 at 11:12 +0100, Knurpht-openSUSE wrote:
El 2019-02-11 a las 11:12 +0100, Knurpht-openSUSE escribió:
Date: Mon, 11 Feb 2019 11:12:08 +0100 From: Knurpht-openSUSE <knurpht@opensuse.org> To: opensuse-support@opensuse.org Subject: Re: [opensuse-support] Unresponsive desktop
[1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running
But I have only 8. Like I have, and swap is only touched by suspend. LAMP stack running, most of
Op maandag 11 februari 2019 09:30:10 CET schreef Carlos E. R.: the time both Chrome and FF open, editing video, pictures etc. I'm wondering how many tabs FF has open, what these tabs are.
After killing firefox (I restarted Thunderbird half an hour ago) I still have 2.3 GB in swap. After killing Th it is the same figure (using alpine to post this).
Telcontar:~ # free -h total used free shared buff/cache available Mem: 7.8G 950M 5.6G 28M 1.3G 6.6G Swap: 23G 2.2G 21G Telcontar:~ #
But, I get 5.6G free, and 1.3 in buff/cache temporarily. With no swap, free would be 2.2 less.
Having swap increases free memory, not the other way round. It makes the system actually faster. That's a common misconception, that having swap makes the system slower. No. What makes it slower is needing to use swap because there is not enough ram.
just turn swap off and see. you think you know but you refuse to try. It is simple: swapoff that only turns swap off until you reboot or turn it back on. it changes no config files. I have been running my main workstation for years w/o swap. and it is simple to turn on additional temporary swap to a temporary file on your hard drive, also w/o changing any config files. and very easy to recover the temp swap file. issue "swapoff" and let your system run for a while to test. if you don't like the way it performs, issue "swapon" to use it again. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Op maandag 11 februari 2019 11:21:26 CET schreef Carlos E. R.:
On Monday, 2019-02-11 at 11:12 +0100, Knurpht-openSUSE wrote:
El 2019-02-11 a las 11:12 +0100, Knurpht-openSUSE escribió:
Date: Mon, 11 Feb 2019 11:12:08 +0100 From: Knurpht-openSUSE <knurpht@opensuse.org> To: opensuse-support@opensuse.org Subject: Re: [opensuse-support] Unresponsive desktop
Op maandag 11 februari 2019 09:30:10 CET schreef Carlos E. R.:
[1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running
But I have only 8.
Like I have, and swap is only touched by suspend. LAMP stack running, most of the time both Chrome and FF open, editing video, pictures etc. I'm wondering how many tabs FF has open, what these tabs are.
After killing firefox (I restarted Thunderbird half an hour ago) I still have 2.3 GB in swap. After killing Th it is the same figure (using alpine to post this).
Telcontar:~ # free -h total used free shared buff/cache available Mem: 7.8G 950M 5.6G 28M 1.3G 6.6G Swap: 23G 2.2G 21G Telcontar:~ #
But, I get 5.6G free, and 1.3 in buff/cache temporarily. With no swap, free would be 2.2 less.
Having swap increases free memory, not the other way round. It makes the system actually faster. That's a common misconception, that having swap makes the system slower. No. What makes it slower is needing to use swap because there is not enough ram.
None of you have looked at the logs in the other post that indicate that the culprit of my problems can be alsa.
-- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) Why do you insist on your own interpretations? Not a single poster here has confirmed seeing what you see. And alsa is definitely not the culprit IMNSHO.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 11/02/2019 14.17, Knurpht-openSUSE wrote:
Op maandag 11 februari 2019 11:21:26 CET schreef Carlos E. R.:
On Monday, 2019-02-11 at 11:12 +0100, Knurpht-openSUSE wrote:
El 2019-02-11 a las 11:12 +0100, Knurpht-openSUSE escribió:
Date: Mon, 11 Feb 2019 11:12:08 +0100 From: Knurpht-openSUSE <knurpht@opensuse.org> To: opensuse-support@opensuse.org Subject: Re: [opensuse-support] Unresponsive desktop
Op maandag 11 februari 2019 09:30:10 CET schreef Carlos E. R.:
[1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running
But I have only 8.
Like I have, and swap is only touched by suspend. LAMP stack running, most of the time both Chrome and FF open, editing video, pictures etc. I'm wondering how many tabs FF has open, what these tabs are.
After killing firefox (I restarted Thunderbird half an hour ago) I still have 2.3 GB in swap. After killing Th it is the same figure (using alpine to post this).
Telcontar:~ # free -h total used free shared buff/cache available Mem: 7.8G 950M 5.6G 28M 1.3G 6.6G Swap: 23G 2.2G 21G Telcontar:~ #
But, I get 5.6G free, and 1.3 in buff/cache temporarily. With no swap, free would be 2.2 less.
Having swap increases free memory, not the other way round. It makes the system actually faster. That's a common misconception, that having swap makes the system slower. No. What makes it slower is needing to use swap because there is not enough ram.
None of you have looked at the logs in the other post that indicate that the culprit of my problems can be alsa.
Why do you insist on your own interpretations? Not a single poster here has confirmed seeing what you see. And alsa is definitely not the culprit IMNSHO.
When the replies say ridiculous things I ignore them, sorry. Don't worry, I will try swapoff when I get back home and I have 5 gigs used in swap. It will be interesting. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))
* Carlos E. R. <robin.listas@telefonica.net> [02-11-19 14:49]:
On 11/02/2019 14.17, Knurpht-openSUSE wrote:
Op maandag 11 februari 2019 11:21:26 CET schreef Carlos E. R.:
On Monday, 2019-02-11 at 11:12 +0100, Knurpht-openSUSE wrote:
El 2019-02-11 a las 11:12 +0100, Knurpht-openSUSE escribió:
Date: Mon, 11 Feb 2019 11:12:08 +0100 From: Knurpht-openSUSE <knurpht@opensuse.org> To: opensuse-support@opensuse.org Subject: Re: [opensuse-support] Unresponsive desktop
Op maandag 11 februari 2019 09:30:10 CET schreef Carlos E. R.:
[1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running
But I have only 8.
Like I have, and swap is only touched by suspend. LAMP stack running, most of the time both Chrome and FF open, editing video, pictures etc. I'm wondering how many tabs FF has open, what these tabs are.
After killing firefox (I restarted Thunderbird half an hour ago) I still have 2.3 GB in swap. After killing Th it is the same figure (using alpine to post this).
Telcontar:~ # free -h total used free shared buff/cache available Mem: 7.8G 950M 5.6G 28M 1.3G 6.6G Swap: 23G 2.2G 21G Telcontar:~ #
But, I get 5.6G free, and 1.3 in buff/cache temporarily. With no swap, free would be 2.2 less.
Having swap increases free memory, not the other way round. It makes the system actually faster. That's a common misconception, that having swap makes the system slower. No. What makes it slower is needing to use swap because there is not enough ram.
None of you have looked at the logs in the other post that indicate that the culprit of my problems can be alsa.
Why do you insist on your own interpretations? Not a single poster here has confirmed seeing what you see. And alsa is definitely not the culprit IMNSHO.
When the replies say ridiculous things I ignore them, sorry.
you may consider valid comments as rediculous, but that only hinders your search for a solution.
Don't worry, I will try swapoff when I get back home and I have 5 gigs used in swap. It will be interesting.
-- Cheers / Saludos,
Carlos E. R.
(from openSUSE 15.0 (Legolas))
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 2/11/19 9:10 PM, Patrick Shanahan wrote:
you may consider valid comments as rediculous, but that only hinders your search for a solution.
I have to agree here. Sorry, Carlos. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 12/02/2019 13.02, Liam Proven wrote:
On 2/11/19 9:10 PM, Patrick Shanahan wrote:
you may consider valid comments as rediculous, but that only hinders your search for a solution.
I have to agree here. Sorry, Carlos.
I said I would try, and I just did. See, it doesn't work: Telcontar:~/Documents/lists/swapoff_test # date ; free -h Wed Feb 13 11:31:13 CET 2019 total used free shared buff/cache available Mem: 7.8G 5.8G 1.1G 135M 893M 1.6G Swap: 23G 5.2G 18G Telcontar:~/Documents/lists/swapoff_test # Telcontar:~/Documents/lists/swapoff_test # time swapoff -a swapoff: /dev/sde1: swapoff failed: Cannot allocate memory real 0m0.010s user 0m0.001s sys 0m0.003s Telcontar:~/Documents/lists/swapoff_test # Even worse than what I predicted. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
Telcontar:~/Documents/lists/swapoff_test # time swapoff -a swapoff: /dev/sde1: swapoff failed: Cannot allocate memory
real 0m0.010s user 0m0.001s sys 0m0.003s
Interesting, so it seems that OOM killer doesn't get triggered in such a case. Would that be expected, or a bug? -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Wed, 13 Feb 2019 12:19:40 +0100 Peter Suetterlin <pit@astro.su.se> wrote:
Carlos E. R. wrote:
Telcontar:~/Documents/lists/swapoff_test # time swapoff -a swapoff: /dev/sde1: swapoff failed: Cannot allocate memory
real 0m0.010s user 0m0.001s sys 0m0.003s
Interesting, so it seems that OOM killer doesn't get triggered in such a case. Would that be expected, or a bug?
I'd hope it would be expected. The swapoff fails, you get told and can shut down whichever processes you choose to free up enough memory. Or you can change your mind about shutting down swap. Versus, the OOM killer is invoked, randomly kills off a selection of your processes, and the swapoff succeeds. I know which I would prefer. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2019-02-13 at 11:55 -0000, Dave Howorth wrote:
Carlos E. R. wrote:
Telcontar:~/Documents/lists/swapoff_test # time swapoff -a swapoff: /dev/sde1: swapoff failed: Cannot allocate memory
real 0m0.010s user 0m0.001s sys 0m0.003s
Interesting, so it seems that OOM killer doesn't get triggered in such a case. Would that be expected, or a bug?
I'd hope it would be expected. The swapoff fails, you get told and can shut down whichever processes you choose to free up enough memory. Or you can change your mind about shutting down swap. Versus, the OOM killer is invoked, randomly kills off a selection of your processes, and the swapoff succeeds. I know which I would prefer.
I then killed Firefox and Thunderbird, restarted them (the machine has to run my usual workload), then repeated the swapoff experiment. Telcontar:~/Documents/lists/swapoff_test # time swapoff -a real 3m30.374s user 0m0.001s sys 3m3.646s Telcontar:~/Documents/lists/swapoff_test # I was writing my notes on the terminal, when the system *collapsed* and would not respond. I managed to issue "swapon -a" on an ssh session already opened on another machine, which took perhaps half an hour to process. Then, with swap back on, the system responded, after also doing some OOM (on mysqld). Thunderbird was not running: cer@Telcontar:~> grep -i "oom" /var/log/messages <0.4> 2019-02-13 13:16:35 Telcontar kernel - - - [688971.796341] mysqld invoked oom-killer: gfp_mask=0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0 <0.4> 2019-02-13 13:16:35 Telcontar kernel - - - [688971.796366] oom_kill_process+0x213/0x3d0 <0.6> 2019-02-13 13:16:35 Telcontar kernel - - - [688971.796474] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name <0.6> 2019-02-13 13:16:35 Telcontar kernel - - - [688971.860717] oom_reaper: reaped process 12455 (thunderbird-bin), now anon-rss:0kB, file-rss:0kB, shmem-rss:15884kB cer@Telcontar:~> Interestingly, both mysqld and Thunderbird have been killed differently (one by oom-killer, another by oom_reaper) Why mysqld I have no idea, but it could have been worse. See the "free -h" output at different stages: Telcontar:~/Documents/lists/swapoff_test # cat free_status.2.log Wed Feb 13 12:32:56 CET 2019 total used free shared buff/cache available Mem: 7.8G 5.0G 870M 503M 2.0G 2.1G Swap: 23G 2.2G 21G Wed Feb 13 12:46:01 CET 2019 total used free shared buff/cache available Mem: 7.8G 6.9G 151M 566M 797M 137M Swap: 0B 0B 0B Wed Feb 13 13:35:38 CET 2019 total used free shared buff/cache available Mem: 7.8G 5.6G 1.2G 547M 1.0G 1.4G Swap: 23G 269M 23G As you can see, when swap was turned off I only had 137M available RAM (151M free and 797M in cache). Barely sufficient to run the system, which collapsed soon and would not respond to the keyboard - not even the LED lights. *top sequence*: Status before running swapoff: top - 12:32:28 up 7 days, 22:38, 4 users, load average: 1,03, 0,69, 0,61 Tasks: 448 total, 1 running, 446 sleeping, 0 stopped, 1 zombie %Cpu(s): 6,4 us, 1,8 sy, 0,6 ni, 88,4 id, 2,9 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 895036 free, 5209780 used, 2056584 buff/cache KiB Swap: 25165820 total, 22824188 free, 2341632 used. 2160380 avail Mem Notice now that "free swap" goes to zero the next minute - probably when swapoff starts working (took 3:30 minutes): top - 12:33:28 up 7 days, 22:39, 4 users, load average: 1,23, 0,81, 0,66 Tasks: 447 total, 2 running, 444 sleeping, 0 stopped, 1 zombie %Cpu(s): 5,6 us, 9,8 sy, 0,6 ni, 81,2 id, 2,6 wa, 0,0 hi, 0,2 si, 0,0 st KiB Mem : 8161400 total, 881484 free, 5215912 used, 2064004 buff/cache KiB Swap: 2035128 total, 0 free, 2035128 used. 2146120 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 15178 root 20 0 22636 1316 1148 0 R 33,44 0,016 0:20.09 swapoff 12957 cer 20 0 9926004 1,042g 409480 0 S 9,804 13,39 5:09.48 firefox 13141 cer 20 0 2424292 700828 194512 0 S 4,544 8,587 1:59.71 Web Content 4680 cer 39 19 2067524 20520 0 22300 S 2,663 0,251 311:38.78 tracker-extract 5910 root 20 0 60420 17824 2112 1900 S 2,280 0,218 266:24.87 iotop 13048 cer 20 0 2593004 685348 201584 0 S 2,247 8,397 1:15.42 Web Content 13090 cer 20 0 2579108 598056 209880 0 S 1,997 7,328 0:52.23 Web Content 12455 cer 20 0 3464248 1,023g 140108 0 S 1,481 13,14 1:48.88 thunderbird-bin 13121 cer 20 0 2684540 742012 196632 0 S 1,182 9,092 0:48.16 Web Content swapoff is working - see that firefox and thunderbird-bin are both running. top - 12:36:28 up 7 days, 22:42, 4 users, load average: 1,95, 1,19, 0,83 Tasks: 450 total, 2 running, 447 sleeping, 0 stopped, 1 zombie %Cpu(s): 5,8 us, 23,5 sy, 0,6 ni, 63,4 id, 6,0 wa, 0,0 hi, 0,7 si, 0,0 st KiB Mem : 8161400 total, 123128 free, 6996448 used, 1041824 buff/cache KiB Swap: 78948 total, 0 free, 78948 used. 315948 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 15178 root 20 0 22636 1292 1124 0 R 87,63 0,016 2:58.03 swapoff 12957 cer 20 0 9926004 1,004g 368860 0 S 9,704 12,90 5:26.81 firefox 13141 cer 20 0 2426340 629064 166704 0 S 3,778 7,708 2:06.93 Web Content 4680 cer 39 19 2067524 42132 0 688 S 2,730 0,516 311:43.68 tracker-extract 5910 root 20 0 60420 19536 1996 72 S 2,513 0,239 266:29.23 iotop 13048 cer 20 0 2593004 658724 173924 0 S 2,397 8,071 1:19.72 Web Content 13121 cer 20 0 2686588 714216 169496 0 S 1,365 8,751 0:50.52 Web Content 13090 cer 20 0 2579108 574268 182952 0 S 1,282 7,036 0:54.64 Web Content 12455 cer 20 0 3464248 0,981g 84588 0 S 1,148 12,61 1:51.19 thunderbird-bin 3868 root 20 0 652028 199244 134556 28 S 0,782 2,441 72:53.03 X 4020 root 20 0 447228 8336 2620 68 S 0,682 0,102 7:32.27 udisksd 24809 root 20 0 41604 1052 0 8 S 0,649 0,013 29:00.71 top 5871 cer 20 0 40396 1024 0 40 S 0,632 0,013 67:09.08 top 52 root 20 0 0 0 0 0 S 0,583 0,000 34:02.25 kswapd0 the next minute, swapoff had finished: top - 12:37:28 up 7 days, 22:43, 4 users, load average: 1,00, 1,06, 0,81 Tasks: 446 total, 1 running, 444 sleeping, 0 stopped, 1 zombie %Cpu(s): 6,2 us, 4,2 sy, 0,6 ni, 85,9 id, 3,0 wa, 0,0 hi, 0,1 si, 0,0 st KiB Mem : 8161400 total, 227648 free, 7045396 used, 888356 buff/cache KiB Swap: 0 total, 0 free, 0 used. 278852 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 12957 cer 20 0 9926004 986,3m 323700 0 S 10,60 12,37 5:33.18 firefox 13141 cer 20 0 2424292 639536 131112 0 S 4,760 7,836 2:09.79 Web Content 13048 cer 20 0 2595052 678568 128068 0 S 3,113 8,314 1:21.59 Web Content 4680 cer 39 19 2067524 42744 0 76 S 2,780 0,524 311:45.35 tracker-extract 5910 root 20 0 60420 19512 1948 48 S 2,413 0,239 266:30.68 iotop 13090 cer 20 0 2579108 598900 146328 0 S 2,413 7,338 0:56.09 Web Content 13121 cer 20 0 2687612 737580 125348 0 S 1,897 9,037 0:51.66 Web Content 12455 cer 20 0 3464248 987,5m 59504 0 S 1,265 12,39 1:51.95 thunderbird-bin 3868 root 20 0 652028 198516 133824 24 S 0,649 2,432 72:53.42 X 5871 cer 20 0 40396 1024 0 40 S 0,616 0,013 67:09.45 top 24809 root 20 0 41604 1052 0 8 S 0,599 0,013 29:01.07 top 52 root 20 0 0 0 0 0 S 0,516 0,000 34:02.56 kswapd0 4234 cer 20 0 301208 19528 3520 0 S 0,250 0,239 27:34.45 gkrellm 4702 cer 20 0 732704 42912 0 52 S 0,233 0,526 23:40.80 tracker-store 4324 cer 20 0 524424 28988 5712 20 S 0,200 0,355 22:56.35 panel-6-weather 4330 cer 20 0 524364 27136 5776 24 S 0,200 0,332 23:03.13 panel-14-weathe 41 root 39 19 0 0 0 0 S 0,117 0,000 3:36.08 khugepaged 4242 cer 20 0 748680 61428 8712 80 S 0,100 0,753 8:45.65 xfce4-terminal 5907 cer 20 0 217984 13180 0 4 S 0,100 0,161 1:40.45 dirmngr 4322 cer 20 0 251216 18624 2468 0 S 0,067 0,228 6:31.89 panel-23-multil 4315 cer 20 0 710624 20768 1480 80 S 0,050 0,254 6:05.39 panel-19-pulsea 6744 cer 20 0 4057688 266724 48 932 S 0,050 3,268 4:51.09 java 24011 cer 20 0 40260 988 0 4 R 0,050 0,012 2:26.05 top 266 root 0 -20 0 0 0 0 S 0,033 0,000 0:50.70 kworker/2:1H top - 12:38:28 up 7 days, 22:44, 4 users, load average: 0,61, 0,94, 0,78 Tasks: 447 total, 1 running, 445 sleeping, 0 stopped, 1 zombie %Cpu(s): 5,3 us, 1,4 sy, 0,6 ni, 90,5 id, 2,2 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 329408 free, 6922968 used, 909024 buff/cache KiB Swap: 0 total, 0 free, 0 used. 401424 avail Mem ... top - 12:46:29 up 7 days, 22:52, 4 users, load average: 0,66, 0,65, 0,67 Tasks: 447 total, 1 running, 445 sleeping, 0 stopped, 1 zombie %Cpu(s): 5,8 us, 1,7 sy, 0,6 ni, 87,4 id, 4,5 wa, 0,0 hi, 0,1 si, 0,0 st KiB Mem : 8161400 total, 156276 free, 7192052 used, 813072 buff/cache KiB Swap: 0 total, 0 free, 0 used. 138704 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 12957 cer 20 0 9926004 990208 293952 0 S 9,407 12,13 6:23.92 firefox 13141 cer 20 0 2424292 554988 98292 0 S 4,096 6,800 2:30.53 Web Content 4680 cer 39 19 2067524 43068 264 16 S 2,714 0,528 311:59.87 tracker-extract 5910 root 20 0 60420 18296 684 0 S 2,481 0,224 266:43.44 iotop 13048 cer 20 0 2596076 715052 95864 0 S 2,231 8,761 1:33.88 Web Content 12455 cer 20 0 3472492 1,010g 37284 0 S 1,915 12,98 2:03.53 thunderbird-bin 13090 cer 20 0 2504132 562236 112660 0 S 1,265 6,889 1:03.27 Web Content 13121 cer 20 0 2688636 778320 98888 0 S 1,116 9,537 0:57.87 Web Content 3868 root 20 0 652028 196496 131804 24 S 0,932 2,408 72:56.89 X 52 root 20 0 0 0 0 0 S 0,716 0,000 34:05.19 kswapd0 4020 root 20 0 447228 6200 448 32 S 0,699 0,076 7:32.70 udisksd 5871 cer 20 0 40396 1024 0 40 S 0,616 0,013 67:12.75 top 24809 root 20 0 41604 1052 0 8 S 0,566 0,013 29:04.38 top 4242 cer 20 0 748680 61108 8376 64 S 0,416 0,749 8:46.30 xfce4-terminal 4702 cer 20 0 732704 42888 0 16 S 0,283 0,525 23:42.13 tracker-store 4234 cer 20 0 301208 19200 3136 0 S 0,266 0,235 27:35.84 gkrellm 4330 cer 20 0 524364 25604 4192 0 S 0,200 0,314 23:04.26 panel-14-weathe 4324 cer 20 0 524424 27068 3712 0 S 0,183 0,332 22:57.47 panel-6-weather 4762 cer 20 0 494612 32860 7268 72 S 0,167 0,403 0:15.99 lxterminal 41 root 39 19 0 0 0 0 S 0,067 0,000 3:36.35 khugepaged 15332 root 0 -20 0 0 0 0 S 0,067 0,000 0:00.04 kworker/u9:3 4250 cer 20 0 1074936 40172 3088 96 S 0,050 0,492 2:21.68 konversation 4315 cer 20 0 710624 19680 328 16 S 0,050 0,241 6:05.66 panel-19-pulsea 4322 cer 20 0 251216 17940 1784 0 S 0,050 0,220 6:32.20 panel-23-multil 6744 cer 20 0 4057688 266912 48 744 S 0,050 3,270 4:51.31 java Here top stopped collecting data for about half an hour (I have it dumping data every minute), the time while the system collapsed. As you can see kswapd0 is running full load trying to free memory dumping things to swap again - thunderbird doesn't appear, it was killed at 13:16:35 (by syslog entry, see top of email). Notice that only about 4 MB are available: top - 13:16:35 up 7 days, 23:22, 4 users, load average: 100,36, 97,43, 79,20 Tasks: 437 total, 5 running, 429 sleeping, 0 stopped, 3 zombie %Cpu(s): 0,2 us, 28,8 sy, 0,0 ni, 3,5 id, 66,9 wa, 0,0 hi, 0,6 si, 0,0 st KiB Mem : 8161400 total, 108228 free, 7405628 used, 647544 buff/cache KiB Swap: 0 total, 0 free, 0 used. 4528 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 52 root 20 0 0 0 0 0 R 100,0 0,000 43:25.98 kswapd0 2318 mysql 20 0 1887764 71392 0 20 S 144,8 0,875 5:10.93 mysqld 12957 cer 20 0 9926004 971900 271204 0 D 65,62 11,91 7:11.64 firefox 6744 cer 20 0 4057688 267328 48 328 S 41,47 3,276 5:21.47 java 2307 named 20 0 540744 203332 0 0 S 41,46 2,491 4:23.45 named 13141 cer 20 0 2424292 579728 75816 0 D 24,38 7,103 2:48.26 Web Content 29797 nscd 20 0 1025804 924 60 32 S 23,67 0,011 0:40.85 nscd 4315 cer 20 0 710624 19548 164 0 R 22,88 0,240 6:22.30 panel-19-pulsea 13121 cer 20 0 2690684 813840 76696 0 D 20,97 9,972 1:13.12 Web Content 4149 cer 20 0 240120 420 0 0 D 20,74 0,005 0:44.32 gpg-agent 13048 cer 20 0 2600172 752436 76500 0 D 20,35 9,219 1:48.68 Web Content 13090 cer 20 0 2504132 594280 92888 0 D 20,32 7,282 1:18.05 Web Content 4250 cer 20 0 1074936 37100 16 96 D 20,15 0,455 2:36.33 konversation 15753 cer 20 0 179320 572 0 0 D 20,01 0,007 0:14.55 nvidia-settings 1538 avahi 20 0 43808 440 0 0 D 19,22 0,005 0:22.54 avahi-daemon 2929 ntp 20 0 53120 756 0 0 D 15,51 0,009 0:38.71 ntpd 24809 root 20 0 41604 1068 8 0 R 15,06 0,013 29:15.33 top 4324 cer 20 0 524424 23752 396 0 D 14,99 0,291 23:08.37 panel-6-weather 4772 cer 20 0 468916 27192 0 60 D 14,95 0,333 2:08.14 contarcorreo 4234 cer 20 0 301208 16064 0 0 D 14,89 0,197 27:46.67 gkrellm 5871 cer 20 0 40396 1064 0 0 R 14,32 0,013 67:23.16 top 4330 cer 20 0 524364 21808 396 0 D 14,19 0,267 23:14.58 panel-14-weathe 3868 root 20 0 652028 194640 129924 0 S 14,03 2,385 73:07.09 X 2954 root 20 0 225140 8808 16 0 D 13,92 0,108 0:28.11 httpd-prefork 24011 cer 20 0 40260 2000 1004 0 R 13,92 0,025 2:36.37 top next iteration of top, I have swap again, but zero used - the good news is that now there are 433MB available memory, the system can breathe again: top - 13:17:36 up 7 days, 23:23, 4 users, load average: 37,39, 79,87, 74,30 Tasks: 433 total, 1 running, 431 sleeping, 0 stopped, 1 zombie %Cpu(s): 8,4 us, 2,0 sy, 0,7 ni, 83,0 id, 5,8 wa, 0,0 hi, 0,1 si, 0,0 st KiB Mem : 8161400 total, 172136 free, 6916048 used, 1073216 buff/cache KiB Swap: 25165820 total, 25165820 free, 0 used. 433128 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 52 root 20 0 0 0 0 0 S 37,29 0,000 54:35.07 kswapd0 12957 cer 20 0 9965688 1,216g 318196 0 S 0,606 15,63 7:22.52 firefox 1 root 20 0 240380 7920 4044 0 S 0,537 0,097 2:22.43 systemd 13141 cer 20 0 2457064 692188 129672 0 S 0,239 8,481 2:52.55 Web Content 1151 root 20 0 7132 1456 1152 0 S 0,167 0,018 0:15.29 mdadm 663 root 20 0 88996 9040 8000 0 S 0,141 0,111 1:47.81 systemd-journal 13048 cer 20 0 2687212 855316 106936 0 S 0,094 10,48 1:50.37 Web Content 4680 cer 39 19 2067524 44384 1580 16 S 0,090 0,544 312:03.11 tracker-extract 5910 root 20 0 60420 21772 4152 0 S 0,076 0,267 266:53.02 iotop 13090 cer 20 0 2506180 713180 132272 0 S 0,062 8,738 1:19.16 Web Content 13121 cer 20 0 2744956 920400 109940 0 S 0,060 11,28 1:14.19 Web Content 3868 root 20 0 636368 184712 119996 0 S 0,033 2,263 73:07.69 X 15778 root 20 0 0 0 0 0 S 0,031 0,000 0:00.56 kworker/0:2 5871 cer 20 0 40396 2616 1552 0 S 0,021 0,032 67:23.53 top 4196 cer 20 0 484456 24180 0 20 S 0,016 0,296 11:25.28 gvfs-udisks2-vo 4020 root 20 0 447228 8992 3240 32 S 0,014 0,110 7:40.01 udisksd 15819 root 20 0 0 0 0 0 S 0,012 0,000 0:00.21 kworker/0:0 839 root 20 0 67628 2572 0 0 S 0,010 0,032 0:01.32 systemd-udevd 4234 cer 20 0 301208 23828 7764 0 S 0,009 0,292 27:46.84 gkrellm 4702 cer 20 0 732704 47244 4320 16 S 0,009 0,579 23:42.45 tracker-store 4250 cer 20 0 1074936 56080 18996 96 S 0,007 0,687 2:36.46 konversation 4324 cer 20 0 524424 31668 8312 0 S 0,007 0,388 23:08.50 panel-6-weather 4330 cer 20 0 524364 28796 7384 0 S 0,007 0,353 23:14.71 panel-14-weathe 22 root 20 0 0 0 0 0 S 0,007 0,000 0:16.43 ksoftirqd/2 8 root 20 0 0 0 0 0 S 0,006 0,000 2:11.07 rcu_sched Three minutes later swap starts to store things, very slowly: top - 13:20:37 up 7 days, 23:26, 4 users, load average: 2,21, 43,88, 61,26 Tasks: 432 total, 2 running, 429 sleeping, 0 stopped, 1 zombie %Cpu(s): 5,3 us, 1,2 sy, 0,8 ni, 90,7 id, 2,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 563748 free, 6518736 used, 1078916 buff/cache KiB Swap: 25165820 total, 25165564 free, 256 used. 830360 avail Mem top - 13:21:37 up 7 days, 23:27, 4 users, load average: 0,94, 35,94, 57,44 Tasks: 432 total, 1 running, 430 sleeping, 0 stopped, 1 zombie %Cpu(s): 5,1 us, 1,2 sy, 0,6 ni, 91,2 id, 2,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 547248 free, 6533800 used, 1080352 buff/cache KiB Swap: 25165820 total, 25165564 free, 256 used. 814192 avail Mem top - 13:22:37 up 7 days, 23:28, 4 users, load average: 0,79, 29,55, 53,90 Tasks: 429 total, 2 running, 426 sleeping, 0 stopped, 1 zombie %Cpu(s): 5,5 us, 1,5 sy, 0,7 ni, 92,0 id, 0,3 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 343844 free, 6739428 used, 1078128 buff/cache KiB Swap: 25165820 total, 25165308 free, 512 used. 609804 avail Mem top - 13:23:37 up 7 days, 23:29, 4 users, load average: 0,36, 24,19, 50,53 Tasks: 430 total, 1 running, 428 sleeping, 0 stopped, 1 zombie %Cpu(s): 5,4 us, 1,1 sy, 0,7 ni, 92,0 id, 0,8 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 335460 free, 6746744 used, 1079196 buff/cache KiB Swap: 25165820 total, 25165308 free, 512 used. 602480 avail Mem ... top - 13:27:37 up 7 days, 23:33, 4 users, load average: 0,14, 10,90, 39,04 Tasks: 432 total, 2 running, 429 sleeping, 0 stopped, 1 zombie %Cpu(s): 5,4 us, 1,5 sy, 0,6 ni, 92,1 id, 0,3 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 170052 free, 6936852 used, 1054496 buff/cache KiB Swap: 25165820 total, 25041916 free, 123904 used. 412372 avail Mem ... top - 13:36:38 up 7 days, 23:42, 4 users, load average: 0,69, 2,08, 21,94 Tasks: 432 total, 1 running, 430 sleeping, 0 stopped, 1 zombie %Cpu(s): 7,0 us, 1,7 sy, 0,6 ni, 88,7 id, 2,0 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161400 total, 940524 free, 6162704 used, 1058172 buff/cache KiB Swap: 25165820 total, 24889596 free, 276224 used. 1190036 avail Mem I have top log and the messages log of the event. As you can see, it is not possible to run this 8GiB machine without Swap - I said it would not work and I was right. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXGQeNRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVX+0AniuRB1NXHsDRAT6MvFoo Tm8aY3BZAKCYbVkrrpwr8jg1R9aVuE7DQmMXNg== =R39Z -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Wed, 13 Feb 2019 14:40:05 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> wrote:
I then killed Firefox and Thunderbird, restarted them (the machine has to run my usual workload), then repeated the swapoff experiment.
Telcontar:~/Documents/lists/swapoff_test # time swapoff -a
real 3m30.374s user 0m0.001s sys 3m3.646s Telcontar:~/Documents/lists/swapoff_test #
I was writing my notes on the terminal, when the system *collapsed* and would not respond. I managed to issue "swapon -a" on an ssh session already opened on another machine, which took perhaps half an hour to process.
Yay! I'm happy you tried that trick and it worked :)
Then, with swap back on, the system responded, after also doing some OOM (on mysqld). Thunderbird was not running:
cer@Telcontar:~> grep -i "oom" /var/log/messages <0.4> 2019-02-13 13:16:35 Telcontar kernel - - - [688971.796341] mysqld invoked oom-killer: gfp_mask=0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0 <0.4> 2019-02-13 13:16:35 Telcontar kernel - - - [688971.796366] oom_kill_process+0x213/0x3d0 <0.6> 2019-02-13 13:16:35 Telcontar kernel - - - [688971.796474] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name <0.6> 2019-02-13 13:16:35 Telcontar kernel - - - [688971.860717] oom_reaper: reaped process 12455 (thunderbird-bin), now anon-rss:0kB, file-rss:0kB, shmem-rss:15884kB cer@Telcontar:~>
Interestingly, both mysqld and Thunderbird have been killed differently (one by oom-killer, another by oom_reaper) Why mysqld I have no idea, but it could have been worse.
mysqld is infamous for being chosen. oom-reaper is a relatively recent addition to the oom killer (from suse) There's a good discussion at https://lwn.net/Articles/668126/ [snip] TL;DR
As you can see, it is not possible to run this 8GiB machine without Swap - I said it would not work and I was right.
I think what you've proved is that the machine cannot support the workload. You either need to change the machine or the workload. You might be able to find a browser that uses less memory (or tune FF), dunno. You might be able to find a way to work with less pages open. You can almost certainly find a MUA that uses less memory then Thunderbird. My first thought is claws, of course :) But there are many other possibilities. Or you could move one or other process(es) to some other machine and remote the interface to your current machine, so it is merely serving as the display for that process. Cheers, Dave -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 13/02/2019 17.39, Dave Howorth wrote:
On Wed, 13 Feb 2019 14:40:05 +0100 (CET) "Carlos E. R." <...@telefonica.net> wrote:
I then killed Firefox and Thunderbird, restarted them (the machine has to run my usual workload), then repeated the swapoff experiment.
Telcontar:~/Documents/lists/swapoff_test # time swapoff -a
real 3m30.374s user 0m0.001s sys 3m3.646s Telcontar:~/Documents/lists/swapoff_test #
I was writing my notes on the terminal, when the system *collapsed* and would not respond. I managed to issue "swapon -a" on an ssh session already opened on another machine, which took perhaps half an hour to process.
Yay! I'm happy you tried that trick and it worked :)
No, it did not work: it crashed, as I thought it would. But I said that I would try nonetheless and I did.
Then, with swap back on, the system responded, after also doing some OOM (on mysqld). Thunderbird was not running: ...
Interestingly, both mysqld and Thunderbird have been killed differently (one by oom-killer, another by oom_reaper) Why mysqld I have no idea, but it could have been worse.
mysqld is infamous for being chosen. oom-reaper is a relatively recent addition to the oom killer (from suse) There's a good discussion at https://lwn.net/Articles/668126/
[snip] TL;DR
Curious. Well, Thunderbird had an email in writing. I had to recover it from the draft folder.
As you can see, it is not possible to run this 8GiB machine without Swap - I said it would not work and I was right.
I think what you've proved is that the machine cannot support the workload. You either need to change the machine or the workload.
Neither is possible, unless I get donations ;-P I had to spend money on house repairs, crumbling walls and such. The washing machine refuses to tumble since this weekend, and the fridge controller module is dying - replacement is too expensive and not worth it on a 15 year machine. So I have to replace both machines. At the moment I have more pressing needs rather than replacing the motherboard + cpu + ram. The workload - well, Firefox has too many tabs and windows, which is why I asked about a tab archiver some weeks ago. The machine is very responsive using swap on SSD. After all, swap was invented decades ago precisely to avoid installing more RAM. The problem is some race condition that the current kernel doesn't handle well (the kernel in 42.3 did not have this problem). ]> Tasks: 448 total, 3 running, 444 sleeping, 0 stopped, 1 zombie ]> %Cpu(s): 14,5 us, 2,1 sy, 0,0 ni, 76,7 id, 6,7 wa, 0,0 hi, 0,0 si, 0,0 st ]> KiB Mem : 8161400 total, 712648 free, 5685608 used, 1763144 buff/cache ]> KiB Swap: 25165820 total, 23227900 free, 1937920 used. 1675796 avail Mem 1.6 GB available, that's good. Less than CPU 18% load. # uptime 19:49:46 up 8 days 5:55, 4 users, load average: 0.39, 0.65, 0.68
You might be able to find a browser that uses less memory (or tune FF), dunno. You might be able to find a way to work with less pages open.
You can almost certainly find a MUA that uses less memory then Thunderbird. My first thought is claws, of course :) But there are many other possibilities.
Not as user friendly. Yes, I also use Alpine. I need to see graphics and photos often.
Or you could move one or other process(es) to some other machine and remote the interface to your current machine, so it is merely serving as the display for that process.
No, but I can move some services to another machine, classical client-server setup. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [02-13-19 13:58]:
On 13/02/2019 17.39, Dave Howorth wrote:
On Wed, 13 Feb 2019 14:40:05 +0100 (CET) "Carlos E. R." <...@telefonica.net> wrote:
I then killed Firefox and Thunderbird, restarted them (the machine has to run my usual workload), then repeated the swapoff experiment.
Telcontar:~/Documents/lists/swapoff_test # time swapoff -a
real 3m30.374s user 0m0.001s sys 3m3.646s Telcontar:~/Documents/lists/swapoff_test #
I was writing my notes on the terminal, when the system *collapsed* and would not respond. I managed to issue "swapon -a" on an ssh session already opened on another machine, which took perhaps half an hour to process.
Yay! I'm happy you tried that trick and it worked :)
No, it did not work: it crashed, as I thought it would. But I said that I would try nonetheless and I did.
Then, with swap back on, the system responded, after also doing some OOM (on mysqld). Thunderbird was not running: ...
Interestingly, both mysqld and Thunderbird have been killed differently (one by oom-killer, another by oom_reaper) Why mysqld I have no idea, but it could have been worse.
mysqld is infamous for being chosen. oom-reaper is a relatively recent addition to the oom killer (from suse) There's a good discussion at https://lwn.net/Articles/668126/
[snip] TL;DR
Curious.
Well, Thunderbird had an email in writing. I had to recover it from the draft folder.
As you can see, it is not possible to run this 8GiB machine without Swap - I said it would not work and I was right.
I think what you've proved is that the machine cannot support the workload. You either need to change the machine or the workload.
Neither is possible, unless I get donations ;-P
I had to spend money on house repairs, crumbling walls and such. The washing machine refuses to tumble since this weekend, and the fridge controller module is dying - replacement is too expensive and not worth it on a 15 year machine. So I have to replace both machines.
At the moment I have more pressing needs rather than replacing the motherboard + cpu + ram.
The workload - well, Firefox has too many tabs and windows, which is why I asked about a tab archiver some weeks ago.
The machine is very responsive using swap on SSD. After all, swap was invented decades ago precisely to avoid installing more RAM. The problem is some race condition that the current kernel doesn't handle well (the kernel in 42.3 did not have this problem).
]> Tasks: 448 total, 3 running, 444 sleeping, 0 stopped, 1 zombie ]> %Cpu(s): 14,5 us, 2,1 sy, 0,0 ni, 76,7 id, 6,7 wa, 0,0 hi, 0,0 si, 0,0 st ]> KiB Mem : 8161400 total, 712648 free, 5685608 used, 1763144 buff/cache ]> KiB Swap: 25165820 total, 23227900 free, 1937920 used. 1675796 avail Mem
1.6 GB available, that's good. Less than CPU 18% load.
# uptime 19:49:46 up 8 days 5:55, 4 users, load average: 0.39, 0.65, 0.68
You might be able to find a browser that uses less memory (or tune FF), dunno. You might be able to find a way to work with less pages open.
You can almost certainly find a MUA that uses less memory then Thunderbird. My first thought is claws, of course :) But there are many other possibilities.
Not as user friendly. Yes, I also use Alpine. I need to see graphics and photos often.
Or you could move one or other process(es) to some other machine and remote the interface to your current machine, so it is merely serving as the display for that process.
No, but I can move some services to another machine, classical client-server setup.
-- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)
give it more swap or add memory or upgrade equipment or utilize less resources -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 13/02/2019 20.45, Patrick Shanahan wrote:
* Carlos E. R. <> [02-13-19 13:58]:
give it more swap
It already has 3 times the RAM.
or add memory
it is maxed.
or upgrade equipment
As explained already, unless I get a donation, hardly going to happen anytime soon.
or utilize less resources
Care to hack Thunderbird and Mozilla to use less gigabytes? And none of that applies to the kernel having a bug, which is the problem. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Wed, 13 Feb 2019 19:57:46 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
Yay! I'm happy you tried that trick and it worked :)
No, it did not work: it crashed, as I thought it would.
I meant the trick of keeping an ssh session open. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 13/02/2019 21.39, Dave Howorth wrote:
On Wed, 13 Feb 2019 19:57:46 +0100 "Carlos E. R." <...@telefonica.net> wrote:
Yay! I'm happy you tried that trick and it worked :)
No, it did not work: it crashed, as I thought it would.
I meant the trick of keeping an ssh session open.
Ah, yes! That worked :-) I remembered that the media server has a keyboard and can run an ssh client ;-) Albeit I had to type commands blindly and wait minutes to see the letters displayed, and more for the command to run. Not the first time I do that. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Op maandag 11 februari 2019 20:48:15 CET schreef Carlos E. R.:
On 11/02/2019 14.17, Knurpht-openSUSE wrote:
Op maandag 11 februari 2019 11:21:26 CET schreef Carlos E. R.:
On Monday, 2019-02-11 at 11:12 +0100, Knurpht-openSUSE wrote:
El 2019-02-11 a las 11:12 +0100, Knurpht-openSUSE escribió:
Date: Mon, 11 Feb 2019 11:12:08 +0100 From: Knurpht-openSUSE <knurpht@opensuse.org> To: opensuse-support@opensuse.org Subject: Re: [opensuse-support] Unresponsive desktop
Op maandag 11 februari 2019 09:30:10 CET schreef Carlos E. R.:
[1] My previous laptop had 4 GB RAM, this one 16 GB - both had a full server stack (LAMP, Dovecot etc.) + KDE running
But I have only 8.
Like I have, and swap is only touched by suspend. LAMP stack running, most of the time both Chrome and FF open, editing video, pictures etc. I'm wondering how many tabs FF has open, what these tabs are.
After killing firefox (I restarted Thunderbird half an hour ago) I still have 2.3 GB in swap. After killing Th it is the same figure (using alpine to post this).
Telcontar:~ # free -h
total used free shared buff/cache
available Mem: 7.8G 950M 5.6G 28M 1.3G 6.6G Swap: 23G 2.2G 21G Telcontar:~ #
But, I get 5.6G free, and 1.3 in buff/cache temporarily. With no swap, free would be 2.2 less.
Having swap increases free memory, not the other way round. It makes the system actually faster. That's a common misconception, that having swap makes the system slower. No. What makes it slower is needing to use swap because there is not enough ram.
None of you have looked at the logs in the other post that indicate that the culprit of my problems can be alsa.
Why do you insist on your own interpretations? Not a single poster here has confirmed seeing what you see. And alsa is definitely not the culprit IMNSHO. When the replies say ridiculous things I ignore them, sorry.
Thank you for the appreciation.
Don't worry, I will try swapoff when I get back home and I have 5 gigs used in swap. It will be interesting.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2019-02-03 at 14:33 +0100, Carlos E. R. wrote:
Hi,
Last December I reported this problem on my laptop, and now my desktop also exhibits it.
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
A week before it also froze, but that time I could not observe anything.
I'm not yet sure, but it seems that my upgrade to the kernel used by Leap 15.1 has solved the problem (and also the problem with hibernation restore crashing). I'm now running a bunch of memory hungry applications, and using swap heavily, and no issues (besides things going slow, of course). Firefox, Thunderbird, LibreOffice, Evince, Shotwell, Clementine, Konversation, Alpine... top - 21:30:32 up 6 days, 1:51, 4 users, load average: 0,36, 0,46, 0,45 Tasks: 483 total, 1 running, 481 sleeping, 0 stopped, 1 zombie %Cpu(s): 1,9 us, 0,9 sy, 0,0 ni, 96,7 id, 0,5 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161136 total, 745112 free, 6326860 used, 1089164 buff/cache KiB Swap: 25165820 total, 19614704 free, 5551116 used. 1353532 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5066 cer 20 0 4389304 1,270g 74080 325520 S 0,000 16,32 417:05.80 thunderbird-bin 27150 cer 20 0 2583260 847756 12444 0 S 0,299 10,39 8:52.66 shotwell 7717 cer 20 0 3092444 741564 68480 233292 S 0,000 9,087 13:43.23 Web Content 7735 cer 20 0 3436212 661520 90220 291272 S 2,090 8,106 82:13.16 Web Content 7634 cer 20 0 3281696 595916 47456 270008 S 0,299 7,302 92:24.61 Web Content 7523 cer 20 0 10,255g 591908 119956 293048 S 0,597 7,253 164:38.29 firefox 7685 cer 20 0 3190572 527744 73736 227068 S 0,000 6,467 70:05.15 Web Content 4805 root 20 0 871924 254616 84672 73792 S 1,194 3,120 46:39.04 X 3902 vscan 20 0 905916 249940 2212 406752 S 0,000 3,063 6:02.58 clamd 27918 cer 20 0 1689996 132764 12512 155900 S 0,299 1,627 3:43.26 soffice.bin 8153 cer 20 0 4399444 60840 2880 141700 S 0,000 0,745 2:10.07 java 16342 cer 20 0 333924 49176 8208 166820 S 0,000 0,603 0:53.85 alpine 5036 cer 20 0 776180 47432 15652 16944 S 0,000 0,581 0:37.52 xfdesktop 5013 cer 20 0 1125320 41460 12560 72924 S 0,000 0,508 0:51.48 Thunar 5242 cer 20 0 136048 39900 29820 0 S 0,000 0,489 0:16.02 imap 2320 named 20 0 539448 31632 1308 171064 S 0,000 0,388 0:37.00 named 24818 vscan 20 0 193924 26188 2120 36620 S 0,000 0,321 0:01.08 /usr/sbin/amavi 24925 vscan 20 0 193924 25964 1948 36676 S 0,000 0,318 0:00.97 /usr/sbin/amavi 5077 cer 20 0 683380 25824 8712 47948 S 1,194 0,316 5:14.91 xfce4-terminal 5054 cer 20 0 2536800 22200 728 214884 S 0,000 0,272 0:33.09 clementine 5785 cer 39 19 1133116 20548 5692 39888 S 0,000 0,252 1:00.52 tracker-miner-f 5299 news 20 0 24664 19136 1904 0 S 0,000 0,234 0:00.09 leafnode 12761 cer 20 0 1153156 18116 8160 26580 S 0,000 0,222 1:21.90 konversation 5015 cer 20 0 458336 16136 6764 18152 S 0,000 0,198 0:47.55 xfce4-panel 5852 cer 20 0 491232 14520 6572 14876 S 0,000 0,178 0:08.22 lxterminal 5055 cer 20 0 527648 13156 5780 14144 S 0,000 0,161 0:05.43 panel-1-whisker 5117 cer 20 0 597132 13136 6336 13828 S 0,299 0,161 10:32.87 panel-14-weathe - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXKpRCxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVExAAn2ejJZ3ajmQ9BWxY1KnA n0hocrHfAKCQZhD5r6E267hYBN7MQFMfwVHIvQ== =d8aL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 07/04/2019 21.35, Carlos E. R. wrote:
On Sunday, 2019-02-03 at 14:33 +0100, Carlos E. R. wrote:
Hi,
Last December I reported this problem on my laptop, and now my desktop also exhibits it.
After several days running, this morning it locked as soon as I changed workspaces. I noticed kswapd0 was busy long time, and that firefox had about 10 gigs of virtual memory. The disk activity led was solid blue. I couldn't find out more, the machine froze and had to be hard rebooted.
A week before it also froze, but that time I could not observe anything.
I'm not yet sure, but it seems that my upgrade to the kernel used by Leap 15.1 has solved the problem (and also the problem with hibernation restore crashing).
I'm now running a bunch of memory hungry applications, and using swap heavily, and no issues (besides things going slow, of course).
Firefox, Thunderbird, LibreOffice, Evince, Shotwell, Clementine, Konversation, Alpine...
top - 21:30:32 up 6 days, 1:51, 4 users, load average: 0,36, 0,46, 0,45 Tasks: 483 total, 1 running, 481 sleeping, 0 stopped, 1 zombie %Cpu(s): 1,9 us, 0,9 sy, 0,0 ni, 96,7 id, 0,5 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161136 total, 745112 free, 6326860 used, 1089164 buff/cache KiB Swap: 25165820 total, 19614704 free, 5551116 used. 1353532 avail Mem
PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5066 cer 20 0 4389304 1,270g 74080 325520 S 0,000 16,32 417:05.80 thunderbird-bin 27150 cer 20 0 2583260 847756 12444 0 S 0,299 10,39 8:52.66 shotwell 7717 cer 20 0 3092444 741564 68480 233292 S 0,000 9,087 13:43.23 Web Content
Maybe related to this, I just saw something in the log. The swap in use is now above 6 GB. Apparently the kernel is having some memory problem but coping, not crashing. <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654102] iotop: page allocation stalls for 11744ms, order:0, mode:0x14000d0(GFP_TEMPORARY), nodemask=(null) <0.6> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654108] iotop cpuset=/ mems_allowed=0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654112] CPU: 3 PID: 8611 Comm: iotop Tainted: P O 4.12.14-lp151.23-default #1 openSUSE Leap 15.1 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654113] Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-7516/MS-7516, BIOS V1.5 10/10/2008 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654114] Call Trace: <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654123] dump_stack+0x5c/0x86 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654126] warn_alloc+0xe0/0x170 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654129] __alloc_pages_slowpath+0x732/0xc50 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654133] ? terminate_walk+0xe4/0x100 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654134] __alloc_pages_nodemask+0x20d/0x230 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654137] alloc_pages_current+0x72/0x140 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654139] __get_free_pages+0xa/0x40 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654142] proc_pid_cmdline_read+0x90/0x470 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654144] ? do_filp_open+0xa0/0xf0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654146] ? _copy_to_user+0x22/0x30 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654147] ? cp_new_stat+0x13d/0x160 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654150] ? __vfs_read+0x26/0x140 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654151] __vfs_read+0x26/0x140 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654153] vfs_read+0x89/0x130 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654155] SyS_read+0x42/0x90 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654156] ? SyS_lseek+0x80/0xa0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654159] do_syscall_64+0x7b/0x150 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654163] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654165] RIP: 0033:0x7ffaf1f4ae61 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654166] RSP: 002b:00007ffd8a292af8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654168] RAX: ffffffffffffffda RBX: 00007ffaf232a4c0 RCX: 00007ffaf1f4ae61 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654169] RDX: 0000000000002000 RSI: 000055879cdb0860 RDI: 0000000000000007 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654170] RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000000000 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654171] R10: 0000000000000100 R11: 0000000000000246 R12: 00007ffaeee71090 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654172] R13: 0000000000000007 R14: 000055879cdb0860 R15: 000055879cbb6000 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654173] Mem-Info: <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] active_anon:1159547 inactive_anon:197953 isolated_anon:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] active_file:34229 inactive_file:19251 isolated_file:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] unevictable:58 dirty:67 writeback:0 unstable:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] slab_reclaimable:466310 slab_unreclaimable:37407 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] mapped:77276 shmem:45651 pagetables:24225 bounce:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] free:30080 free_pcp:222 free_cma:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654181] Node 0 active_anon:4638188kB inactive_anon:791812kB active_file:136916kB inactive_file:77004kB unevictable:232kB isolated(anon):0kB isolated(file):0kB mapped:309104kB dirty:268kB writeback:0kB shmem:182604kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 436224kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654181] Node 0 DMA free:15876kB min:132kB low:164kB high:196kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654186] lowmem_reserve[]: 0 2963 7954 7954 7954 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654189] Node 0 DMA32 free:54948kB min:35276kB low:41532kB high:47788kB active_anon:1304484kB inactive_anon:428380kB active_file:45396kB inactive_file:28076kB unevictable:32kB writepending:48kB present:3128896kB managed:3034748kB mlocked:32kB slab_reclaimable:1010672kB slab_unreclaimable:43544kB kernel_stack:3136kB pagetables:18108kB bounce:0kB free_pcp:820kB local_pcp:128kB free_cma:0kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654193] lowmem_reserve[]: 0 0 4990 4990 4990 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654196] Node 0 Normal free:49496kB min:50604kB low:61204kB high:71804kB active_anon:3333360kB inactive_anon:363632kB active_file:91520kB inactive_file:48928kB unevictable:200kB writepending:220kB present:5242880kB managed:5110480kB mlocked:200kB slab_reclaimable:854568kB slab_unreclaimable:106084kB kernel_stack:14720kB pagetables:78792kB bounce:0kB free_pcp:68kB local_pcp:48kB free_cma:0kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654200] lowmem_reserve[]: 0 0 0 0 0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654203] Node 0 DMA: 1*4kB (U) 0*8kB 0*16kB 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15876kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654213] Node 0 DMA32: 3219*4kB (ME) 2677*8kB (ME) 806*16kB (ME) 127*32kB (UME) 29*64kB (UME) 7*128kB (ME) 4*256kB (ME) 1*512kB (U) 0*1024kB 0*2048kB 0*4096kB = 55540kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654224] Node 0 Normal: 7689*4kB (UMEH) 1376*8kB (UMEH) 328*16kB (UMEH) 76*32kB (UMEH) 3*64kB (U) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 49636kB <0.6> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654234] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654234] 206138 total pagecache pages <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654241] 106991 pages in swap cache <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654243] Swap cache stats: add 10069285, delete 9964855, find 19224545/21513208 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654243] Free swap = 19530224kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654244] Total swap = 25165820kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654244] 2096942 pages RAM <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654245] 0 pages HighMem/MovableOnly <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654245] 56658 pages reserved <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654246] 0 pages hwpoisoned <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659843] thunderbird-bin: page allocation stalls for 11564ms, order:0, mode:0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null) <0.6> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659850] thunderbird-bin cpuset=/ mems_allowed=0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659857] CPU: 1 PID: 5066 Comm: thunderbird-bin Tainted: P O 4.12.14-lp151.23-default #1 openSUSE Leap 15.1 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659858] Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-7516/MS-7516, BIOS V1.5 10/10/2008 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659858] Call Trace: <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659869] dump_stack+0x5c/0x86 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659872] warn_alloc+0xe0/0x170 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659875] __alloc_pages_slowpath+0x732/0xc50 ... Top list of processes, sorted by memory use: top - 04:06:46 up 6 days, 8:27, 4 users, load average: 0,49, 0,37, 0,37 Tasks: 481 total, 1 running, 479 sleeping, 0 stopped, 1 zombie %Cpu(s): 2,6 us, 1,0 sy, 0,0 ni, 96,3 id, 0,1 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161136 total, 942204 free, 4910296 used, 2308636 buff/cache KiB Swap: 25165820 total, 18809328 free, 6356492 used. 2484860 avail Mem PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5066 cer 20 0 4458508 1,214g 91568 388448 S 0,298 15,59 472:07.69 thunderbird-bin 7634 cer 20 0 3306468 723440 44876 370612 S 1,190 8,864 95:42.66 Web Content 7735 cer 20 0 3358296 662356 82140 361204 S 1,190 8,116 88:09.76 Web Content 7717 cer 20 0 3061056 602636 65180 303236 S 0,000 7,384 15:32.35 Web Content 7523 cer 20 0 10,262g 553668 117976 332564 S 1,190 6,784 174:10.53 firefox 7685 cer 20 0 3228388 412204 109696 283076 S 0,595 5,051 72:26.80 Web Content 4805 root 20 0 916432 145100 110972 209608 S 1,190 1,778 50:16.42 X 27918 cer 20 0 1689996 128036 21148 169300 S 0,298 1,569 4:19.68 soffice.bin 2320 named 20 0 562588 50708 0 178060 S 0,000 0,621 0:52.94 named 5036 cer 20 0 776180 47548 16168 17192 S 0,000 0,583 0:40.93 xfdesktop 5013 cer 20 0 1125572 37684 14356 78656 S 0,000 0,462 0:53.17 Thunar 3902 vscan 20 0 979648 36216 2672 621104 S 0,000 0,444 7:49.28 clamd 5852 cer 20 0 527072 35664 24744 13864 S 0,000 0,437 0:11.83 lxterminal 12761 cer 20 0 1161920 34448 17492 23984 S 0,000 0,422 1:30.48 konversation 5077 cer 20 0 687980 30520 10192 48832 S 0,298 0,374 6:11.76 xfce4-terminal 5806 cer 20 0 675152 30076 2944 33344 S 0,000 0,369 0:41.00 tracker-store 5054 cer 20 0 2536800 29036 232 220796 S 0,000 0,356 0:35.31 clementine 8153 cer 20 0 4399444 26472 3320 176564 S 0,000 0,324 2:19.17 java 26883 vscan 20 0 194348 25320 1400 37168 S 0,000 0,310 0:00.51 /usr/sbin/amavi 16342 cer 20 0 333924 20096 2964 190656 S 0,000 0,246 1:09.53 alpine 5785 cer 39 19 1133116 20016 1968 36808 S 0,000 0,245 1:15.04 tracker-miner-f 10346 news 20 0 24972 19500 1936 0 S 0,000 0,239 0:00.14 leafnode 5117 cer 20 0 597132 15520 8584 13848 S 0,000 0,190 11:20.41 panel-14-weathe 5015 cer 20 0 458336 15384 7056 19204 S 0,000 0,189 0:51.07 xfce4-panel 8611 root 20 0 57356 15136 2292 1700 S 2,679 0,185 142:04.74 iotop 5055 cer 20 0 527648 14176 7628 14972 S 0,000 0,174 0:05.90 panel-1-whisker 5098 cer 20 0 710596 13984 10000 17408 S 0,000 0,171 2:59.29 panel-19-pulsea Is somebody interested in this, to send the logs? Of course, normally I would restart Thunderbird and Firefox, but I'm keeping the system stressed for observation. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
08.04.2019 5:12, Carlos E. R. пишет: ...
Maybe related to this, I just saw something in the log. The swap in use is now above 6 GB.
Apparently the kernel is having some memory problem but coping, not crashing.
...
<0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654173] Mem-Info: <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] active_anon:1159547 inactive_anon:197953 isolated_anon:0
You have 4.5GB of allocated memory that applications accessed recently. There is really nothing that can be done here short of adding more RAM or not using these applications.
<0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] active_file:34229 inactive_file:19251 isolated_file:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] unevictable:58 dirty:67 writeback:0 unstable:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] slab_reclaimable:466310 slab_unreclaimable:37407
That's over 2GB of kernel memory. That looks too much; you may want to ask on LKML for ideas. There is slabtop command (do not know if it is installed by default) that shows owners of slabs and also how much is active; that may ring the bell for someone with more intimate kernel knowledge. You may want to setup monitoring of memory consumption to see how it evolves.
<0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] mapped:77276 shmem:45651 pagetables:24225 bounce:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] free:30080 free_pcp:222 free_cma:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654181] Node 0 active_anon:4638188kB inactive_anon:791812kB active_file:136916kB inactive_file:77004kB unevictable:232kB isolated(anon):0kB isolated(file):0kB mapped:309104kB dirty:268kB writeback:0kB shmem:182604kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 436224kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654181] Node 0 DMA free:15876kB min:132kB low:164kB high:196kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654186] lowmem_reserve[]: 0 2963 7954 7954 7954 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654189] Node 0 DMA32 free:54948kB min:35276kB low:41532kB high:47788kB active_anon:1304484kB inactive_anon:428380kB active_file:45396kB inactive_file:28076kB unevictable:32kB writepending:48kB present:3128896kB managed:3034748kB mlocked:32kB slab_reclaimable:1010672kB slab_unreclaimable:43544kB kernel_stack:3136kB pagetables:18108kB bounce:0kB free_pcp:820kB local_pcp:128kB free_cma:0kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654193] lowmem_reserve[]: 0 0 4990 4990 4990 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654196] Node 0 Normal free:49496kB min:50604kB low:61204kB high:71804kB active_anon:3333360kB inactive_anon:363632kB active_file:91520kB inactive_file:48928kB unevictable:200kB writepending:220kB present:5242880kB managed:5110480kB mlocked:200kB slab_reclaimable:854568kB slab_unreclaimable:106084kB kernel_stack:14720kB pagetables:78792kB bounce:0kB free_pcp:68kB local_pcp:48kB free_cma:0kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654200] lowmem_reserve[]: 0 0 0 0 0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654203] Node 0 DMA: 1*4kB (U) 0*8kB 0*16kB 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15876kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654213] Node 0 DMA32: 3219*4kB (ME) 2677*8kB (ME) 806*16kB (ME) 127*32kB (UME) 29*64kB (UME) 7*128kB (ME) 4*256kB (ME) 1*512kB (U) 0*1024kB 0*2048kB 0*4096kB = 55540kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654224] Node 0 Normal: 7689*4kB (UMEH) 1376*8kB (UMEH) 328*16kB (UMEH) 76*32kB (UMEH) 3*64kB (U) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 49636kB <0.6> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654234] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654234] 206138 total pagecache pages <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654241] 106991 pages in swap cache <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654243] Swap cache stats: add 10069285, delete 9964855, find 19224545/21513208 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654243] Free swap = 19530224kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654244] Total swap = 25165820kB <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654244] 2096942 pages RAM <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654245] 0 pages HighMem/MovableOnly <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654245] 56658 pages reserved <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654246] 0 pages hwpoisoned <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659843] thunderbird-bin: page allocation stalls for 11564ms, order:0, mode:0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null) <0.6> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659850] thunderbird-bin cpuset=/ mems_allowed=0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659857] CPU: 1 PID: 5066 Comm: thunderbird-bin Tainted: P O 4.12.14-lp151.23-default #1 openSUSE Leap 15.1 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659858] Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-7516/MS-7516, BIOS V1.5 10/10/2008 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659858] Call Trace: <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659869] dump_stack+0x5c/0x86 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659872] warn_alloc+0xe0/0x170 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.659875] __alloc_pages_slowpath+0x732/0xc50 ...
Top list of processes, sorted by memory use:
top - 04:06:46 up 6 days, 8:27, 4 users, load average: 0,49, 0,37, 0,37 Tasks: 481 total, 1 running, 479 sleeping, 0 stopped, 1 zombie %Cpu(s): 2,6 us, 1,0 sy, 0,0 ni, 96,3 id, 0,1 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 8161136 total, 942204 free, 4910296 used, 2308636 buff/cache KiB Swap: 25165820 total, 18809328 free, 6356492 used. 2484860 avail Mem
PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 5066 cer 20 0 4458508 1,214g 91568 388448 S 0,298 15,59 472:07.69 thunderbird-bin 7634 cer 20 0 3306468 723440 44876 370612 S 1,190 8,864 95:42.66 Web Content 7735 cer 20 0 3358296 662356 82140 361204 S 1,190 8,116 88:09.76 Web Content 7717 cer 20 0 3061056 602636 65180 303236 S 0,000 7,384 15:32.35 Web Content 7523 cer 20 0 10,262g 553668 117976 332564 S 1,190 6,784 174:10.53 firefox 7685 cer 20 0 3228388 412204 109696 283076 S 0,595 5,051 72:26.80 Web Content 4805 root 20 0 916432 145100 110972 209608 S 1,190 1,778 50:16.42 X 27918 cer 20 0 1689996 128036 21148 169300 S 0,298 1,569 4:19.68 soffice.bin 2320 named 20 0 562588 50708 0 178060 S 0,000 0,621 0:52.94 named 5036 cer 20 0 776180 47548 16168 17192 S 0,000 0,583 0:40.93 xfdesktop 5013 cer 20 0 1125572 37684 14356 78656 S 0,000 0,462 0:53.17 Thunar 3902 vscan 20 0 979648 36216 2672 621104 S 0,000 0,444 7:49.28 clamd 5852 cer 20 0 527072 35664 24744 13864 S 0,000 0,437 0:11.83 lxterminal 12761 cer 20 0 1161920 34448 17492 23984 S 0,000 0,422 1:30.48 konversation 5077 cer 20 0 687980 30520 10192 48832 S 0,298 0,374 6:11.76 xfce4-terminal 5806 cer 20 0 675152 30076 2944 33344 S 0,000 0,369 0:41.00 tracker-store 5054 cer 20 0 2536800 29036 232 220796 S 0,000 0,356 0:35.31 clementine 8153 cer 20 0 4399444 26472 3320 176564 S 0,000 0,324 2:19.17 java 26883 vscan 20 0 194348 25320 1400 37168 S 0,000 0,310 0:00.51 /usr/sbin/amavi 16342 cer 20 0 333924 20096 2964 190656 S 0,000 0,246 1:09.53 alpine 5785 cer 39 19 1133116 20016 1968 36808 S 0,000 0,245 1:15.04 tracker-miner-f 10346 news 20 0 24972 19500 1936 0 S 0,000 0,239 0:00.14 leafnode 5117 cer 20 0 597132 15520 8584 13848 S 0,000 0,190 11:20.41 panel-14-weathe 5015 cer 20 0 458336 15384 7056 19204 S 0,000 0,189 0:51.07 xfce4-panel 8611 root 20 0 57356 15136 2292 1700 S 2,679 0,185 142:04.74 iotop 5055 cer 20 0 527648 14176 7628 14972 S 0,000 0,174 0:05.90 panel-1-whisker 5098 cer 20 0 710596 13984 10000 17408 S 0,000 0,171 2:59.29 panel-19-pulsea
Is somebody interested in this, to send the logs?
Of course, normally I would restart Thunderbird and Firefox, but I'm keeping the system stressed for observation.
On 08/04/2019 06.33, Andrei Borzenkov wrote:
08.04.2019 5:12, Carlos E. R. пишет: ...
Maybe related to this, I just saw something in the log. The swap in use is now above 6 GB.
Apparently the kernel is having some memory problem but coping, not crashing.
...
<0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654173] Mem-Info: <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] active_anon:1159547 inactive_anon:197953 isolated_anon:0
You have 4.5GB of allocated memory that applications accessed recently. There is really nothing that can be done here short of adding more RAM or not using these applications.
<0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] active_file:34229 inactive_file:19251 isolated_file:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] unevictable:58 dirty:67 writeback:0 unstable:0 <0.4> 2019-04-08 01:06:41 Telcontar kernel - - - [335302.654177] slab_reclaimable:466310 slab_unreclaimable:37407
That's over 2GB of kernel memory. That looks too much; you may want to ask on LKML for ideas. There is slabtop command (do not know if it is installed by default) that shows owners of slabs and also how much is active; that may ring the bell for someone with more intimate kernel knowledge.
You may want to setup monitoring of memory consumption to see how it evolves.
Meanwhile, I updated and rebooted the machine. Just before that, hibernate aborted and was impossible. But no crash. I don't even know if those log entries indicate a problem, or what kind of problem (I was working at the machine most of the time and noticed nothing). I only wondered if this could be important/interesting enough to log a bugzilla here for someone to have a look. (yes, I know the machine would love more RAM, but it is maxed. Thus I would need a new machine, but I'm not prepared to spend that money now) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
participants (9)
-
Andrei Borzenkov -
Carlos E. R. -
Christian Boltz -
Dave Howorth -
Jiri Slaby -
Knurpht-openSUSE -
Liam Proven -
Patrick Shanahan -
Peter Suetterlin