Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 02 May 2013 14:39:39 -1000
From:      Adam McDougall <mcdouga9@egr.msu.edu>
To:        freebsd-fs@freebsd.org
Subject:   Re: NFS Performance issue against NetApp
Message-ID:  <5183074B.5090004@egr.msu.edu>
In-Reply-To: <420165EE-BBBF-4E97-B476-58FFE55A52AA@hub.org>
References:  <834305228.13772274.1367527941142.JavaMail.root@k-state.edu> <75CB6F1E-385D-4E51-876E-7BB8D7140263@hub.org> <20130502221857.GJ32659@physics.umn.edu> <420165EE-BBBF-4E97-B476-58FFE55A52AA@hub.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 5/2/2013 1:43 PM, Marc G. Fournier wrote:
> On 2013-05-02, at 15:18 , Graham Allan <allan@physics.umn.edu> wrote:
>
>> On Thu, May 02, 2013 at 02:05:38PM -0700, Marc G. Fournier wrote:
>>> The thing is, I'm not convinced it is a NFS related issue … there are *so* many other variables involved … it could be something with the network stack … it could be something with the scheduler … it could be … hell, it could be like the guy states in that blog posting (http://antibsd.wordpress.com/) and be the compiler changes …
>> I'm just watching interestedly from the sidelines, and I hesitate to ask
>> because it seems too obvious - maybe I missed something - but have you
>> run both tests (Linux and FreeBSD) purely with local disk, to get a
>> baseline independent of NFS?
> Hadn't thought to do so with Linux, but …
>
> Linux ……. 20732ms, 20117ms, 20935ms, 20130ms, 20560ms
> FreeBSD .. 28996ms, 24794ms, 24702ms, 23311ms, 24153ms
>
> In the case of the following, I umount the file system, change the settings, mount and then run two runs:
>
> FreeBSD, nfs, vfs.nfs.prime_access_cache=1 …  279207ms, 273970ms
> FreeBSD, nfs, vfs.nfs.prime_access_cache=0 … 279254ms, 274667ms
> FreeBSD, oldnfs, vfs.nfs.prime_access_cache=0 … 244955ms, 243280ms
> FreeBSD, oldnfs, vfs.nfs.prime_access_cache =1 … 242014ms, 242393ms
>
> Default for vfs.nfs.prime_access_cache appears to be 0 …
>
>
My understanding of jboss is it unpacks your war files (or whatever) to 
a temp deploy dir but essentially tries to run everything from memory.  
If you replaced a war file, it would usually undeploy and redeploy.  Is 
your jboss extracting the archives to an NFS dir or can you reconfigure 
or symlink it to extract to a local temp dir when starting up?  I can't 
imagine offhand why it might be useful to store the temp dir on NFS.  I 
would think most of the writes at startup would be to temp files that 
would be of no use after the jboss java process is stopped.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5183074B.5090004>