Memory leak in Nautilus? (3/12/2011)

try this fix.
http://www.webupd8.org/2010/07/nautilus-memory-leak-fix-ubuntu-1004.html

   David
   in TN

Sorry,

I already tried that, and apparently I don't have that package installed.

Please, report a bug.

Can you give the output of:

uname -a; lsb_release -a; echo; apt-cache policy nautilus

Thanks

@ actionparsnip (Huh?!)

uname -a:
Linux Storage3 2.6.32-29-generic #58-Ubuntu SMP Fri Feb 11 20:52:10 UTC 2011 x86_64 GNU/Linux

lsb_release -a:
Distributor ID: Ubuntu
Description: Ubuntu 10.04.2 LTS
Release: 10.04
Codename: lucid

echo:
(returned no data)

apt-cache policy nautilus:
autilus:
  Installed: 1:2.30.1-0ubuntu1.1
  Candidate: 1:2.30.1-0ubuntu1.1
  Version table:
 *** 1:2.30.1-0ubuntu1.1 0
        500 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
        100 /var/lib/dpkg/status
     1:2.30.0-0ubuntu4 0
        500 http://us.archive.ubuntu.com/ubuntu/ lucid/main Packages

Jim

@ delance

Bug submitted:

Ubuntu » “nautilus” package » Bugs » Bug #734552

Try:

sudo add-apt-repository ppa:am-monkeyd/nautilus-elementary-ppa; sudo apt-get update; sudo apt-get -y upgrade; sudo apt-get -f install

You should now have nautilus 2.31.1

May help

Interesting update:

Nautilus may not be entirely at fault:

I did, (tried to do!) a multi-gig tar-gz from one drive to another (it eventually failed because my target drive did not have enough space)

At the end of the tar/gz operation SysMon shows a stable 793 meg of RAM used - even after dismissing the terminal that ran the tar-gz. That's 300 megs of memory not returned to the memory pool.

Is it possible that the latest kernel's memory scavenging is not returning all allocated memory when released?

Is it possible that the terminal - being in a window - still implicates Nautilus?

I still think that Nautilus remains implicated to some extent, but the issue may be more complex than originally imagined.

Update:

Before I continue with all of your excellent suggestions, I am investigating the possibility that this may be a problem with the latest *kernel* and not Nautilus.

I have subsequently seen some interesting things that may actually implicate the kernel, so I have rebooted using an older kernel and I am repeating some of my huge file moves, both via command-line and via Nautilus.

If, for the sake of argument, I exonerate Nautilus - is it possible to "back-out" a bug in launchpad? (and possibly reference a new bug as the reason for backing it out?)

I don't want to pull the trigger just yet, but I do want to do some more research before I say one thing or another.

What say ye?

Jim

Could you install in desktop upper bar, the gadget (don't know English word) linked to monitoring of system resources, and then check which type of RAM is used: User, Shared, Buffer, Hidden or Free. As kernel uses lot of extra memory in 4GB configuration as I/O cache, it's not uncommon today to have all remaining RAM used as I/O buffer. All I/Os are done when more memory is required, which sometimes induces big latency.

@ Delance

Do you know it's name? (even if it's not in English?)

running TOP shows a lot of memory being used as "buffer"

@ everybody

Actually, I am becoming more confused. There are times when it appears that the kernel is hogging memory, at other times it seems that Nautilus has grabbed it all. Regardless of kernel used.

On another topic: If the kernel has the nasty habit of grabbing "all remaining RAM" to be used as "I/O buffer" - I would say that this is a serious bug in the kernel! The kernel's memory management should not be so stupid as that.

If the kernel is holding all the physical RAM, then it's ok. If it is using a lot of swap and never releasing, then it is not ok. It is not a bad habit to use all RAM, since all RAM not being used is misusing resources. RAM is fast and needs to be used as much as possible.

grabbing "all remaining RAM" to be used as "I/O buffer" avoid hard disk access which are slow and multiple flash memory write which reduce its life expectancy. So it's not so stupid, except when it has to dump all this memory or when a crash make lost all buffered data. But Nautilus should not use this memory, as it is I/O buffer managed by kernel. I can't tell you more.

@ Federico
@ Delance

Viz.: Kernel grabbing RAM

I know that it makes sense for the kernel to grab RAM as needed to substitute for slow disk-accesses. This is normal and expected behavior.

