GNOME Bugzilla – Bug 107418
fam monitoring/thumbnailing causing very high cpu usage.
Last modified: 2012-08-14 18:30:24 UTC
When i am downloading a png image into a folder that is being monitored by nautilus/fam nautilus tries to thumbnail the image every time it is updated by fam. This causes the cpu to spike and nautilus to become unresponsive just because i'm downloading an image.
See this thread on destkop devel: http://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00223.html I think that the issue is that every time a file is changed nautilus updates it and recreates the thumbnail. But the thumbnailing is only part of the problem. There is still very high cpu usage with normal files. I would suggest that disabling refreshing when a file's size is changed.
i have two ideas 1)Mime system will identify the file type ( if this a image file or Movie) and It Will Remember is size then it will refresh every 5 sec if this is little pic .... (u got the idea?) 2)Disable Auto Refreshing.
*** Bug 103820 has been marked as a duplicate of this bug. ***
Maybe the best solution would just be not to thumbnail on a fam induced refresh only on a manual one.
I just did some experimentations: run 'dd if=/dev/zero of=del' both fam and nautilus showing 20-30% CPU Usage Doing the same without nautilus fam uses 20-40% So I don't think that this is really a thumbnailing issue. It looks unpolished to have the thumbnail trying to generate as you download, but the CPU usage is almost definately to do with the actual file monitoring.
this is fixed in gnome-vfs head.
This was reintroduced at some time and it is still present in GNOME 2.4 (Debian unstable flavour)..
*** Bug 158272 has been marked as a duplicate of this bug. ***
Reopening and updating Version based on duplicate bug and comment 7. Does anybody know if this is still occuring in 2.8?
this is definitely still occurring in 2.8. But instead of high CPU usage, the constant re-thumbnailing of a currently-downloading movie file creates a moderate CPU load (with famd running, anyway) and is kind of annoying.
*** Bug 164213 has been marked as a duplicate of this bug. ***
Still occurring in Nautilus 2.9.2, see http://bugzilla.gnome.org/show_bug.cgi?id=164213 (last duplicate bug)
*** Bug 154778 has been marked as a duplicate of this bug. ***
*** Bug 172974 has been marked as a duplicate of this bug. ***
Still happening on 2.10/hoary. Very annoying. I am copying a movie file from a DVD to my hard drive. Each file takes 5 minutes to copy. During this time, nautilus keeps respawning /usr/bin/gnome-video-thumbnailer over and over and over again, making the system unresponsive (even the mouse pointer becomes "jumpy"). I think nautilus needs an exponential backoff on file change notifications, if you know what I mean...
2005-05-08 Martin Wehner <martin.wehner@gmail.com> * libnautilus-private/nautilus-thumbnails.c: (thumbnail_thread_start): Don't try to thumbnail files which have been modified in the last few seconds to avoid constantly re-thumbnailing them. Current cool-off period is three seconds. Fixes bug #107418.
Can this possibly be added to the GNOME 2.10 branch too?
*** Bug 300723 has been marked as a duplicate of this bug. ***
*** Bug 305630 has been marked as a duplicate of this bug. ***
The patch is on the stable branch too now, so it'll be in gnome 2.10.2
*** Bug 310766 has been marked as a duplicate of this bug. ***
*** Bug 312833 has been marked as a duplicate of this bug. ***
*** Bug 317690 has been marked as a duplicate of this bug. ***
*** Bug 114185 has been marked as a duplicate of this bug. ***
This is still happening in 2.14; this has been fixed?
Reopening as per recent duplicates.
*** Bug 440041 has been marked as a duplicate of this bug. ***
*** Bug 462741 has been marked as a duplicate of this bug. ***
*** Bug 384585 has been marked as a duplicate of this bug. ***
bug 430043 seams related, although it is not the same issue.
*** Bug 353223 has been marked as a duplicate of this bug. ***
*** Bug 155136 has been marked as a duplicate of this bug. ***
*** Bug 374100 has been marked as a duplicate of this bug. ***
Created attachment 107496 [details] [review] patch to gnome-vfs add notification when files are closed for writing
The problem here is that Nautilus doesn't know when a program is finished editing a file, so it updates the thumbnail every time it changes. However, on Linux, inotify lets programs know when a file has been closed for writing, which is exactly the kind of information Nautilus is looking for. I therefore propose that Nautilus should only update an icon when a file is closed for writing. Maybe let it change the icon once when a file is changed, and thereafter not do anything on file change events until there's a file closed for writing event. Considering that this proposal is a fairly significant break from current behavior (and that I've already taken two hours to pore over the labyrinth of Nautilus' file monitoring, icon factory, and thumbnailing code and gotten nowhere), I'm going to wait until there's a consensus before trying to implement it. The necessary changes to GnomeVFS are much simpler, however, and seem a lot more straightforward and uncontroversial. So, I'm attaching a patch to get GnomeVFS to notify programs of IN_CLOSE_WRITE events (I hope it works... :) hth, ~thomas
One other thing. I know that there's this program in POSIX called 'fuser' that will tell you what programs are using a file, and even how they are using that file- for reading, writing, executing, mmaping, as their current directory, or as their root directory. While IN_CLOSE_WRITE is already the perfect trigger for icon updates on a Linux system, GNOME is supposed to run on systems that don't have inotify yet. Here's where fuser could be useful: when a file is changed, don't wait three seconds for more changes or make a new icon, check if it's open for writing, and check again every so often until it's closed. Maybe with a timeout if some ridiculous program that isn't updating it nevertheless wants to keep it open for writing all day. hth, ~thomas
IMO this is a fairly important bug as it affects me every time I download a video file to desktop. I can save to a different location and avoid this error but will be a annoyance to non-power users. Saving a file (specially a video) to desktop is a very common user operation and will make the whole desktop experience suffer and users won't understand why. Good to know there is already a proposed solution. Hope to see it in gnome soon (next release?).
Patch obsoleted by GIO. Setting patch status.
I had the idea to prevent creating thumbnails when the file is open in "write" mode; but I am not sure whether it's possible on GIO or not. Anyone? I will work on it if someone give me a hint where to start and what's the resolution.
*** Bug 585005 has been marked as a duplicate of this bug. ***
This bug hit me with more than CPU usage. My RAM went flying through the roof (disk started swapping madly), my window borders crashed, and my gnome-panel started to die slowly. It took me a good five minutes to get control of my computer enough to find this bug and kill the running video thumbnailing process. Very nasty!
[Bumping version number as per dup]
The problem still exists. Ubuntu 12.04 LTS with gnome-session 3.2.1 Are there any workarounds besides not having the download folder open in Nautilus? As the bug is nearly 10 years old, it could be that I am leaving this comment in the wrong place. If so, please tell me where to report it. Thanks for any help.
*** This bug has been marked as a duplicate of bug 593229 ***