From owner-freebsd-stable@freebsd.org Tue Jun 19 20:20:33 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7DF3100C454 for ; Tue, 19 Jun 2018 20:20:32 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from limbo.b1t.name (limbo.b1t.name [78.25.32.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6CA8A74252 for ; Tue, 19 Jun 2018 20:20:32 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from [172.29.1.147] (probe.42.lan [172.29.1.147]) by limbo.b1t.name (Postfix) with ESMTPSA id CA417B3; Tue, 19 Jun 2018 23:20:21 +0300 (EEST) Subject: Re: lightly loaded system eats swap space To: Jeremy Chadwick , freebsd-stable@freebsd.org References: <20180619172936.GA24967@icarus.home.lan> From: Volodymyr Kostyrko Message-ID: Date: Tue, 19 Jun 2018 23:20:20 +0300 User-Agent: Mozilla/5.0 (X11; DragonFly x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180619172936.GA24967@icarus.home.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=b1t.name; s=dkim; t=1529439623; bh=a/7zMlbqtpX0WkxRyx1KRGn+m3FCT2qyseHt7s0FgRw=; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EUgmSNE+b1DUZpcP0aLBlAyRKsVPxRD2Rfr0pP92Dn3SRg0Ul1lStWHsAqWakXeBLNayxrjf1pKy26rydvVWms98vRUQxGQskbY50++ZAHrdo4ZRl+qUvdwbHFiuWXWr/odHdUUOmPfqy5AQbUiWZFgGT1+bwiHRAjuZlU8GC08= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:20:33 -0000 19.06.18 20:29, Jeremy Chadwick wrote: > (I am not subscribed to -stable, so please CC me, though I doubt I can > help in any way/shape/form past this Email) > > Not the first time this has come up -- and every time it has, all that's > heard is crickets in the threads. Recent proof: … I may sound lame but I also faced this issues a few month ago. After a few days of load system was trying to push more and more data into the swap up to the point that active window becomes too small to handle all programs so they should be get back from swap and while they are not running something pinches ARC and ARC claims the memory and so on… I wasn't ever a fan of limiting things. If something requires limits it can be easily exploited. Should I switch from normal limits to other limits when I, say, need to test something on 4 VMs? So while paging through documentation I found a rather old memo in tuning(7) about vm.swap_idle_enabled. I played a little with thresholds but that was only making things worse. I left swap_idle_enable on and let machine live. That was near January I suppose. To my amusement swap problems were gone. This doesn't mean swap wasn't used, instead system survived weeks under irregular load without issues. The only other change that I did was bumping up vfs.zfs.arc_free_target a little bit higher then default to make some space between ARC and VM so they wouldn't clash on memory so often. Since then all of my problems with swap was forgotten. I'm not sure what setting fixed that, neither I'm sure that wasn't some recent patches. I'm running 11-STABLE and rebuilding system at least once per month. Hope that can help someone. WBR. -- Sphinx of black quartz judge my vow.