extremely poor performance

Bug #422610 reported by MFeif on 2009-09-01
This bug affects 11 people
Affects Status Importance Assigned to Milestone
ubuntuone-client (Ubuntu)
John Lenton

Bug Description

Binary package hint: ubuntuone-client

Jaunty 64bit.
UbuntuOne client: 0.93.1+r191

I'm trying out UO as a replacement for Dropbox in part; I've been syncing dotfiles and other sorts of config that I want to keep parallel on several Ubuntu boxes that I use. UO is attractive to me in its focus on Ubuntu (permissions, prolly better support for unix in general) and I'd like to have a good reason to give Canonical some money.

Last night I put about 70M worth of files in, the bulk of which is files from the Firefox Scrapbook plugin. This plugin downloads web pages recursively, including attached media files, to keep an archive. This means that there are many very small files.

UO started sync'ing the files, but very slowly. There were 6000+ to sync, which is a lot. After a few hours, it was about 1000 files in, so I left the machine overnight. This is a very fast machine with 4G of RAM, and a decent broadband connection (¾Mb upload connection). It was taking about 5 seconds per file, according to the simple status update on mouse-click (Updating xxxx of yyyy). No other significant network activity was occurring.

This morning, the sync had simply stopped. I don't know how far it got; there were no messages. The web client said that I had about 19Mb of files; not 70Mb. There were no error messages anywhere.

I put a tiny txt file into the UO folder to get it started sync'ing again, and UO crashed. Minutes later, apport tried to send a report... which ate 2.43G of RAM and of course failed, getting a 500 error from the Launchpad server.

I logged out, logged back in, and UO said "up to date". About 5 minutes later (and some furious hard-drive thrashing), it started sending files again... 5s per file or more.

I'm not sure which particular component of this setup is the problem, which is why I'm being so verbose in this report; sorry. It simply should not take 10hours (well, maybe more!) to send 70M on a ¾Mb connection. Dropbox works quickly and reliably; I set it and forget it, so it's not a matter of net connection or congestion.

James Deibele (jdeibele) wrote :

I'm doing almost the same quantity: 70M worth of data in 7868 (according to the Ubuntu One client) files. Files are being uploaded at the rate of 2 or 3 per hour.

One (maybe unusual) thing that I'm doing: ~/Ubuntu One is a symbolic link to ~/Dropbox

Mark G. Saye (markgsaye) wrote :

MFeif, thanks for your bug report. I'm assigning it to one of the developers to look into. Please could you update your ubuntuone packages, and let us know if the situation has changed at all for you, since there have been several fixes made since your report. You may be interested to check out the "u1sdtool" command line application, in particular the "u1sdtool --current-transfers" option. Run "/usr/bin/u1sdtool -h" in a terminal (Applications -> Accessories -> Terminal) to see the options. Thanks.

Mark G. Saye (markgsaye) on 2009-10-09
Changed in ubuntuone-client (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → John Lenton (chipaca)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers