Timeline for Linux using whole swap, becoming unresponsive while there is plenty of free RAM
Current License: CC BY-SA 3.0
31 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 4, 2021 at 20:32 | comment | added | Mikko Rantalainen | In case somebody is reading this question in the future, if OOM Killer takes down something, you can find the details in the kernel log (distros with systemd probably use journalctl). The OOM killer log includes details about memory usage which may help solving the problem. | |
| May 5, 2016 at 12:14 | history | edited | knaecke | CC BY-SA 3.0 | added config changes which fix the problem |
| Apr 30, 2016 at 22:02 | history | edited | knaecke | CC BY-SA 3.0 | add workaround |
| Apr 30, 2016 at 22:01 | vote | accept | knaecke | ||
| Apr 30, 2016 at 21:57 | comment | added | knaecke | It may be an issue with the Xorg.conf and my intel card. I added options like DRI 3 to avoid other problems, this may be no supported correctly. | |
| Apr 30, 2016 at 21:36 | comment | added | sourcejedi | I'd have thought it would end up using XWayland though; I find it interesting if that behaves significantly different to an X-only system. | |
| Apr 30, 2016 at 21:34 | comment | added | sourcejedi | Heh, if that's a realistic option, it sounds like a good way to avoid the legacy that is SysV shared memory :). | |
| Apr 30, 2016 at 21:31 | comment | added | knaecke | It really seems to be X related. I just tested it on wayland and have no issues whatsoever. (It gets triggered on X by starting the game "Papers, please", on wayland this is no problem) | |
| Apr 30, 2016 at 21:22 | comment | added | sourcejedi | Hmm, this doesn't quite make sense to me. Apparently ipcs requires read access, so technically you should run it as root. Not expecting that to help if it's X-related though. | |
| Apr 30, 2016 at 21:03 | comment | added | knaecke | added the output of ipcs | |
| Apr 30, 2016 at 21:03 | history | edited | knaecke | CC BY-SA 3.0 | more ipcs output |
| Apr 30, 2016 at 20:57 | history | edited | knaecke | CC BY-SA 3.0 | added 3036 characters in body |
| Apr 30, 2016 at 20:19 | comment | added | Henrik Carlqvist | Ok, we got the output of top (no big processes), the output of df (no big tmpfs). So what about sys v ipc? Could we also get the output of ipcs? Maybe you have some big shared memory. | |
| Apr 30, 2016 at 20:12 | comment | added | knaecke | @JuliePelletier no, it's a laptop. | |
| Apr 30, 2016 at 19:54 | history | edited | knaecke | CC BY-SA 3.0 | top shared memory |
| Apr 30, 2016 at 19:41 | comment | added | sourcejedi | The 6GB of cache is actually 6GB of shared memory. I've updated my second answer to include information on legacy shared system V memory, but hopefully it's regular mmap() and you won't need that section. | |
| Apr 30, 2016 at 19:37 | comment | added | Julie Pelletier | Is this on a VPS? | |
| Apr 30, 2016 at 19:15 | answer | added | sourcejedi | timeline score: 2 | |
| Apr 30, 2016 at 18:49 | history | edited | knaecke | CC BY-SA 3.0 | meminfo |
| Apr 30, 2016 at 18:47 | comment | added | knaecke | Unfortunately not. I executed in on my system with the the currently full swap (it will probably become unresponsive in a few minutes and kill the x session), but this changed nothing. | |
| Apr 30, 2016 at 18:44 | comment | added | psusi | Try ( as root ) echo 1 > /proc/sys/vm/drop_caches and see if that 6 gb of cache gets freed up. Also add the output of cat /proc/meminfo to your question. | |
| Apr 30, 2016 at 18:35 | history | edited | knaecke | CC BY-SA 3.0 | added 412 characters in body |
| Apr 30, 2016 at 18:31 | answer | added | sourcejedi | timeline score: 2 | |
| Apr 30, 2016 at 18:29 | comment | added | knaecke | But why is my RAM nearly empty, and my swap full? And why does the system not at least fill the RAM before it kills processes? My tmpfs only use few kB. | |
| Apr 30, 2016 at 18:21 | comment | added | Henrik Carlqvist | One more thing that might be worth checking... If you have some tmpfs file system mounted contents below that directory could also consume your virtual memory. df -h | grep tmpfs | |
| Apr 30, 2016 at 18:15 | comment | added | Henrik Carlqvist | You obviously have some process(es) consuming a lot of RAM. As it helps to kill X it is probably some X program(s) which also die when X gets killed. You could look with top and see which processes are using a lot of virtual memory. It is possible to sort on memory usage in top. You could avoid those programs consuming a lot of memory or you could add some more swap to your machine. | |
| S Apr 30, 2016 at 18:07 | history | edited | schaiba | CC BY-SA 3.0 | grammar and syntax edit |
| S Apr 30, 2016 at 18:07 | history | suggested | Peter Carter | CC BY-SA 3.0 | grammar and syntax edit |
| Apr 30, 2016 at 17:29 | review | Suggested edits | |||
| S Apr 30, 2016 at 18:07 | |||||
| Apr 30, 2016 at 17:02 | review | First posts | |||
| Apr 30, 2016 at 17:05 | |||||
| Apr 30, 2016 at 17:00 | history | asked | knaecke | CC BY-SA 3.0 |