What drives are you using and how many ?
IMO you really need to either back up several GB of large ( say >300 MB)
files or use bigasm to check what throughput is possible, I'd guess that
you are being clobbered by the small file syndrome for which there is
little you can do. One other possibility might be the Solaris DNLC cache do
a vmstat -s adn check that bit "(cache hits XX%)" is greater than 95% if
not then increase the cache (and inode cache) sizes.
On Tue, 27 Aug 2002 15:37:06 +1000, Stuart Lamble
<Stuart.Lamble AT ITS.MONASH.EDU DOT AU> wrote:
>Hey ho.
>
>We have a Sun Ultra 10 hooked up to a fibre channel hardware RAID
>controller, with a 522 GB RAID 5 partition. This partition is
>currently holding 39.4 GB of data, in 2,410,991 files. (so about
>17 kB per file on average.) UFS filesystem, with filesystem logging
>turned on (we really, really, _really_ don't want to be fscking
>over 500 GB of data when the filesystem is full and the system goes
>down!)
>
>For some reason, Networker is taking an exorbitantly long amount of
>time to backup this filesystem. I've seen it sitting idle for
>extended periods of time (on a full backup), and when it finally
>does start doing things, it'll be at tens or hundreds of kilobytes
>per second. This on a system which can quite happily transfer a
>100 MB file over ssh in 30 seconds or so (so no, it isn't a duplex
>issue. The network connection is a 100 Mbps full duplex Ethernet.)
Ok it is slow but how long do you expect backup or restore to take with 500
GB you'll be lucky to get 9 MB/s through your Ethernet so you would expect
a minimum backup time of 16 hours and a restore of of a day or more.
>
>Tarring up a 100 MB directory tree is also reasonably fast --
>certainly faster than Networker seems to be in backing up that amount
>of data. I have seen Networker manage peak transfer rates of around
>3 MB/s, but that is rarely sustained for more than a few minutes, if
>that.
>
>There are things that I can do: I could, for example, reconfigure the
>RAID set to have a 16 kB "chunk size" (instead of its current 128 kB),
>but I'm not certain if that will have the desired effect, especially
>given that tar seems to be reasonably fast. This backup is taking ages
>as it is; once the filesystem grows in usage, I can only see things
>getting worse.
The read speed from the RAID is unlikely to be the problem could you use
uasm to move the 39 GB of data to another disk on the same system this
would give you an idea of how long it takes to read the data.
>Networker 6.1.2 on both the server and the client. The server's on an
>ATM hookup, and other clients don't exhibit this problem in any event,
>so it doesn't seem to be a network issue. Any hints, pointers, or
>suggestions would be very gratefully received.
What is the specs for the server, is it doing other backups through the
same network connection whilst this big client is going slow?
Not sure with 6.1.2 but 6.1.1 Sun nwadmin GUI consistently under reports
speeds by 25% compared to iostat.
>
>Thanks,
>
>Stuart.
>
>PS: I would have searched the archives, but they seem to be down at
>the moment. Am I simply looking at the wrong place? --
>http://listserv.temple.edu/archives/networker.html, but that goes to
>May 2002 (from March 2000) and the files appear to be not there
>("error 2" -- ENOENT -- is a pretty clear indication that the file
>the cgi script is trying to open isn't there...) Cheers.
>
>--
>Note: To sign off this list, send a "signoff" command via email
>to listserv AT listmail.temple DOT edu or visit the list's Web site at
>http://listmail.temple.edu/archives/networker.html where you can
>also view and post messages to the list.
>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