However, when the Kernel, or Nautilus, grabs ram and fails to either re-use it or relinquish it, that's a problem.

Example: I do a 1T file copy and the kernel/nautilus grabs 1.45 gigs of RAM out of 2.9 gigs. Once the file copy ends, the memory is not relinquished into the common pool for reuse.

I then do another 1T file copy and the kernel/nautilus grabs the rest of RAM (1.45 gigs) or a significant portion of it, to perform that file copy.

Common-sense tells me that if whatever process grabbed 1.5 gigs of ram for a file transfer - the next file transfer should be able to use that same space if the first one is clearly and obviously finished. (which should be easily determined. The kernel, if not nautilus, should know what processes are currently active and running.

If, for whatever reason, the RAM requirements for the next process or transfer is greater than 1.5 gigs - it should consume the additional ram needed to make the total ram consumed for that process equal it's requirement. (i.e. if the next process / copy / whatever needs 1.7 gigs of RAM, the additional 0.2 gigs of ram should be added to what is there - instead of grabbing an *additional* 1.7 gigs.

Common-sense also tells me that at the end of the file copy, absent some other process that needs this large block of RAM, the excess RAM should be relinquished to the common memory pool (global heap) so that some other process can use it if needed.

It is also common-sense that "thrashing swap" is extremely expensive as far as system performance is concerned, so the kernel should try to manage memory in such a way as to avoid using swap if at all possible. (i.e. reducing copy buffer size prior to dedicating swap as buffer space.)

When I start the system - GUI running - sitting there in a quiescent state the system consumes something between 350 - 400 megs of ram - steady-state. "It is intuitively obvious. . . . ." that the kernel does not need to grab 4 gigs of RAM just because it is available.

By comparison, running PerfMon, (a feature in Task Manager), in Windows 7, or XP - shows a certain (relatively small) amount of RAM consumed when quiescent. If I start a process that requires larger amounts of RAM, Windows allocates the RAM to the process and once that process terminates the excess RAM is (almost) immediately relinquished back to the common memory pool.

*VISTA* had a problem where the kernel consumed all available RAM, forcing any additional processes to run from swap. M$ fixed that damn fast in an update - which helped but did not completely resolve the issues. Windows 7 was released with a much more efficient memory management subsystem. (I am not sure, but I believe that Vista SP1 helped to resolve that issue with a more efficient memory manager - perhaps borrowed from Win-7.)

I am continuing to research this - and as a result I am fighting with the (ahem!) "choices" that Ubuntu is giving me about the running-state of my system. Ultimately what I would like to do is reboot into run-level 3 and try these tasks again to see who the guilty party REALLY is.

Unfortunately, Ubuntu seems to have depreciated run-level 3 and getting that mode to work appears to be a non-trivial undertaking. (Ref: Question #149356 )

So much for "choices". . . . . .

@ Everyone

Since getting into a "pure" runlevel-3 is darn near impossible - and I really don't want to thrash on this. . . . .

Also, since I get the same effect from a terminal window (as root) as I do from a drag-and-drop. . . . . .

Is it safe to conclude that maybe the problem is NOT nautilus, but might be a kernel (memory management) bug?

As an additional data-point, I was reviewing some old e-mails, and I noticed that on Feb 22, 2010, I experienced the same issue, which brought my file-server to it's knees - it basically froze solid and needed a hard-reboot from the frozen state to recover.

Earlier this year, (around the mid-Feb timeframe), I experienced a catastrophic file-server crash that, though I cannot prove it because of the disastrous nature of the crash - the way things locked up leads me to believe that this bug may have cost me my server on several occasions.

It is only by the grace of Almighty God - and my backups - that I wasn't totally screwed to the wall.

[NB: If your system pukes it's guts up all over your RAID-5 array, "RAID-5" won't save you. I was running RAID-*10*, belt AND suspenders, and it still got clobbered. . . .]

It is not uncommon for me to do multi-meg / multi-T transfers of data - as I move very large file images, ISO's, and such like around on a regular basis. (I am often called upon to receive, build, test, and/or transmit large/huge file "globs", DVD-sized ISO's, and such like)

I have a sneaking suspicion that - until this gets solved - I'm going to have to schedule a Cron-daily job that does a restart (shutdown -r now) at about 02:00 each night - to make sure memory gets flushed.

Any comments?

Jim