From owner-freebsd-stable@freebsd.org Thu Feb 18 01:12:37 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 967BEAAC9D4 for ; Thu, 18 Feb 2016 01:12:37 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 844A3A6D for ; Thu, 18 Feb 2016 01:12:37 +0000 (UTC) (envelope-from bc979@lafn.org) Received: by mailman.ysv.freebsd.org (Postfix) id 83EF4AAC9D3; Thu, 18 Feb 2016 01:12:37 +0000 (UTC) Delivered-To: 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 83712AAC9D2; Thu, 18 Feb 2016 01:12:37 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from mail.lafn.org (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4B6A6C; Thu, 18 Feb 2016 01:12:36 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from [10.0.1.12] (unknown [10.0.1.12]) by mail.lafn.org (Postfix) with ESMTPSA id D201D114C4FD; Wed, 17 Feb 2016 17:06:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: intr using Swap From: Doug Hardie In-Reply-To: <44d1rusuxs.fsf@lowell-desk.lan> Date: Wed, 17 Feb 2016 17:06:48 -0800 Cc: hiren panchasara , owner-freebsd-stable@freebsd.org, stable@freebsd.org, Efra?n D?ctor Content-Transfer-Encoding: quoted-printable Message-Id: <49F794B1-937F-4AEA-90CF-7C19AFF7EFE2@lafn.org> References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> <56C4F7E9.9090405@motumweb.com> <20160217230138.GJ89208@strugglingcoder.info> <44d1rusuxs.fsf@lowell-desk.lan> To: Lowell Gilbert X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 18 Feb 2016 01:12:37 -0000 > On 17 February 2016, at 16:50, Lowell Gilbert = wrote: >=20 > hiren panchasara writes: >=20 >> On 02/17/16 at 04:44P, Efra?n D?ctor wrote: >>> El 17/02/2016 a las 01:15 p. m., dweimer escribi?: >>>>=20 >>>> They may not show as swapped unless the entire process is actually=20= >>>> swapped, which would be unlikely to occur. Personally I wouldn't = worry=20 >>>> about it, the only thing I can think of is to restart processes one = at=20 >>>> a time to see which one clears up the swap usage. Granted you may = see=20 >>>> a little clear after each process. >>>>=20 >>>> The more important task would be to determine what caused the = memory=20 >>>> to run out in the first place, and decide if its going to be a=20 >>>> frequent enough occurrence to justify adding physical memory to the=20= >>>> system. >>>>=20 >>>> There is likely some way to find out what is using it, but that is=20= >>>> beyond my knowledge. >>>>=20 >>>> --=20 >>>> Thanks, >>>> Dean E. Weimer >>>> http://www.dweimer.net/ >>>=20 >>> The server has 64 GB of RAM, 40-45 GB are always inactive thats why = I'm=20 >>> wondering why are the processes being swapped out. >=20 > There are almost certainly no processes being swapped out. Some of = their > *pages* are being stored in swap, but that is a very different thing. >=20 >> Yes, I've seen this too. Inact end up accumulating a very large chunk = of >> memory leaving Free to very low.=20 >=20 > That's yet another, different thing. >=20 >> What VM/pagedaemon seems to care about is Free+Cache and not just = Free. >=20 > Which makes sense, even without a deep understanding of the concepts, > because those are guaranteed to be able to be re-allocated = immediately. > It is literally true that the pageout scan does nothing when = free+cache > is less than the target. >=20 >> I kind of get that Free mem is wasted mem but putting everything in = Inact >> to the point that machine has to go into swap when a sudden need = arises >> also doesn't seem right. >=20 > "Go into swap" is too vague to mean much. I suspect that you mean the > system will have to start swapping out rapidly, but that isn't = actually > the case. First of all, pages in "inact" aren't necessarily dirty, so > re-using them wouldn't be as expensive as having to write them to > backing store. Also, when a page is copied to swap, the surrounding > pages are eligible to be copied to swap also, to take advantage of the > bandwidth advantages of larger transfer sizes. This does not move them > to the cache queue, although it does make that easier to do later if = and > when their "turn" comes up. >=20 >> I guess it all boils down to adjusting defaults to the system's need. >> i.e. if you know you have a proc that may need a large chunk of mem >> you'd need to tweak free+cache target accordingly. What I find = lacking >> is the correct/easy way to do it. If I look at available sysctls: >> vm.v_free_min: Minimum low-free-pages threshold >> vm.v_cache_min: Min pages on cache queue >> vm.v_free_target: Desired free pages >> And I cannot get them to do the right thing to have more Free around = so >> swapping doesn't happen in sudden need. And are these all runtime >> sysctls? OR does it require reboot for them to work right?=20 >=20 > These take effect immediately, from what I can see. >=20 > Have you measured that paging (not swapping; that's a more extreme > measure where the whole process gets removed from memory) is a > significant load on your system in a specific case? If not, I doubt = that > it's actually the case, and you're mitigating a non-existent problem I believe the question here is what is using up the swap space. =46rom = what I have been able to find with a similar situation is that malloc = will allocate swap space to backup memory and mmap will also allocate = swap if there is no backing file. procstat -v can be helpful in chasing = down some of those issues. However, I ended up guessing which process = it was by sequentially restarting processes and watching swapinfo. I = still have not been able to chase down what in that process is using the = space. There are no mmaps that are not file backed so it must be a = malloc. Finding the right one has been elusive. =20