Red Hat Bugzilla – Full Text Bug Listing
|Summary:||High CPU load by gnome-vfs-daemon [dbus validation slow]|
|Product:||[Fedora] Fedora||Reporter:||Gian Paolo Mureddu <gmureddu>|
|Component:||dbus||Assignee:||David Zeuthen <davidz>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Version:||6||CC:||alentejo2, bnocera, mclasen, thethirddoorontheleft, triage, vlada|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-05-06 12:50:19 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Gian Paolo Mureddu 2006-11-16 03:42:47 EST
Description of problem: High CPU utilization (+80%) is perceived when transferring data over SMB by the gnome-vfs-daemon, also (maybe as a consequence of this condition) the transfer rate is very low (~10mbit/sec over a 100mbit/sec connection) other protocols, such as sftp or simple ftp transfer much faster, but they are still limited when used through gnome-vfs (e.g, from within Nautilus), however these protocols are considerably faster than SMB (~50mbit/sec) when using gnome-vfs, and these same protocols go full speed when using either samba-client, ftp or sftp from the command line or with programs such as gFTP (though gFTP does not support SMB). The high CPU utilization is confirmed by programs such as gnome-system-monitor, top, ps and gkrellm, the identification of the program responsible of this is easily viewed with top, ps or gnome-system-monitor. These conditions were observed when moving rather large chunks of data over the SMB line (~300Mb), it does not matter the actual number of files (one time it was a large monolithic archive, another several smaller package files) Version-Release number of selected component (if applicable): gnome-vfs-daemon, part of the package: gnome-vfs2-2.16.2-1.fc6 How reproducible: Always Steps to Reproduce: 1. Update gome-vfs2 to the latest version 2. Open an SMB share through smb:// in Nautilus or through the "Connect to server..." dialog 3. Copy a large file from the share to the local system. Actual results: The gnome-vfs-daemon program eats up a lot CPU cycles when transfering large chunks of data over an SMB connection, maybe affecting the transfer rate in the process. Expected results: For the program to use less resources and faster transfer rates.
Comment 1 Alexander Larsson 2006-11-20 08:20:14 EST
I ran this in sysprof, and it seems the validation of messages is really slow. The profile shows 70% of system cpu time spend reading the dbus messages.
Comment 2 Alexander Larsson 2006-11-20 08:26:18 EST
Created attachment 141647 [details] profile for smb copy This is a (large) sysprof profile for copying a large file. About 65% of the system time is spent in _dbus_validate_body_with_reason. Although, as you can see a large part of that (27% total system time) is actually ending up in _dbus_real_assert.
Comment 3 Alexander Larsson 2006-11-20 08:28:09 EST
*** Bug 212379 has been marked as a duplicate of this bug. ***
Comment 4 Alexander Larsson 2006-11-20 09:56:18 EST
I tried the dbus-1.0.0-2.fc6 build which has asserts and stuff disabled, and it seems a lot better. Are we gonna release that as an update?
Comment 5 Alexander Larsson 2006-11-20 09:59:01 EST
When i say better i mean the total cpu use is lower, and the copy is faster. However, dbus_validate_body_with_reason still takes 45% of the system time (although the used system time is less than before). I.E. There are still opportunities for optimization here.
Comment 6 Gian Paolo Mureddu 2006-11-20 12:29:25 EST
Alex, thanks for the confirmation. I wouldn't know how to run a profile to try and identify all the processes in volved. So this is a mixed situation? Part D-Bus and part gnome-vfs?
Comment 7 Alexander Larsson 2006-11-20 13:42:09 EST
No, its a dbus performance issue only.
Comment 8 Alexander Larsson 2006-11-21 03:26:46 EST
*** Bug 216478 has been marked as a duplicate of this bug. ***
Comment 9 Alexander Larsson 2006-11-21 03:26:59 EST
*** Bug 187592 has been marked as a duplicate of this bug. ***
Comment 10 Bug Zapper 2008-04-04 00:43:22 EDT
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
Comment 11 Bug Zapper 2008-05-06 12:50:17 EDT
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.