From owner-freebsd-net@FreeBSD.ORG Mon Aug 11 19:27:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7C0F6A2 for ; Mon, 11 Aug 2014 19:27:51 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E12C27D1 for ; Mon, 11 Aug 2014 19:27:51 +0000 (UTC) Received: from [192.168.1.200] (p548181A9.dip0.t-ipconnect.de [84.129.129.169]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BBD891C0C069E; Mon, 11 Aug 2014 21:27:46 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: A problem on TCP in High RTT Environment. From: Michael Tuexen In-Reply-To: <7A4120EE-60F3-4D32-89C4-C694B8DFEAE4@netapp.com> Date: Mon, 11 Aug 2014 21:27:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E8A6382-7096-495A-907C-86CE26A163A2@lurchi.franken.de> References: <20140809184232.GF83475@funkthat.com> <8AE1AC56-D52F-4F13-AAA3-BB96042B37DD@lurchi.franken.de> <20140809204500.GG83475@funkthat.com> <3F6BC212-4223-4AAC-8668-A27075DC55C2@lurchi.franken.de> <20140810022350.GI83475@funkthat.com> <20140810033212.GL83475@funkthat.com> <17A804F3-BEA6-46F4-887F-B68750618FD9@netapp.com> <0CF85443-26AC-4931-9D00-3396C18C7690@lurchi.franken.de> <7A4120EE-60F3-4D32-89C4-C694B8DFEAE4@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-net@freebsd.org" , John-Mark Gurney , Niu Zhixiong , Bill Yuan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 19:27:51 -0000 On 11 Aug 2014, at 14:12, Eggert, Lars wrote: > On 2014-8-11, at 9:17, Michael Tuexen = wrote: >> Was there any suspicious output provided by netstat -m when the = problems occur? >=20 > root@laurel:~ # netstat -m > 8186/2179/10365 mbufs in use (current/cache/total) > 8184/1214/9398/2036224 mbuf clusters in use (current/cache/total/max) > 8184/885 mbuf+clusters out of packet secondary zone in use = (current/cache) > 0/5/5/1018111 4k (page size) jumbo clusters in use = (current/cache/total/max) > 0/0/0/301662 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/169685 16k jumbo clusters in use (current/cache/total/max) > 18414K/2992K/21407K bytes allocated to network (current/cache/total) > 544/57/8194 requests for mbufs denied (mbufs/clusters/mbuf+clusters) I guess the above is the problem. The card wants a lot of mbufs... So the problem should go away if you increase the number of = mbufs/clusters, which means no requests are denied and you don't experience any = performance issue. I ran into this on machines having several igb and ixgbe cards, each = wanting a lot of clusters for each of the receive rings per receive queue... Best regards Michael > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile >=20 > root@laurel:~ # uptime > 2:12PM up 37 mins, 3 users, load averages: 0.20, 0.25, 0.15 >=20 > Lars