On 08/02/12 02:00, Vit Hrachovy wrote:
On 08/02/12 00:53, Mike Gerdts wrote:
Is it known and/or expected that nfs:/// repos perform *much* worse than
http:// repos?
As an example, I have two images that I started to update at the same
time. The repo is in SCA, the images are in BRM. I thought that NFS may
be the cause of the horrible performance so I hit ^C in one of them.
Then I started up a couple pkg.depotd processes for the on-nightly and
on-extra repos in SCA, changed the publisher settings on one of the
images to use http URIs, and restarted the operation (pkg change-variant
variant.debug.osnet=true).
Any idea what's behind this?
Hi Mike,
I don't know how far SCA labs are from BRM, but IPS makes a lot of tiny FS
operations instead of one big file transfer.
In case of traversing NFS across misconfigured routers or across vast
landscapes the stat() operations on NFS take very long time and as IPS fires
lots of such operations, this could explain horrible performance.
On the other hand if You have machine serving repo over NFS in the same subnet
and in the same LAN like machine being installed, NFS should have better
performance.
Regards
The two machines in question are ~37 ms apart. Aside from pkg over NFS, I've
noticed no significant network or NFS problems. My home directory is also
mounted from SCA and it's performed as well as you would expect when you are 37
ms away from your storage. The same repo on the same host was used for both
http and nfs publisher configuration so that rules out network issues (assuming
there's not some complicated and slow packet filtering for NFS that doesn't
exist for http). Also, if it had to do with a warm vs. cold fs cache on the
server side, that would suggest that the http operation would have gone fast
until it caught up with the NFS operation, then they would finish at about the
same time. That certainly wasn't the case.
Does the file:/// path of pkg do more stat() requests than the http:// path does
HEAD requests? If so, why? If not, perhaps there's something in the NFS stack
that is suboptimal for this type of workload.
At least for the case of high latency file:/// repos, it would seem as though
there would be a lot of benefit in having multiple threads.
httphost# pkg history -n 1 -l | grep Time
Start Time: 2012-08-01T16:29:17
End Time: 2012-08-01T16:35:09
Total Time: 0:05:52
nfshost# pkg history -n 1 -l | grep Time
Start Time: 2012-08-01T15:23:50
End Time: 2012-08-01T15:54:27
Total Time: 0:30:37
Those times really do overlap but the servers are set for different time zones:
16:29 - 16:35 MDT vs. 15:23 - 15:54 PDT.
--
Mike Gerdts
Solaris Core OS / Zones http://blogs.oracle.com/zoneszone/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
