From: Dragan K. <dk...@ly...> - 2007-11-12 01:10:29
|
Dump isn't the fastest backup software, but if you <br>get such ridiculously low transfer rates, there must <br>be something wrong with your hardware. I had a similar <br>problem. The "tar" could do something like really <br>respectable transfer rates and "dump" reported such <br>ridiculous rates as you quote. <br> <br>Why don't you try something else in the way of e2fs? <br>Try an "fsck". Mine needed close to 6 hours to <br>complete a 290 GB 15-disks RAID-6. <br> <br>After I replaced the controller it was back to <br>minutes and "dump" was at about 50-60 MB/s. <br> <br> <br>Date: Wed, 07 Nov 2007 13:30:12 -0800 <br>From: Todd and Margo Chester <Tod...@ve...> <br>Subject: Re: [Dump-users] slowwwwwww <br>To: James Roth <jam...@gm...> <br>Cc: Stelian Pop <st...@po...>, dum...@li... <br>Message-ID: <473...@ve...> <br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed <br> <br>> On Nov 6, 2007 7:59 AM, Stelian Pop <st...@po...> wrote: <br>>> Le dimanche 04 novembre 2007 ? 15:11 -0800, Todd and Margo Chester a <br>>> ?crit : <br>>>> 2.6.18-8.1.8.el5 <br>>>> <br>>>> Hi All, <br>>> Hi, <br>>>> After I wiped my hard drives clean of CentOS 4.4 <br>>>> (RHEL 4.4 clone) and installed CentOS 5 (RHEL 5), <br>>>> I noticed that everything was slower. Especially, <br>>>> dump, which was 3.5 times slower. <br>>>> <br>>>> So, I did some tests from my install CD/DVD's in "rescue mode" <br>>>> and the System Rescue CD from http://www.sysresccd.org. <br>>>> I used the same backup script (dump) that I use in normal <br>>>> boot mode. I stopped the backup after dump gave the first <br>>>> estimate of time: <br>>>> <br>>>> "dump" CentOS4.4 (Kernel 2.6.9-42.EL) install CD in rescue mode: <br>>>> transfer rate 8468 KB/s, estimated finish 2:09 <br>>>> <br>>>> "dump" CentOS5 (Kernel 2.6.18) install DVD in rescue mode: <br>>>> transfer rate 4422 KB/s, estimated finish 4:10 <br>>>> <br>>>> "dump" System Rescue CD (Kernel 2.6.22.9): <br>>>> transfer rate 4370 KB/s, estimated finish 4:15 <br>>>> <br>>>> Has anyone else seen this? If so, were you able to fix it? <br>>> I guess you'll have to do some cross-tests yourself... The problem could <br>>> be related to the filesystem read, the output write, or dump itself. <br>>> <br>>> Try dumping to /dev/null, and compare the speeds on both OSes. <br>>> <br>>> Try using the same dump version on both OSes to rule out dump problems. <br>>> <br>>> If the two tests above do not give any indication, it is probably a <br>>> kernel problem (either in the filesystem driver or the disk driver). <br>>> Maybe running some filesystem performance tests (bonnie etc) will show <br>>> the problem. <br>>> <br>>> Stelian. <br>>> -- <br>>> Stelian Pop <st...@po...> <br>>> <br> <br>James Roth wrote: <br>> Did you use hdparm to check / enable DMA on the hard drive? What are <br>> the drives and how are they configured? <br>> <br> <br>Hi Stelian and James, <br> <br>I read through the man page for hdparm and could not figure <br>out how to read my DMA settings with hdparam. :'( <br>How would I test this? <br> <br>I take it "bonnie++" will mean nothing to any of us <br>until I have data from a CentOS5 and a CentOS4.5 <br>machine to compare with. (I will be at the <br>4.5 customers site next Tuesday and will test <br>him for a comparison.) <br> <br>Also, the problem occurs when backing up to tape <br>as well as hard drive. Of the four computers below, <br>all are using RAID controllers as the source of the <br>data to be backed up. <br> <br>And, it is not just dump that is slow, everything <br>is slow. dump is just the easiest to get number <br>from. <br> <br>Basically, I have three identical computers in play: two <br>with the problem and one without (it is running Cent OS 4.5). <br>This is extensively documented, including fresh dmesg's, on <br> <br>http://bugs.centos.org/view.php?id=2382 <br> <br>Also, there is another party having the same problem <br>with a different processor, motherboard, chipset, <br>RAID controller and tape drive. He is documented over at <br> <br>http://www.centos.org/modules/newbb/viewtopic.php?topic_id=10659&start=0#forumpost34209 <br> <br>To summarize my three computers: <br> <br>My CentOS5: uname -r 2.6.18-8.1.14.el5 <br>My (and my customer's) motherboards (3) are the Supermicro x7dal-e: <br> <br>http://www.supermicro.com/products/motherboard/Xeon1333/5000X/X7DAL-E.cfm <br> <br>The LSI Megaraid cards are the SATA-150-4 and SATA 300-4XLP: <br> <br>http://www.lsi.com/storage_home/products_home/internal_raid/megaraid_sata/megaraid_sata_1504/index.html <br> <br> <br>http://www.lsi.com/storage_home/products_home/internal_raid/megaraid_sata/megaraid_sata_300_4xlp/index.html <br> <br> <br>The tape drive is a Exabyte VXA-3. <br>http://exabyte.com/products/products/get_products.cfm?prod_id=641 <br>run from an Adaptec 19160 SCSI-U160 LVDS Controller <br> <br>The backup hard drive is an external SATA drive (eSATA) <br> <br>Computer A: VXA-3, CentOS 5 , LSI SATA 300-4XLP <br> <br>DUMP: 17815320 blocks (17397.77MB) on 1 volume(s) <br>DUMP: finished in 6473 seconds, throughput 2,752 kBytes/sec <br> <br>DUMP: 5038380 blocks (4920.29MB) on 1 volume(s) <br>DUMP: finished in 1872 seconds, throughput 2,691 kBytes/sec <br>Note: 3 times slower than Computer B <br> <br>Computer B: VXA-3, CentOS 4.5 , LSI SATA-150-4 <br> <br>DUMP: 35933440 blocks (35091.25MB) on 1 volume(s) <br>DUMP: finished in 4396 seconds, throughput 8,174 kBytes/sec <br> <br>DUMP: 27096640 blocks (26461.56MB) on 1 volume(s) <br>DUMP: finished in 3532 seconds, throughput 7,671 kBytes/sec <br> <br> <br>Computer C: eSATA, CentOS 4.4 & 5 , LSI SATA-150-4 <br> <br>CentOS 4.4, 1:05 hours, approx 52 GB backup file 13,333 kBytes/sec <br>CentOS 5.0, 3:16 hours, approx 43 GB backup file 3,656 kBytes/sec <br>Note: 3.6 times slower <br> <br> <br>Computer C: misc speed tests <br> <br>cp winxp.hdd /dev/null (7.7 GB), HDD=LSI, Cent 5: 1:44 min, <br>Cent OS 4.4: 1:43 min <br>cp estat.hdd /dev/null (7.7 GB), HDD=eSata, Cent 5: 3:08 min, <br>Cent OS 4.4: 3:07 min <br> <br>cp winxp.hdd eraseme (7.7 GB), HDD=LSI, Cent 5: 4:50 min, <br>Cent OS 4.4: 4:48 min <br>cp estat.hdd eraseme (7.7 GB), HDD=eSata, Cent 5: 7:22 min, <br>Cent OS 4.4: 6:54 min <br> <br>Parallels' start up of winxp, HDD=LSI, 44 sec <br>startup of Acrobat 8 Pro: 1st time: 5 sec; 2nd time: 2 sec <br> <br>Parallels' start up of eSata, HDD=eSata, 38 sec <br>startup of Acrobat 8 Pro: 1st time: 7 sec; 2nd time: 1 sec <br> <br> <br>The [forth] computer that the other reporter is using <br>(cut and paste from the CentOS posting): <br> <br>MB Tyan S2892 <br>2x3ware9508 Raid Controlles 16x300Gb SATA drives. <br>1xAIC7902W onboard controller for connect external SCSI devices. <br>2xAXUS Brownie BR1600U3P SCSI Ultra 160 device with <br>16x250Gb IDE drives in each. <br>1xHP Storage Works Ultrium 460 LTO-2 Tape drive <br>1xQuantum LTO-2 Tape Drive <br>1xHP Storage Works Ultrium 920 LTO-3 Tape drive <br> <br>For backup we are use tapes in these Tape drives. <br> <br>As you can see this configuration use RAID massives <br>but not all of them on RAID cards. Some of these <br>RAIDs are on the RAID Storages. <br> <br>Now I cannot represent adequate information about <br>slower but can write some data for analises. <br>We write on tape different information in few <br>sessions and this count is different but we can see <br>from logs time of start, count of sessions, size of <br>total writed data. <br> <br>RHEL3: <br>Start - End : Size : Sessions <br>2007/07/23-13:07:01 - 2007/07/23-16:40:30 : 115.737 GB. : 5 <br>2007/07/23-13:07:36 - 2007/07/23-16:52:54 : 163.738 GB. : 8 <br>2007/07/25-09:50:42 - 2007/07/25-12:26:21 : 190.159 GB. : 8 <br>2007/07/27-09:20:40 - 2007/07/27-10:44:21 : 115.603 GB. : 7 <br>2007/07/30-09:49:18 - 2007/07/30-12:10:03 : 182.304 GB. : 10 <br> <br>CentOS 5: <br>2007/10/05-16:16:06 - 2007/10/06-16:32:30 : 98.534 GB. : 4 <br>2007/10/05-16:26:00 - 2007/10/08-16:37:49 : 100.837 GB. : 2 <br>2007/10/08-16:34:40 - 2007/10/09-17:12:23 : 176.883 GB. : 9 <br>2007/10/08-16:41:36 - 2007/10/09-05:17:06 : 100.837 GB. : 4 <br>2007/10/09-16:48:48 - 2007/10/09-22:22:14 : 73.3732 GB. : 4 |