From owner-freebsd-stable@freebsd.org Mon Sep 26 11:57:13 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68186BEBB9F for ; Mon, 26 Sep 2016 11:57:13 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 077DB7CE for ; Mon, 26 Sep 2016 11:57:12 +0000 (UTC) (envelope-from julien.charbon@gmail.com) Received: by mail-wm0-f46.google.com with SMTP id 197so23858766wmk.1 for ; Mon, 26 Sep 2016 04:57:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+2oBuXLjAwTGCS+Y03rMna+RxwWPtmhg3/m6RefGd30=; b=jLHrbRPgcQB+QOZX7FYWIK+y6MU7fxc15yVOCzEEv74pfHerABjmRbsB0+dWACDYtB ZX05qns1TXHEpAgFCyymOK0SxpkfayVDbS1SUHPfFK4gC5hgErB7G/IZugxsu0lhG1LE 9HGhlcmYzX1xMg1S/gAnN1zBoOwI2RRmP8PRGaGD/SKzp/AGfMm5raceOk425esUMaSE +CRN5uPgZ8BIYetnxmmBz9UDDNQTksevsx0w5bq78WtGuyuvEm6SXt+5Rv41jnjZl8Lu ZmHLHe3y8FBCuhSrlJAZxsnyAjQkf0s/E9h08Wpqfz3C1BptmDu3XagGgbbRI82sVfCd Jasw== X-Gm-Message-State: AA6/9RlOmjToZTSwwtEEceBUiLJygS0rtp2Q6I5l7Jfs0J91fabqtfzewxH23mB9g5GynA== X-Received: by 10.28.102.6 with SMTP id a6mr13305987wmc.97.1474891025405; Mon, 26 Sep 2016 04:57:05 -0700 (PDT) Received: from [10.100.64.20] ([217.30.88.44]) by smtp.gmail.com with ESMTPSA id n7sm10864508wmf.18.2016.09.26.04.57.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Sep 2016 04:57:04 -0700 (PDT) Subject: Re: 11.0 stuck on high network load To: Slawa Olhovchenkov References: <20160916183053.GL9397@strugglingcoder.info> <20160916190330.GG2840@zxy.spb.ru> <78cbcdc9-f565-1046-c157-2ddd8fcccc62@freebsd.org> <20160919204328.GN2840@zxy.spb.ru> <8ba75d6e-4f01-895e-0aed-53c6c6692cb9@freebsd.org> <20160920202633.GQ2840@zxy.spb.ru> <20160921195155.GW2840@zxy.spb.ru> <20160923200143.GG2840@zxy.spb.ru> <20160925124626.GI2840@zxy.spb.ru> Cc: Konstantin Belousov , freebsd-stable@FreeBSD.org, hiren panchasara From: Julien Charbon Message-ID: <064be3ae-8df9-fa22-06ab-346af024afd3@freebsd.org> Date: Mon, 26 Sep 2016 13:57:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20160925124626.GI2840@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 11:57:13 -0000 Hi Slawa, On 9/25/16 2:46 PM, Slawa Olhovchenkov wrote: > On Fri, Sep 23, 2016 at 11:01:43PM +0300, Slawa Olhovchenkov wrote: >> On Wed, Sep 21, 2016 at 11:25:18PM +0200, Julien Charbon wrote: >>> >>> On 9/21/16 9:51 PM, Slawa Olhovchenkov wrote: >>>> On Wed, Sep 21, 2016 at 09:11:24AM +0200, Julien Charbon wrote: >>>>> You can also use Dtrace and lockstat (especially with the lockstat -s >>>>> option): >>>>> >>>>> https://wiki.freebsd.org/DTrace/One-Liners#Kernel_Locks >>>>> https://www.freebsd.org/cgi/man.cgi?query=lockstat&manpath=FreeBSD+11.0-RELEASE >>>>> >>>>> But I am less familiar with Dtrace/lockstat tools. >>>> >>>> I am still use old kernel and got lockdown again. >>>> Try using lockstat (I am save more output), interesting may be next: >>>> >>>> R/W writer spin on writer: 190019 events in 1.070 seconds (177571 events/sec) >>>> >>>> ------------------------------------------------------------------------------- >>>> Count indv cuml rcnt nsec Lock Caller >>>> 140839 74% 74% 0.00 24659 tcpinp tcp_tw_2msl_scan+0xc6 >>>> >>>> nsec ------ Time Distribution ------ count Stack >>>> 4096 | 913 tcp_twstart+0xa3 >>>> 8192 |@@@@@@@@@@@@ 58191 tcp_do_segment+0x201f >>>> 16384 |@@@@@@ 29594 tcp_input+0xe1c >>>> 32768 |@@@@ 23447 ip_input+0x15f >>>> 65536 |@@@ 16197 >>>> 131072 |@ 8674 >>>> 262144 | 3358 >>>> 524288 | 456 >>>> 1048576 | 9 >>>> ------------------------------------------------------------------------------- >>>> Count indv cuml rcnt nsec Lock Caller >>>> 49180 26% 100% 0.00 15929 tcpinp tcp_tw_2msl_scan+0xc6 >>>> >>>> nsec ------ Time Distribution ------ count Stack >>>> 4096 | 157 pfslowtimo+0x54 >>>> 8192 |@@@@@@@@@@@@@@@ 24796 softclock_call_cc+0x179 >>>> 16384 |@@@@@@ 11223 softclock+0x44 >>>> 32768 |@@@@ 7426 intr_event_execute_handlers+0x95 >>>> 65536 |@@ 3918 >>>> 131072 | 1363 >>>> 262144 | 278 >>>> 524288 | 19 >>>> ------------------------------------------------------------------------------- >>> >>> This is interesting, it seems that you have two call paths competing >>> for INP locks here: >>> >>> - pfslowtimo()/tcp_tw_2msl_scan(reuse=0) and >>> >>> - tcp_input()/tcp_twstart()/tcp_tw_2msl_scan(reuse=1) >> >> My current hypothesis: >> >> nginx do write() (or may be close()?) to socket, kernel lock >> first inp in V_twq_2msl, happen callout for pfslowtimo() on the same >> CPU core and tcp_tw_2msl_scan infinity locked on same inp. >> >> In this case you modification can't help, before next try we need some >> like yeld(). > > Or may be locks leaks. > Or both. Actually one extra debug thing you can do is launching lockstat with below extra options: -H For Hold lock stats -P To get the overall time -s 20 To get the stackstrace To see who is holding the INP lock for so long. Thanks to Hiren for pointing the -H option. -- Julien