From owner-freebsd-stable@freebsd.org Thu Feb 18 00:50:48 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 6E620AAC0FF for ; Thu, 18 Feb 2016 00:50:48 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.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 53E051C30 for ; Thu, 18 Feb 2016 00:50:48 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: by mailman.ysv.freebsd.org (Postfix) id 517A7AAC0FD; Thu, 18 Feb 2016 00:50:48 +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 35E3EAAC0FC; Thu, 18 Feb 2016 00:50:48 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id E14531C2C; Thu, 18 Feb 2016 00:50:47 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from lowell-desk.lan (router.lan [172.30.250.2]) by be-well.ilk.org (Postfix) with ESMTP id 90D0033C1E; Wed, 17 Feb 2016 19:50:40 -0500 (EST) Received: by lowell-desk.lan (Postfix, from userid 1147) id D0E4D39843; Wed, 17 Feb 2016 19:50:39 -0500 (EST) From: Lowell Gilbert To: hiren panchasara Cc: Efra?n D?ctor , owner-freebsd-stable@freebsd.org, stable@freebsd.org Subject: Re: intr using Swap References: <56C4AF81.3040202@motumweb.com> <87f6fb602e0ad11b7600c70a08d74c30@dweimer.net> <56C4C244.8070805@motumweb.com> <56C4F7E9.9090405@motumweb.com> <20160217230138.GJ89208@strugglingcoder.info> Date: Wed, 17 Feb 2016 19:50:39 -0500 In-Reply-To: <20160217230138.GJ89208@strugglingcoder.info> (hiren panchasara's message of "Wed, 17 Feb 2016 15:01:38 -0800") Message-ID: <44d1rusuxs.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain 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 00:50:48 -0000 hiren panchasara writes: > On 02/17/16 at 04:44P, Efra?n D?ctor wrote: >> El 17/02/2016 a las 01:15 p. m., dweimer escribi?: >> > >> > They may not show as swapped unless the entire process is actually >> > swapped, which would be unlikely to occur. Personally I wouldn't worry >> > about it, the only thing I can think of is to restart processes one at >> > a time to see which one clears up the swap usage. Granted you may see >> > a little clear after each process. >> > >> > The more important task would be to determine what caused the memory >> > to run out in the first place, and decide if its going to be a >> > frequent enough occurrence to justify adding physical memory to the >> > system. >> > >> > There is likely some way to find out what is using it, but that is >> > beyond my knowledge. >> > >> > -- >> > Thanks, >> > Dean E. Weimer >> > http://www.dweimer.net/ >> >> The server has 64 GB of RAM, 40-45 GB are always inactive thats why I'm >> wondering why are the processes being swapped out. 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. > Yes, I've seen this too. Inact end up accumulating a very large chunk of > memory leaving Free to very low. That's yet another, different thing. > What VM/pagedaemon seems to care about is Free+Cache and not just Free. 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. > 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. "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. > 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? These take effect immediately, from what I can see. 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. Be well.