From owner-freebsd-stable@FreeBSD.ORG Thu Nov 24 16:30:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CAB1106566C for ; Thu, 24 Nov 2011 16:30:42 +0000 (UTC) (envelope-from kerbzo@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id CED208FC08 for ; Thu, 24 Nov 2011 16:30:41 +0000 (UTC) Received: by iakl21 with SMTP id l21so4897551iak.13 for ; Thu, 24 Nov 2011 08:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YkyM799LlESQWYuJQHymOO+biw3UfY9YSGpSK5EHiB0=; b=xp/4qWHNE0OqznwOIudnIUyI3asS0OefHI/NWvKZcBdfQCvjcwc3bQ5A9g5sCDSeNP +59/0yvhMc6gTTRxPHsS8hOxa0o9ivQ5d3fbnzaOYq7BYj6xRv1HhxhrjqTS2wJ2ncXi Bqb9vpewQKsA8INE6Eq+0DEe5rmi381jB6AME= MIME-Version: 1.0 Received: by 10.50.135.40 with SMTP id pp8mr33951008igb.1.1322150872251; Thu, 24 Nov 2011 08:07:52 -0800 (PST) Received: by 10.231.34.68 with HTTP; Thu, 24 Nov 2011 08:07:52 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Nov 2011 17:07:52 +0100 Message-ID: From: kerbzo To: Kris Bauer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 16:30:42 -0000 Hi, I 'm experiencing a similar issue but I don't know if mine could be considered normal behaviour: even if net.inet.tcp.reass.curesegments is set to 1680 and does not icrease, the output of vmstat -z shows a high tcpreass fail value that I don't remember in previous (8-STABLE) builds: ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP [...] socket: 680, 25602, 740, 754, 4345747, 0, 0 unpcb: 240, 25600, 85, 459, 148595, 0, 0 ipq: 56, 819, 0, 378, 16126, 0, 0 udp_inpcb: 392, 25600, 24, 376, 222036, 0, 0 udpcb: 16, 25704, 24, 480, 222036, 0, 0 tcp_inpcb: 392, 25600, 719, 2391, 3958901, 0, 0 tcpcb: 976, 25600, 625, 707, 3958901, 0, 0 tcptw: 72, 5150, 93, 2357, 1486035, 0, 0 syncache: 152, 15375, 2, 398, 1587985, 0, 0 hostcache: 136, 15372, 1490, 4922, 119374, 0, 0 tcpreass: 40, 1680, 1680, 0, 108934,4800302, 0 sackhole: 32, 0, 0, 404, 134750, 0, 0 [...] System is FreeBSD 9.0-PRERELEASE #8 r227705 Bye, On Thu, Nov 24, 2011 at 8:02 AM, Kris Bauer wrot= e: > Hello, > > I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 where t= he > net.inet.tcp.reass.curesegments value is constantly increasing (and not > descreasing when there is nominal traffic with the box). =A0It is causing= tcp > slowdowns as described with kern/155407: > > Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session (fo= r > this socket and any other socket waiting for retransmited packets). After > exhausted net.inet.tcp.reass.maxsegments allocation new entry in tcp_reas= s > failed (for this socket and any other socket waiting for retransmited > packets). > > I have increased the reass.maxsegments value to 16384 to temporarily avoi= d > the problem, but the cursegments number keeps rising and it seems it will > occur again. > > Is this an issue that anyone else has seen? =A0I can provide more informa= tion > if need be. > > Thanks, > Kris > _______________________________________________ > 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" >