Public bug reported: Binary package hint: sbackup
When backing up a large directory structure (in my case: ~ 280000 files, probably many directories, ~ 10 GB of data all in all), sbackup seems to get slower and slower while creating the list of files (i.e. creating the fprops file)... It can be seen how the fprops file grows by a few kb every few seconds. After creation of fprops file, actual tar'ing and gzip'ing doesn't show any strange performance (most CPU time goes to gzip, and some goes to I/O wait, as expected). Details: Creating the fprops file took 280 minutes in the end; that means it has handled 17 files per second. At the beginning of backup, I had measured a speed of about 60 files / second. During fprops creation, the HDD led didn't light up often, and top showed that all CPU load was used by the sbackupd process - so the slowdown is apparently not disk bound. Also, when testing backup just with the default config (i.e. backing up the system files) the first run took maybe a minute, and an incremental backup took around 15 seconds... The machine is a Pentium 1 with 400 MHz, with 128 MB RAM, a 8 GB system disk and a 40 GB data disk. This happened with sbackup from Dapper (0.9-1 IIRC) and also with the newest release (0.10.3-0.1). Maybe there is a O(n^2) action in the code? I've seen a line like "if not parent in dirs_in ..." which seems to search for every file name in the list (map?) of known files - so this operation probably gets slower, the more files are added. Is there a way to profile this? ** Affects: sbackup (Ubuntu) Importance: Undecided Status: Unconfirmed -- sbackup is very slow when working on many files https://bugs.launchpad.net/bugs/102577 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs