On 10/8/07, Hendrik Friedel <[EMAIL PROTECTED]> wrote: > Ok, what I did now was a backup of localhost. Here, the network cannot be > the bottleneck, and I can check the rest with vmstat, too. By the way: The > Pool-Disk is dedicated an not the source disk for the backup. > > Here's the vmstat. I hope it's readable. > procs ---------memory------ ---swap-- -----io--- -system-- ----cpu-- > r b swpd free buff cache si so bi bo in cs us sy id wa > 1 3 2816 6308 135036 228608 0 0 527 583 3027 4872 11 11 0 77 > 0 3 2816 6236 134420 229588 0 0 779 281 2946 4755 18 12 0 70 > 0 4 2816 5532 134820 229848 0 0 436 333 3906 4505 8 19 0 73
Here your system is primarily waiting on disk, see the high IO wait time of ~70%? Also see the low bi/bo rates? That indicates that the disks are seeking all over the place. You mentioned that one of the disks is running xfs. You can check the fragmentation level by running: xfs_db -c frag -r /dev/hdXX If the fragmentation level is over 10%, it's worth defragging, just run xfs_fsr which will defrag all mounted xfs filesystems for 2 hours. It's not a bad idea to run that periodically if you have xfs partitions. I seem to remember reiserfs having performance issues after some time, especially if you happen to let the partition get too full. How full are your partitions? You should also check that each disk is running full speed by running hdparm -tT /dev/hdX. You should be seeing at least 30MB/s, probably 40-50MB+. -Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ BackupPC-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
