Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 215890

Summary: High CPU load by gnome-vfs-daemon [dbus validation slow]
Product: [Fedora] Fedora Reporter: Gian Paolo Mureddu <gmureddu>
Component: dbusAssignee: David Zeuthen <davidz>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: alentejo2, bnocera, mclasen, thethirddoorontheleft, triage, vlada
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 12:50:19 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
profile for smb copy none

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:

How reproducible:

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

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
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.

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:

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.