1

This is an older machine running a Debian-based distro with lxde and pcmanfm used as file manager. pcmanfm normally runs quite well, except when it comes to copying very large files (e. g. *.VOBs from an uncompressed DVD). Well, actually I thought it would use my swap (set at 3.5 GB) but unfortunately swap would always show about 12 MB.
So is pcmanfm ignoring the swap file? Unfortunately, one of this machine's RAM modules showed errors and I had to remove it. So I'm currently down to only 1 GB of physical RAM :(. Still, this should not matter if swap was correctly addressed!

Example from syslog:

[40398.719466] Out of memory: Kill process 21573 (compiz) score 2 or sacrifice child

Instead, processes that require most resources get killed by the kernel, coincidentally depending what it gets hold of next (usually compiz, dbus etc.)

Is there a way to "tell" pcmanfm to use the swap space anyway?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
syntaxerror
  • 2,236
  • 2
  • 27
  • 49
  • 3
    Copying files should not take much memory. I copy GiB large files on systems with 64MiB of memory without problems. I don't know why pcmanfm eats so much memory, but it looks like a bug. Can you try to copy using the `cp` command in the terminal? – Marco Sep 26 '13 at 12:33
  • Oh yes, `cp` works, I know that. Did that 3 days ago with a 125 GB image file from a partition (preferably done from "built-in" consoles CTRL-ALT-F1 to not interfere with anything). But sometimes it's more comfortable to do this via file manager, especially when you have to *select* some files or directories. – syntaxerror Sep 26 '13 at 13:07
  • 2
    So is the question "how to make pcmanfm to use swap more readily?" or "why am I getting OOM under pcmanfm"? The answer to the first has been given but, as others have noted, that answer does nothing to fix the bug causing the OOM. A very quick look around the pcmanfm's source in libfm seems to show that the program may try to copy the file contents into its internal clipboard which is obviously not the way to do it. – msw Sep 26 '13 at 13:47
  • OUCH! Thanks a lot, I wasn't aware of that. But this is because (as you just pointed out) there is no *separate* source of the file manager you could download but it's crammed into `libfm`. And alas, you have to learn about that fact first if you have never delved into its internals before. – syntaxerror Sep 26 '13 at 14:28
  • @msw You should make this an answer, since it explains the problem. – Gilles 'SO- stop being evil' Sep 26 '13 at 22:48

2 Answers2

2

I would try to answer you a more generic question:

Is there a way to "tell" a process to use the swap space anyway?

The Linux kernel provides via /proc/sys interface a property which defines how aggressively memory pages (anonymous only !) are swapped out to disk.

The vm.swappiness property is applied globally per system but not per process. Set this value low if you want to avoid swapping as much as possible. If your system process sleeps for a long time you may benefit with an aggressive swapping behavior by increasing this value. This global property is available as /proc/sys/vm/swappiness and can be tuned with sysctl tool.

With introduction of cgroups in kernel 2.6.24, it is possible to make it more granular with memory subsystem. Lets assume you have available a cgroup hieararchy with memory subsystem attached (/cgroups/mem) and a cgroup (/cgroups/mem/your_cgroup) with tasks/processes defined (/cgroups/mem/your_cgroup/tasks). Then, you can change swappiness behaviour for this group of tasks as follows:

cd /cgroups/mem/your_cgroup
echo 90 > memory.swappiness

How to assign a process to this cgroup automatically? I would create a simple rule in the /etc/cgrules.conf file

your_user:pcmanfm   memory  /your_cgroup

This file is then used by cgroup rules engine daemon (cgred service) for automatic processes classification.

For more details please check Linux kernel cgroups documentation.

dsmsk80
  • 3,038
  • 1
  • 15
  • 20
  • 2
    I fail to see how setting the swappiness would prevent the issue in any way. Regardless of the swappiness setting the kernel will use the swap when running out of physical memory. – Marco Sep 26 '13 at 13:12
  • @dsmsk80 Thanks, regardless of if it will solve my OOM problem, this is at least something interesting to fiddle with! (BTW could you please consider making the word "low" in boldface too for clarity's sake?) – syntaxerror Sep 26 '13 at 13:22
  • 1
    Thanks, that's more like it! `man proc` revealed that it is set to __60__ by default. But on my system, it was set to 5. That's "quite" a difference, I must say... – syntaxerror Sep 26 '13 at 13:38
  • But neither setting (5 or 60) will make the slightest bit of difference to a system that is out of memory. Indeed fiddling with the swapiness setting is much like the proverbial "rearranging the deck chairs on the Titanic": it gives the appearance of doing *something* but the ship is still going to sink. – msw Sep 26 '13 at 17:24
  • LOL. YMMD with that great comparison.:) But for real, I think it might make a difference to a system that is *not yet* out of memory. That is, if you try adjusting swappiness *before* copying the huge-size stuff, you might have a slight chance of getting swap utilized *way earlier* (ideally preventing vital processes from being killed). Or couldn't you? – syntaxerror Sep 26 '13 at 19:13
  • 1
    @syntaxerror Running out of memory is about running out of virtual memory. How much of it is in swap and how much of it is in RAM is irrelevant. You will not gain anything by fiddling with swappiness. – Gilles 'SO- stop being evil' Sep 26 '13 at 22:49
-1

I had the same problem with Lubuntu 14.04 when I started my computer (a laptop) with a second display.

A workaround is to turn off the second display automatically when the computer starts (in an autostart file in /home/user/.config/lxsession/Lubuntu) - I used xrandr --output VGA1 --off since I was using a vga monitor for my second display.

I then ran a desktop file then calls a bash file (perhaps overkill) that sets xrandr the way I want it.

I think that the key is that you have to get down to one display (your primary display) and then start up the second display. When I do it this way it uses the desktop image file correctly, and my pcmanfm cpu% never goes high.

Phil

user2383235
  • 1
  • 1
  • 1
    Can you provide more detail around why you think a second display has anything to do with PCManFM pegging the CPU? The two seem completely unrelated... – jasonwryan Aug 30 '14 at 06:19