From owner-freebsd-fs@FreeBSD.ORG Fri May 3 00:48:16 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0BC42B75 for ; Fri, 3 May 2013 00:48:16 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (dauterive.egr.msu.edu [35.9.37.168]) by mx1.freebsd.org (Postfix) with ESMTP id DA2741EB1 for ; Fri, 3 May 2013 00:48:15 +0000 (UTC) Received: from dauterive (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 50F93427F2 for ; Thu, 2 May 2013 20:39:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by dauterive (dauterive.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcbaUielxrKN for ; Thu, 2 May 2013 20:39:25 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <5183074B.5090004@egr.msu.edu> Date: Thu, 02 May 2013 14:39:39 -1000 From: Adam McDougall User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: NFS Performance issue against NetApp 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> In-Reply-To: <420165EE-BBBF-4E97-B476-58FFE55A52AA@hub.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 00:48:16 -0000 On 5/2/2013 1:43 PM, Marc G. Fournier wrote: > On 2013-05-02, at 15:18 , Graham Allan 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.