From owner-freebsd-hackers@freebsd.org Tue Sep 11 00:54:16 2018 Return-Path: Delivered-To: freebsd-hackers@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 6C83010A092D for ; Tue, 11 Sep 2018 00:54:16 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBA0B7CBF7 for ; Tue, 11 Sep 2018 00:54:15 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pl1-x62d.google.com with SMTP id f6-v6so10528570plo.1 for ; Mon, 10 Sep 2018 17:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2P/vSyopDGfOUHpI+dBHqU/jFEWx/800JWmHhq2s+fk=; b=MSdh+zqiXDCCuAyHVHV42OBBvGWFToCGmIEwigcZ9cwrF0sAwJNQPO7c39g8+me8Nf Ew8ib6MK95WkeKtELTPpLf3twhOs1s0eH1KxCcAgu+z7ON2mF5woM3ZTm6k0BSNyYH6n a9xajE9dBUdZ4DIZDMpu98Qe6KhEYY9DXv52IsJoGXQ4y5m8ubkP4s6paV9CejZLRg4u ZvBq2e8yPdDCQBs7oTqj5zhBPzD+Y/OOyYPX8z8zwwurrIve2kqQZHBFYXSfFJ6Qvnxt QP+dy47GsHiOAbcD/XBG0J3abzgJUoKn5V6/8r4120/YKvJjamswY4vS6ifS2Zld5Hun 9Dtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=2P/vSyopDGfOUHpI+dBHqU/jFEWx/800JWmHhq2s+fk=; b=HoUaCnG53rNDcRX4TzN1W90aByrHFAsdbVvMBHvcvmLFNSbaLiLGGG/5+JiCsaGaLo Ji0bX3nGM6JI/ZwfbdMaY43FDxxtJtcPyqeVDHc3StkUXIrGz1v2ufb1pcP1zcunYWVa Zb54RvwWcXsSwCPriAwtE+MVJLS8XsDpJxKIBh8b5bCTKaCYxZV1b5v3XMXgDghP3sFV 1wrbM5fZW9m9NxtuYpr0kCDqUW1u0DXTf71FttjYbHHQ93NxIIUa13MQz6iPHJT/Semm AKC+ilHJ5ddJeCGjMHTHhMYy4WvGmkcl4nqSKCwGlYsQyOJSLiqSdK2sl+z5Efuczmch sYQA== X-Gm-Message-State: APzg51DV0V6tazlc82hnTihb+FQL3GmNzEo2iC6zCOPktMk08lC0RAop X7ulJI+yWbLlFMOAvqzokhr9KGgw X-Google-Smtp-Source: ANB0VdY5EdaJ+Dc/wRVheoeT0iXaDn+m8FO+dhLYEdjc+3QA7gh3VC4Gkg3Y5keXAttthsmzGQxnNQ== X-Received: by 2002:a17:902:8d8c:: with SMTP id v12-v6mr24137876plo.94.1536627254867; Mon, 10 Sep 2018 17:54:14 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-78-8.dsl.bell.ca. [174.88.78.8]) by smtp.gmail.com with ESMTPSA id z8-v6sm20956070pfe.163.2018.09.10.17.54.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 17:54:13 -0700 (PDT) Sender: Mark Johnston Date: Mon, 10 Sep 2018 20:54:11 -0400 From: Mark Johnston To: Robert Cc: freebsd-hackers@freebsd.org Subject: Re: Sudden grow of memory in "Laundry" state Message-ID: <20180911005411.GF2849@raichu> References: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 00:54:16 -0000 On Mon, Sep 10, 2018 at 11:44:52AM -0700, Robert wrote: > Hi, I have a server with FreeBSD 11.2 and 48 Gigs of RAM where an app > with extensive usage of shared memory (24GB allocation) is running. > > After some random amount of time (usually few days of running), there > happens a sudden increase of "Laundry" memory grow (from zero to 24G in > a few minutes). > > Then slowly it reduces. > > Are described symptoms normal and expected? I've never noticed anything > like that on 11.1. The laundry queue contains dirty inactive pages, which need to be written back to the swap device or a filesystem before they can be reused. When the system is short for free pages, it will scan the inactive queue looking for clean pages, which can be freed cheaply. Dirty pages are moved to the laundry queue. My guess is that the system was running without a page shortage for a long time, and suddenly experienced some memory pressure. This caused lots of pages to move from the inactive queue to the laundry queue. Demand for free pages will then cause pages in the laundry queue to be written back and freed, or requeued if the page was referenced after being placed in the laundry queue. "vmstat -s" and "sysctl vm.stats" output might make things more clear. All this is to say that there's nothing particularly abnormal about what you're observing, though it's not clear what effects this behaviour has on your workload, if any. I can't think of any direct reason this would happen on 11.2 but not 11.1.