Date: Fri, 3 May 2013 13:29:13 -0700 From: "Marc G. Fournier" <scrappy@hub.org> To: Adam McDougall <mcdouga9@egr.msu.edu> Cc: freebsd-fs@freebsd.org Subject: Re: NFS Performance issue against NetApp Message-ID: <A3C236A0-155F-448E-AD26-2B9F55893D54@hub.org> 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 2013-05-02, at 17:39 , Adam McDougall <mcdouga9@egr.msu.edu> wrote: > 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. Unless I've missed something, jboss extracts the war when you do the = deploy, so subsequent restarts just use the extracted files and = shouldn't be slowed down by those writes =85 there are no other temp = files that I'm aware of =85 but, in this case, the problem is that we're = running jboss within a jail'd environment, and the jail is sitting on = the NFS server, so moving pieces of it to local drives isn't = particularly feasible =85
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A3C236A0-155F-448E-AD26-2B9F55893D54>