On 6/30/05, Dragan Cvetkovic <[EMAIL PROTECTED]> wrote: > On Wed, 29 Jun 2005, Rich Teer wrote: > > > On Wed, 29 Jun 2005, Dragan Cvetkovic wrote: > > > >> after starting truss -afe -o /dev/null -p 2079, it managed to copy some > >> 10MB of data in one minute or so, but after killing truss, it takes 5 > >> minutes to copy 2MB of data. > >> > >> What is going on here? How can I find that out? > > > > <Bryan Cantrill> > > This sounds like a job DTrace! [FX: sounds of feverish typing] > > </Bryan Cantrill> > > > > :-) > > > > Yes, I know I should use them, and I wish I know how to do it. Therefore > dtrace-discuss cc-ed :-) > > To recapitulate and simplify a bit: I want to copy via NFS a large file > (Solaris Express b17 first iso, some 300MB). My NFS server is a x86 machine > running onnv16, my NFS client is a SPARC machine (SunBlade 100) running > Solaris 10 GA and up to date with patches. They are all on the local > network and e.g. ftp shows the transfer speed of some 8-9MB/s. However, if > I use cp to do the same, it goes extremelly slowly: 1 or 2MB per minute or > even less! > > When I truss nfsd on the server, I see that it does a lot of sleeping, when > I trace cp on the client, it does a lot of write() + mmap() of 8MB chunks > and some idling in between. I have tried experimenting with switching off > NFS4 and some other stuff (as I am not completely sure that our NFS4 setup > is completely OK), but didn't help. > > Where is the cp source, btw? > > 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!)! >
Those symptoms immediately make me think duplex mismatch. -- Alex Kiernan _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
