From nobody Tue Aug 03 13:47:13 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BD35012D9BB5; Tue, 3 Aug 2021 13:47:13 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GfGQ94K96z4VP7; Tue, 3 Aug 2021 13:47:13 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x833.google.com with SMTP id h10so13952801qth.5; Tue, 03 Aug 2021 06:47:13 -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:content-transfer-encoding:in-reply-to; bh=pWRyDEXI9ta6X9SsIJ7NlKZaCSItKV4GjqxstcIRsps=; b=QrJj4Gk1S+LqqwCOIy10M7u1sWsYS80KqX4hrUIUUtUhtQ/BdQhqEQMiwzNVcFQJyK 0hZs7K27pdPvfDl8s4cvcpVDlckCsqOG9M5kfqu2uOkA+K4jLDwBPmXuoHG8oYAPaduR CxXk9AIUSRIUWUxD8zUqTTAMzAg+LGHTfW5XJza4FCaDXFTtyVIP6RCMw39bCIu24/z+ yvW7nL75XopNmY9MzCDw8a0DNYABX0322bJ8wi0XoEiSjc8AnjlIptw8zei3zn5eb52m YTYJOjJRVabO9hSFBY99t/YgPIn9W+u78+AvTW42VX1dkhINtzGJkL8EvVBDmYOj9Xs8 58nA== 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 :content-transfer-encoding:in-reply-to; bh=pWRyDEXI9ta6X9SsIJ7NlKZaCSItKV4GjqxstcIRsps=; b=tKt4jQq2rYZX6X1cDgXQYy7J0tyyaw2j9ziGvL6p06tXzspV/o/mphE4DwrlTHAUjV GLsrqdXTYDNwedvHLxm1Gz8BZpR+ssjwLgE58uvm0EO9X2p0pCeUbX6znjDbFTkbuW+A TJv+0HNlprUs6lQIO2+CGwN4icuA40Rn8GW0GPJvdpXDZvNSWX/4tmhHtbwPMkQZC0F0 ntoPhca/uz34L8uGgRAm8FbkWsROdjMI4VRsUDhfVnqpOKZUTGENzQApnJt3Klesg7C6 a9r0+DBZIeONl7SQaWHzAS8LciHFF97/HClvXv9cWiiOfZjQGn6XOHaGyeDIlFAPm5cb gSeg== X-Gm-Message-State: AOAM530WdhoDInR31xxlQzIFsawuUBCbHieXPx8FfjVysbV5oNCn1Oyz tcNjdwWGaZFlSHF9VMikz0s= X-Google-Smtp-Source: ABdhPJy8blrxm/OPzRX/6lCoWyvoy4CJlKJCtQ6cLyXW3SyM0TSkkM07WlgD1TdafpfIG1WHXJUEbg== X-Received: by 2002:a05:622a:1a9f:: with SMTP id s31mr18500579qtc.151.1627998433201; Tue, 03 Aug 2021 06:47:13 -0700 (PDT) Received: from nuc ([142.126.162.193]) by smtp.gmail.com with ESMTPSA id x7sm7643200qki.102.2021.08.03.06.47.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Aug 2021 06:47:12 -0700 (PDT) Date: Tue, 3 Aug 2021 09:47:13 -0400 From: Mark Johnston To: "Andrey V. Elsukov" Cc: =?iso-8859-1?Q?=D6zkan?= KIRIK , FreeBSD Net , freebsd-stable Subject: Re: Wired Memory Increasing about 500MBytes per day Message-ID: References: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5dc957ec-9483-0a80-b29e-be4b71c1b9d9@yandex.ru> X-Rspamd-Queue-Id: 4GfGQ94K96z4VP7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Tue, Aug 03, 2021 at 09:38:17AM +0300, Andrey V. Elsukov wrote: > 02.08.2021 08:00, Özkan KIRIK пишет: > > Hello, > > > > I'm using FreeBSD stable/12 0f97f2a1857a96563792f0d873b11a16ff9f818c (Jul > > 25) built. > > pf, ipfw and ipsec options are built with kernel. The server is used as > > firewall that squid and snort3 (daq - netmap) is running. > > > > I saw that, wired memory is increasing every day. It's about 500MBytes per > > day. I'm checking vmstat and top (sorted by res), I couldn't find what is > > consuming the wired memory. > > > > How can I find that which process or which part of kernel is consuming the > > wired memory ? > > Hi, > > We noticed the same problem, I'm not sure the exact version, but you can > check the output: > # vmstat -z | egrep "ITEM|pgcache" > > The page cache grows until lowmem is not reached. Then it automatically > cleans and begins to grow again. The pgcache zones simply provide a per-CPU cache and allocator for physical page frames. The sizes of the caches are bounded. The numbers of "used" items from the pgcache zones do not really tell you anything since those pages may be allocated for any number of purposes, including for other UMA zones. For instance, if ZFS allocates a buffer page from its ABD UMA zone, and that zone's caches are empty, UMA may allocate a new slab using uma_small_alloc() -> vm_page_alloc() -> pgcache zone. So if there is some wired page leak, the pgcache zones are probably not directly responsible.