From owner-freebsd-stable@FreeBSD.ORG Sat May 2 19:28:36 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DA50145 for ; Sat, 2 May 2015 19:28:36 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 474871B65 for ; Sat, 2 May 2015 19:28:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CsBABlJEVV/95baINcg19cBYMYwkiBTAqFNk4CggsTAQEBAQEBAYEKhCABAQEDAQEBASAEJyALGxgCAg0ZAikBCSYGCAcEARwEiAIIDbJdkmUBAQEBBgEBAQEBAQEbgSGKGIQzAQEFFzQHgmiBRQWLGYsFhBCDVT2GB442I4IHHIFtIjEHgQQ5gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,356,1427774400"; d="scan'208";a="207745642" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 02 May 2015 15:28:34 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7FB21B4221; Sat, 2 May 2015 15:28:34 -0400 (EDT) Date: Sat, 2 May 2015 15:28:34 -0400 (EDT) From: Rick Macklem To: "Frank de Bot (lists)" Cc: freebsd-stable@FreeBSD.org Message-ID: <1031959302.30289198.1430594914473.JavaMail.root@uoguelph.ca> In-Reply-To: <55451961.5070708@searchy.net> Subject: Re: kernel process [nfscl] high cpu MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 19:28:36 -0000 Frank de Bot wrote: > Hi, > > On a 10.1-RELEASE-p9 server I have several NFS mounts used for a > jail. > Because it's a server only to test, there is a low load. But the > [nfscl] > process is hogging a CPU after a while. This happens pretty fast, > within > 1 or 2 days. I'm noticing the high CPU of the process when I want to > do > some test after a little while (those 1 or 2 days). > > My jail.conf look like: > > exec.start = "/bin/sh /etc/rc"; > exec.stop = "/bin/sh /etc/rc.shutdown"; > exec.clean; > mount.devfs; > exec.consolelog = "/var/log/jail.$name.log"; > #mount.fstab = "/usr/local/etc/jail.fstab.$name"; > > test01 { > host.hostname = "test01_hosting"; > ip4.addr = somepublicaddress; > ip4.addr += someprivateaddress; > > mount = "10.13.37.2:/tank/hostingbase /opt/jails/test01 > nfs nfsv4,minorversion=1,pnfs,ro,noatime 0 0"; > mount += "10.13.37.2:/tank/hosting/test > /opt/jails/test01/opt nfs nfsv4,minorversion=1,pnfs,noatime > 0 0"; > > path = "/opt/jails/test01"; > } > > Last test was with NFS 4.1, I also worked with NFS 4.(0) with the > same > result. In the readonly nfs share there are symbolic links point to > the > read-write share for logging, storing .run files, etc. When I monitor > my > network interface with tcpdump, there is little nfs traffic, only > when I > do try to access the shares there is activity. > > What is causing nfscl to run around in circles, hogging the CPU (it > makes the system slow to respond too) or how can I found out what's > the > cause? > Well, the nfscl does server->client RPCs referred to as callbacks. I have no idea what the implications of running it in a jail is, but I'd guess that these server->client RPCs get blocked somehow, etc... (The NFSv4.0 mechanism requires a separate IP address that the server can connect to on the client. For NFSv4.1, it should use the same TCP connection as is used for the client->server RPCs. The latter seems like it should work, but there is probably some glitch.) ** Just run without the nfscl daemon (it is only needed for delegations or pNFS). Since a big Netapp filer (the cluster ones) are about the only servers that currently support pNFS (no FreeBSD server support yet), you can probably forget about pNFS (I'd get rid of the "pnfs" mount option). It also won't work unless this callback path is working. As for delegations, they aren't required for NFSv4.[0-1] to work correctly and aren't enabled by default on the FreeBSD server. --> Running without the nfscl daemon will just ensure no delegations are issued, even if enabled on the server. rick > > Regards, > > Frank de Bot > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" >