On Wed, Dragan Cvetkovic wrote: > On Thu, 30 Jun 2005, Gavin Maltby wrote: > >Hi Dragan, > > Hi Gavin, > > > >On 06/30/05 00:00, Dragan Cvetkovic wrote: > >[cut] > >>Where is the cp source, btw? > > > >usr/src/cmd/mv - cp and mv have common source. > > Ah, that explains it. > > > > >>Another example of slow transfer: copying these 4 isos to our install > >>server (using setup_install_server + add_to_install_server) took the whole > >>day (some 5 to 6 hours!)! > >> > >>How do I start debugging this problem? Hints are more than welcome. > > > >There was a fix around a year ago to cp performance - 5015406. > >Basically all the fancy mmap and VM advice that our copy was doing > >had so much VM overhead that a brute-force "read buffer, write buffer" > >approach was faster! So that should have eliminated the traditional cp > >performance problems. Before diving into cp/mv source try some > >copies using dd in both direction - nfs client to server and server > >to client - using a few block sizes. That could eliminate or > >confirm cp as a suspect - my guess is it will eliminate it. > > > > OK. See below. > > > >Are you copying from a client local f/s to server via nfs, > >from server via nfs to local client f/s, or one nfs mount > >to another? By way of a baseline, how long does > >a mkfile 300m take when run on the nfs server in the > >shared directory? > > I am copying to a clients f/s from server's fs via nfs. I was doing both > using /net/server/shared/file/system and mounting it via NFS on a client. > > Here is the mkfile experiment: > > server# share -F nfs -o anon=0 /var/tmp/se > server# pwd > /var/tmp/se > server# time mkfile 300m foo > > real 0m8.613s > user 0m0.072s > sys 0m5.080s > > On the client: > > client# pwd > /net/server/var/tmp/se > client# time mkfile 300m bar > > real 0m35.535s > user 0m0.140s > sys 0m4.053s > > Here is the dd time > > client# pwd > /net/server/var/tmp/se > client# time dd if=sol-nv-b17-x86-v1-iso.zip > of=/var/tmp/sol-nv-b17-x86-v1-iso.zip > > (pressed ^c, it was taking too long) > > ^C104736+0 records in > 104736+0 records out > > real 3m23.931s > user 0m0.997s > sys 0m4.701s > > i.e. in 3m 24sec it only copied 51MB of data (256KB/s). > > and with larger block size: > > client# time dd if=sol-nv-b17-x86-v1-iso.zip > of=/var/tmp/sol-nv-b17-x86-v1-iso.zip bs=32k > > ^C > 59+0 records in > 59+0 records out > > real 3m43.381s > user 0m0.005s > sys 0m0.117s > > so, it's even worse (1.8MB in 3m 43sec!). > > It seems that the transfer start quickly, but after some time it gets > slower and slower.
(note: in the future the [EMAIL PROTECTED] list may be a better target for these discussions). Without the aid of a snoop trace of this interaction, I am going to guess that there may be something going on with the x86 server. The NFS client, especially in Solaris 10, is aggressive about read-aheads and the read sizes it generates are larger than ftp would generate. So the classic problem is usually one where the client/server is unable to handle the back-to-back network traffic. To confirm something like this, a snoop trace at both the client and server would be needed; if such a snoop trace is generated, a pointer to it would be best or you can send it to me directly. Spencer _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
