ubuntuone-syncdaemon hogs the processor, interferes with video playback

[Rick Spencer]

Binary package hint: ubuntuone-client

Steps:
1. Boot mini-10v mini-1ov
2. Wait for network to connect
3. Start web browser
4. Try to watch a video on the web, note that video is unwatchably choppy
5. Run top, note that ubuntu0ne-syncdaemon is taking up +/- 74% of one core
6. Try to kill ubuntuone-syncdaemon, note that you can't because the process ID is constantly changing

Expected:
File syncing will not interfere with normal usage of the computer

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: ubuntuone-client 1.5.4-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-4.31-generic 2.6.38-rc5
Uname: Linux 2.6.38-4-generic i686
NonfreeKernelModules: wl
Architecture: i386
Date: Sat Feb 19 10:01:36 2011
InstallationMedia: Ubuntu-Netbook 10.04 "Lucid Lynx" - Alpha i386 (20100329)
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 LC_MESSAGES=en_US.utf8
 SHELL=/bin/bash
SourcePackage: ubuntuone-client
UbuntuOneSyncdaemonExceptionsLog:

UbuntuOneUserSyncdaemonConfig:
 [bandwidth_throttling]
 read_limit = 2097152
 write_limit = 2097152
 on = False

[John O'Brien (jdobrien)]

Seems we need to test this on a netbook, i do not see these kinds of loads on a dual core laptop with a fast hard drive.

[Lucio Torre (lucio.torre)]

6. Try to kill ubuntuone-syncdaemon, note that you can't because the process ID is constantly changing

For some reason syncdaemon is dying and restarting. It should not do that.

Can we please get the logs from ~/.cache/ubuntuone/logs/* to see whats going on?

[Guillermo Gonzalez (verterok)]

Hi Rick,

Looks like a problem in the metadata storage/backend.

would you mind attach/paste the output of: ls -la ~/.local/share/ubuntuone/syncdaemon/tritcask/

Also, it would be helpful if you attach the offending metadata file: /home/rick/.local/share/ubuntuone/syncdaemon/tritcask/129653302256468.live.tritcask-v1.data

If you don't want to make that info public, we can change the visibility of the bug or you can just send an email to me.

Thanks!

[Roman Yepishev (rye)]

Guillermo, does it look like bug #711211 causing the syncdaemon to restart when connection to the server fails at the initial stage? In this case local rescan is being performed on every restart (obviously) leading to high CPU load.

[Guillermo Gonzalez (verterok)]

Hi Roman,

In this case tritcask is raising an error and syncdaemon is restarted, take a look to the latest attached logs.

Cheers,