You are not logged in.
I'm not quite sure which forum to post this in, but this seems right.
With reasonable regularity, my whole system freezes, almost to a complete halt. The freeze itself seems to take 5-10 seconds, during which time I can switch between windows, interact etc., but in the end everything stops. I can usually switch to a tty but it takes 2-8 minutes from I press ctrl-alt-f2 until it appears. If I kill Firefox, eventually I can return to work again.
dmesg has this:
[356927.994259] Out of memory: Kill process 1468 (firefox) score 298 or sacrifice child
[356927.994640] Killed process 1701 (plugin-containe) total-vm:794732kB, anon-rss:109672kB, file-rss:0kBso I guess the plugin-container is to blame.
I recently had Linux Mint and Ubuntu installed on the same computer, none of which had this problem.
Can someone suggest ways to solve the problem (and I don't count "Don't watch Youtube while you're working" as a valid solution)?
Last edited by eyolf (2014-08-27 18:15:31)
Offline
What's the output of "free -m" and "smem -kt" (as root) run during your regular activities?
Offline
Here's the output with a youtube video running in the background:
# free -m
total used free shared buffers cached
Mem: 3957 3400 556 33 72 719
-/+ buffers/cache: 2609 1347
Swap: 0 0 0# smem -kt
PID User Command Swap USS PSS RSS
6147 eyolf dbus-launch --sh-syntax --e 0 284.0K 284.0K 288.0K
11717 eyolf ./words 0 380.0K 380.0K 388.0K
6229 eyolf /bin/sh /usr/bin/gnome-do 0 416.0K 416.0K 428.0K
9247 eyolf /bin/sh -c set -- '/home/ey 0 424.0K 424.0K 436.0K
11716 eyolf /bin/bash /usr/bin/words 0 428.0K 428.0K 440.0K
13289 eyolf /bin/sh -c set -- '/home/ey 0 428.0K 428.0K 440.0K
871 eyolf /usr/lib/systemd/systemd -- 0 620.0K 620.0K 648.0K
8579 eyolf /usr/lib/gvfs/gvfsd-metadat 0 624.0K 624.0K 656.0K
6281 eyolf /usr/lib/GConf/gconfd-2 0 672.0K 749.0K 2.3M
25061 eyolf /usr/lib/pulse/gconf-helper 0 800.0K 800.0K 832.0K
6153 eyolf /usr/lib/dconf/dconf-servic 0 868.0K 868.0K 900.0K
6166 eyolf /usr/lib/gvfs/gvfsd 0 816.0K 920.0K 3.5M
10819 eyolf /bin/bash /usr/bin/yaourt i 0 968.0K 968.0K 980.0K
6185 eyolf /usr/lib/gvfs/gvfsd-fuse /r 0 1.0M 1.0M 1.1M
8255 eyolf htop 0 1.1M 1.1M 2.6M
6148 eyolf /usr/bin/dbus-daemon --fork 0 1.0M 1.2M 2.5M
8251 eyolf -zsh 0 1.7M 1.7M 1.7M
9419 eyolf zsh 0 1.7M 1.7M 1.7M
12072 eyolf zsh 0 1.7M 1.7M 1.7M
9141 eyolf zsh 0 1.7M 1.7M 1.7M
9321 eyolf zsh 0 1.7M 1.7M 1.7M
11853 eyolf zsh 0 1.7M 1.7M 1.7M
11064 eyolf zsh 0 1.8M 1.8M 1.8M
18564 eyolf zsh 0 2.0M 2.0M 2.1M
6204 eyolf /usr/lib/gvfs/gvfs-udisks2- 0 2.1M 2.3M 5.3M
12359 eyolf zsh 0 1.7M 2.4M 5.4M
13214 eyolf zsh 0 1.7M 2.4M 5.6M
11996 eyolf /usr/lib/gvfs/gvfsd-http -- 0 3.1M 3.1M 3.2M
6248 eyolf /usr/lib/gvfs/gvfsd-trash - 0 3.4M 3.5M 6.7M
25054 eyolf /usr/bin/pulseaudio --start 0 4.1M 5.2M 9.2M
3832 eyolf mocp 0 5.3M 5.3M 5.4M
15345 eyolf python2 /usr/bin/smem -kt 0 9.6M 9.8M 12.1M
9225 eyolf /usr/bin/python -O /usr/bin 0 13.8M 13.8M 13.8M
6226 eyolf /usr/lib/mate-polkit/polkit 0 14.5M 14.7M 17.9M
13216 eyolf /usr/bin/python -O /usr/bin 0 13.7M 14.8M 20.0M
6140 eyolf mate-session 0 14.7M 14.9M 19.1M
6272 eyolf /usr/lib/mate-panel/notific 0 14.7M 15.1M 21.2M
6216 eyolf mate-screensaver 0 15.1M 15.2M 17.7M
12074 eyolf /usr/bin/python -O /usr/bin 0 16.1M 16.8M 19.4M
11855 eyolf vim 0 17.3M 17.3M 17.4M
9421 eyolf vim 0 17.3M 17.3M 17.4M
6222 eyolf mate-power-manager 0 17.0M 17.5M 23.8M
6218 eyolf mate-volume-control-applet 0 17.1M 17.6M 22.9M
6270 eyolf /usr/lib/mate-panel/clock-a 0 17.9M 19.1M 29.4M
9248 eyolf vim -- /home/eyolf/.vimrc 0 19.2M 19.2M 19.3M
9285 eyolf /usr/bin/python -O /usr/bin 0 20.6M 21.2M 24.0M
6268 eyolf /usr/lib/mate-panel/wnck-ap 0 20.5M 21.3M 31.8M
6159 eyolf marco 0 21.3M 22.9M 33.2M
6227 eyolf nm-applet 0 21.9M 23.3M 29.3M
15027 eyolf /usr/bin/gvim -f /tmp/vimpe 0 21.4M 26.7M 59.7M
15250 eyolf /usr/bin/gvim -f /tmp/vimpe 0 21.4M 26.9M 60.1M
9315 eyolf mate-terminal 0 26.1M 27.7M 39.9M
12779 eyolf caja 0 22.4M 29.9M 65.3M
6157 eyolf /usr/lib/mate-settings-daem 0 27.3M 31.0M 41.6M
6164 eyolf mate-panel 0 31.0M 31.8M 40.6M
12345 eyolf vidalia 0 62.9M 68.4M 103.3M
6261 eyolf mono /usr/lib/gnome-do/Do.e 0 94.8M 95.5M 105.8M
14331 eyolf luakit 0 111.2M 120.1M 160.8M
12638 eyolf /usr/lib/firefox/plugin-con 0 118.7M 134.2M 179.2M
13290 eyolf zathura -- /home/eyolf/doku 0 132.5M 136.8M 145.3M
14386 eyolf thunderbird 0 262.2M 269.1M 307.7M
12373 eyolf /usr/lib/firefox/firefox 0 742.3M 760.5M 812.4M
-------------------------------------------------------------------------------
62 1 0 2.0G 2.1G 2.5G Offline
It sounds as if you run out of memory at some point (maybe Firefox is eating more and more memory?), the out-of-memory killer kicks in at some point and kills something (plugin-container was using only 100 MB of RAM). If you have Magic SysRq (fully) enabled, you can use Alt+SysRq+f to invoke the oom killer.
You could run "dstat -cdnpmgs --top-bio --top-cpu --top-mem" (as root) and show me its output from the time when your PC stops responding. dmesg should also have more info about the state of your memory when the oom killer strikes.
Offline
Great. I can see a looong evening of youtube videos and flash-games ahead of me.
I'll work hard to get a freeze going, and will return with dstat outputs.
Offline
add some swap
Offline
Arrgh. I'd forgotten to add the swap partition to the fstab. I feel like the "is the computer plugged in?" kind of customer support caller.
Oh well. I think I'll watch all those videos anyway, I was kinda looking forward to it.
Thanks for your help, both of you.
Offline
Adding swap should help, but you might still want to see what is (was) actually happening, what is eating a lot of memory, etc.
Offline
True. Should I swapoff to provoke a freeze, or is that overdoing it?
Offline
Well, you could see if you run into problems sooner or later with swap enabled. You say you didn't have problems with other distros, thus adding swap should provide you with enough virtual memory for your workload, unless some program behaves differently in Arch. Maybe run "smem -kt" after some long uptime and see if Firefox isn't using e.g. 2 GB of RAM, which it really shouldn't, unless you have a lot of tabs open.
What makes me wonder is why the oom killer apparently didn't active quickly when you apparently ran out of memory.
Offline
Well, you could see if you run into problems sooner or later with swap enabled. You say you didn't have problems with other distros, thus adding swap should provide you with enough virtual memory for your workload, unless some program behaves differently in Arch. Maybe run "smem -kt" after some long uptime and see if Firefox isn't using e.g. 2 GB of RAM, which it really shouldn't, unless you have a lot of tabs open.
I do tend to have 25+ tabs open most of the time, but it's never caused this kind of problems before. I'll try smem -kt and report back if I see something odd.
What makes me wonder is why the oom killer apparently didn't active quickly when you apparently ran out of memory.
Yes, I would have expected that too. What I also would have expected, after having used Firefox for ten years now, that some day the accusations/rumors/complaints of memory leakage and that "Firefox is a memory hog", would stop, but they don't seem to. Maybe it's true then...
Offline