Date: Thu, 2 May 2013 21:53:18 -0500 From: Chuck Burns <break19@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: NFS Performance issue against NetApp Message-ID: <CAE2yjrr9pLEqn9E8NuuzHz3fd4Ui5VvTahWR1TAM4ZdH3m8%2BKg@mail.gmail.com> In-Reply-To: <5183074B.5090004@egr.msu.edu> 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> <5183074B.5090004@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 2, 2013 7:48 PM, "Adam McDougall" <mcdouga9@egr.msu.edu> wrote: > > 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 =85 there ar= e *so* many other variables involved =85 it could be something with the netwo= rk stack =85 it could be something with the scheduler =85 it could be =85 hell= , it could be like the guy states in that blog posting ( http://antibsd.wordpress.com/) and be the compiler changes =85 >>> >>> I'm just watching interestedly from the sidelines, and I hesitate to as= k >>> 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 =85 >> >> Linux =85=85. 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=3D1 =85 279207ms, 273970ms >> FreeBSD, nfs, vfs.nfs.prime_access_cache=3D0 =85 279254ms, 274667ms >> FreeBSD, oldnfs, vfs.nfs.prime_access_cache=3D0 =85 244955ms, 243280ms >> FreeBSD, oldnfs, vfs.nfs.prime_access_cache =3D1 =85 242014ms, 242393ms >> >> Default for vfs.nfs.prime_access_cache appears to be 0 =85 >> >> > 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. > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" Here is another possibility. Most linux distros put /tmp on tmpfs, whereas FreeBSD by default uses actual disk space.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE2yjrr9pLEqn9E8NuuzHz3fd4Ui5VvTahWR1TAM4ZdH3m8%2BKg>