~85% is user, and the bacula report says compression is off: 21-May 12:22 tardis-sd: Spooling data ... 21-May 12:37 tardis-sd: Job write elapsed time = 00:15:37, Transfer rate = 42.36 M bytes/second 21-May 12:37 tardis-sd: Committing spooled data to Volume "210betatest". Despooling 39,728,405,145 bytes ... 21-May 12:48 tardis-sd: Despooling elapsed time = 00:10:23, Transfer rate = 63.76 M bytes/second 21-May 12:48 tardis-sd: Sending spooled attrs to the Director. Despooling 806,068 bytes ... 21-May 12:48 tardis-dir: Bacula tardis-dir 2.1.10 (18May07): 21-May-2007 12:48:56 Build OS: i686-pc-linux-gnu debian 4.0 JobId: 5 Job: Drakh.2007-05-21_12.22.07 Backup Level: Full Client: "drakh-fd" 2.1.10 (18May07) x86_64-unknown-linux-gnu,debian,4.0 FileSet: "Drakh Set" 2007-05-21 11:44:02 Pool: "Default" (From Job resource) Storage: "Tape0" (From Job resource) Scheduled time: 21-May-2007 12:22:01 Start time: 21-May-2007 12:22:09 End time: 21-May-2007 12:48:56 Elapsed time: 26 mins 47 secs Priority: 10 FD Files Written: 2,685 SD Files Written: 2,685 FD Bytes Written: 39,694,703,129 (39.69 GB) SD Bytes Written: 39,695,139,913 (39.69 GB) Rate: 24701.1 KB/s Software Compression: None VSS: no Encryption: no Volume name(s): 210betatest Volume Session Id: 2 Volume Session Time: 1179762221 Last Volume Bytes: 178,310,522,880 (178.3 GB) Non-fatal FD errors: 0 SD Errors: 0 FD termination status: OK SD termination status: OK Termination: Backup OK
Thanks, Jordan Bill Moran wrote: > On Mon, 21 May 2007 12:49:12 -0400 > Jordan Desroches <[EMAIL PROTECTED]> wrote: > >> I've done a bunch of testing since my last post, and the slowdown >> appears to be CPU usage on the client file daemon (bacula-fd). bacula-fd >> consumes all the cpu resource it can get, and tends to transfers data >> faster (40 MB/s) on to the director on a machine with better CPU, even >> though the disk array on the slower machine (28 MB/s) was faster >> (similar data sets). I'm using MD5 hashes and compression is not turned >> on (also not explicitly turned off, if there is such a command). Is it >> normal for the file daemon to consume 100% of a cpu, or am I doing >> something wrong? > > Any time I've seen high CPU usage on the FD, it's been the result of > compression being turned on and has been solved by either lowering the > aggressiveness of compression or turning it off altogether. > > So my first advice would be to verify whether compression is on or not. > Check your job defaults. > > Is this a POSIX system? Run top(1) and see where the CPU time is going: > user? system? io? > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
