From nobody Mon Sep 16 05:41:08 2024 X-Original-To: freebsd-hackers@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 4X6YgS122Jz5W4R8 for ; Mon, 16 Sep 2024 05:41:24 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X6YgQ6TDVz47fg; Mon, 16 Sep 2024 05:41:22 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ultimatedns.net header.s=mx99 header.b=tFJq930+; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 48G5f9t7013415; Sun, 15 Sep 2024 22:41:15 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1726465275; x=1726465875; r=y; bh=5vO94Pd2xmEvmNK94F1nZqIFbjMd3sCc0yUArq8kCu8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=tFJq930+u6n1avm1FFmIwU2xGL9Cua5wK5yl+rQ5b16bhB+DBW9ybRxneEDKbv3t3 KvvgM83shHkodJvtGZIKUdb8z95g+FNP8le8FavZ/zatot+VKz+MbR2fBrl72/B/NW OMXE/LQlYJdtfpM/KG59mggWGxaJiHFObWbmaXyizgQGLKa1Pot0BvtthUstiDI+9B fxFLL8ybcf9XLjNKhvkUL7nNqprZgE8JWmvILjVOp9Jl2x6S0TPwFMBg9m+qem0MCM gQfBDrefuc6LhXaiZzwc+lwm0bTHOx9D5xZj1htBDOhXHE6eAo0bQfWMcgrIOAtqtB 8WiUJbQ68zozg== List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Date: Sun, 15 Sep 2024 22:41:08 -0700 From: Chris To: Yuri Cc: Freebsd hackers list Subject: Re: How to explain high memory consumption of a jail after all large processed in it have finished? In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <8401aac030b97331c4ade91438854884@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.60 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; R_SPF_ALLOW(-0.20)[+ip4:24.113.41.81/29]; R_DKIM_ALLOW(-0.20)[ultimatedns.net:s=mx99]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[ultimatedns.net:+] X-Rspamd-Queue-Id: 4X6YgQ6TDVz47fg On 2024-09-12 11:45, Yuri wrote: > I noticed that when the port lang/rust is building in the poudriere jail the > memory consumption of the host system remains high all the way into the > packaging > phase when the pkg-static process is the only active process and it consumes > a > very little memory. > > > During build a lot of memory is consumed, which is understandable. The > system > remains at ~500MB of free memory through the build process, according to > top(1). > > > But once the build is finished, poudriere goes into the "packaging" phase > which > only runs a small pkg-static process that compresses the built files. > pkg-static > is the only active process in the poudriere jail. > > > What looks strange to me is that the host system's memory consumption > remains high > through the "packaging" phase which itself is low in memory, and only goes > down > when the jail is destroyed. > > > How to explain the high memory consumption of a jail after all large presses > have finished? Apologies in advance if already addressed, but I'm way behind on my email. I'm gonna guess the compression stage is responsible. My experience shows it really chews through CPU cycles, and as a result memory. --Chris > > > > Thanks, > > Yuri -- sent from a device written from and running on FreeBSD