From owner-freebsd-current@freebsd.org Tue Mar 15 18:38:11 2016 Return-Path: Delivered-To: freebsd-current@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 A51A9AD2674 for ; Tue, 15 Mar 2016 18:38:11 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 074361F06; Tue, 15 Mar 2016 18:38:10 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from [192.168.100.100] ([87.139.233.65]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQzIE-1aEv5P3Pbi-00UNgp; Tue, 15 Mar 2016 19:38:05 +0100 Subject: Re: how to recycle Inact memory more aggressively? To: FreeBSD Current References: <1458055811.68920.24.camel@freebsd.org> Cc: Ian Lepore , jbtakk@iherebuywisely.com, "gljennjohn@gmail.com >> Gary Jennejohn" From: olli hauer Message-ID: <56E85759.8060905@gmx.de> Date: Tue, 15 Mar 2016 19:41:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1458055811.68920.24.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ipa9qwBub1Apc/YkLaLJMEn+eMu9FYdv+mf0wIddgaxn93I8S8T frCnJpJHbnrDeg9Wcd+32JiDSg8xwufzQoeYSX5lwTuvKFHTDtN+nkVMo1brQArnltdjw/B UnVTE11vckSY3X0qtzeHS/kcg3m4i7e52U//tSWKIK8KdQBEnb1Ki039qt1tGtdUq5t4bMV eHTi+bTrzc7G1hseydnFA== X-UI-Out-Filterresults: notjunk:1;V01:K0:2SMQl2Qt/QA=:hT5ZUoF1MWa6+x7VwKnOUk gg3umSNvvj0Om1lnhV3DDw/eBtZQi9i0z54j99KS6OY3HntzNNt+lbzdj2YZZyezno7zcp1Tg NFKZUi4Vr6XUSCnKIwqgpl1GNcjZykS0e0g8iz6+G7I7SJAYA54xk/tgK/VI3QVAz3VcqBsQv 5tCrNRDRvryq6CCC6zAqi1DcXUELY9AzKaibjWFa8FOGhaZ3k+aaxVP5GAz04tdNcS7XnpXTM wmtpdCUso9q+sT92nfrYd9eiwEAywDkXyuQBesECpOkCOx/CWOvbtEiDW9lvpSOZxlkMa9rXw +4QxfcYBUlIM0qIH99ffExFaHYcM5QtTcGxrn0oNIpU0vcaoPlpb36TRMLCahkOy9DccqQFhy y869tdX57gTwnOLyOARnChdJGxvR/LSZiCo0ZpM+hJp1oPSxRdXzHVT32USYoYLUarfk6HOj0 HxrPwzI4MXL8U2dQDbRu1v2cFydmHnobdldF7XB0iIiFp4B3EpL1JQnfxPf2z6MzuEPVL0O+i tnVw2w/PKtmJ67IeKU4vrCEsC7IMyHH6BrWUGVRBrQyzDoB9sc4LF9K86MPYeuFn8suI6mvCM I6D1NBvEUa3nnr+J6E0IQpKTqPLEnyE2BGflT4be8UN60tKJQadX1nyXINoMXWweOjRLg996B szCv/ft06zoKlH9+mIzFXP/NnNwCAny5FzBPuizsu00K/Wd9875/DD86vVmb8DGP1BGebO5gr XvQR2TkrPLW+jkdRRfoi+DCh7v4RCl9t00X8OLdF+yXE7IeDMRI4km2fmzbItwsZGkFjNylZt hb2tBAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 18:38:11 -0000 ... >> Just a point I've bought up elsewhere... >> I've, if I recall, wrecked several filesystems (although EIDE) using >> rsync at the normal bus rate, and sometimes >> thumbdrives with whatever filesystem type on them. >> >> I settled on --bwlimit=1500, max for unattended rsync usage and >> almost every day >> use --bwlimit=700. It happened also on VM's where the host is connected via FC to the storage but only on the FreeBSD VM's. >> The latter enables several resource-intensive processes ( music, >> classical music videos, svn, pkg, browsing, etc) to >> proceed apace concurrently on the desktop (SATA not EIDE) with nary a >> hang nor slowdown. I don't have any *NIX system with a gui, only around 110+ headless systems and halve of them are running FreeBSD. > I have no real idea what any of that is about, but before it turns into > some kind of "rsync is bad" mythology, let me just say that I've been > using rsync to copy gigabytes of backup data every day for years now. > I've never had any kind of problem, especially system responsiveness > problems, until this increased swapfile activity thing started > happening on 10-stable in the past few months. > > To reiterate: rsync is not in any way at fault here, and any suggestion > that the unresponsiveness should be "fixed" by screwing around with > rsync parms that have worked fine for a decade is just something I > completely reject. > > I'm sure I'd see the same kind of increased swapping with ANY process > that read and wrote gigabytes of data in a short period of time. And > that's what this thread is about: What has changed to cause this > regression that multiple people are seeing where lots of IO now drives > an unusual amount of swapfile activity on systems that used to NEVER > write anything to swap? All those systems are running already for years, for me it looks more like a missing *free* (memory leak). Looking at the net/rsync history the last update was in Dec. 2015. Perhaps it is worth to test net/rsync r359474 for a while to get a comparsion, but Gary reported the issue by using `cp' and not rsync. -- olli