On Mon, Dec 14, 2015 at 09:12:06PM +0000, Lewis, Dave wrote: > Hi, > > Thanks. I ran it again with attribute spooling. That sped up the backup of > data to the disk pool - instead of 6 hours it took less than 2 - but writing > the file metadata afterwards took nearly 6 hours. > > 12-Dec 18:24 jubjub-sd JobId 583: Job write elapsed time = 01:51:55, Transfer > rate = 703.0 K Bytes/second > 12-Dec 18:24 jubjub-sd JobId 583: Sending spooled attrs to the Director. > Despooling 120,266,153 bytes ... > 13-Dec 00:11 jubjub-dir JobId 583: Bacula jubjub-dir 5.2.6 (21Feb12): > Elapsed time: 7 hours 39 mins 13 secs > FD Files Written: 391,552 > SD Files Written: 391,552 > FD Bytes Written: 4,486,007,552 (4.486 GB) > SD Bytes Written: 4,720,742,979 (4.720 GB) > Rate: 162.8 KB/s > Software Compression: None > Encryption: yes > Accurate: no > > So the transfer rate increased from about 200 KB/s to about 700 KB/s, but the > total elapsed time increased. >
Hi Dave, how large is your catalog database? How many entries do you have in your File table, for instance? Attribute despooling should be much faster than what you're seeing even on SATA disks. I guess your mysql setup could do with some optimization w/r to buffer pool size (I hope you're using InnoDB as the backend db engine) and lock / write strategies. As your DB runs on the director machine, I'd assign at last 50% of the available RAM if your catalog has a similar size. A quick google search came up with the following query to determine your catalog db size: SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP BY table_schema; All the best, Uwe ------------------------------------------------------------------------------ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
