From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7182122219497062400 X-Received: by 2002:a62:55c3:0:b0:576:b4ce:42b4 with SMTP id j186-20020a6255c3000000b00576b4ce42b4mr1564495pfb.61.1672222998160; Wed, 28 Dec 2022 02:23:18 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a62:e113:0:b0:580:eae2:d19c with SMTP id q19-20020a62e113000000b00580eae2d19cls2257366pfh.4.-pod-prod-gmail; Wed, 28 Dec 2022 02:23:17 -0800 (PST) X-Google-Smtp-Source: AMrXdXu6NPqxVuhOfAG3SrBLdgGSuksiPUpAi66MImz4fWhBKz98huCuX+AkLE+d24sFPjCX1BY6 X-Received: by 2002:a62:b617:0:b0:577:b52:4ec2 with SMTP id j23-20020a62b617000000b005770b524ec2mr23908713pff.29.1672222997068; Wed, 28 Dec 2022 02:23:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672222997; cv=none; d=google.com; s=arc-20160816; b=ga3YVO3Nju7pov9y6olD6kxRmYw1rpJrjuaUYut/0sN/FmqpL4HJ4GhWikuz0W0smX cnj+0XosK+5vmEabPB7vnOtrh9qduHcO3lcp9dgqVBNcakMF9H4UfQQm/QPk5ddOt95G wcZNfqY6I/8Vjl6oWAr+iCVEvZLAJJtTsJgpNTXFXz/mDpHCh+VVDLsjCDv/PCZGGfMg NNpVvW2PMCS73xmds5GgeP+Q7tuGiT/zbRkjR7WqRNHMjUFKaP5RQw9i+zKjXvz+Zvf3 +3QfxrB5zuMZrNalYW6dt6Rgpf5bY9ME+Z4owpFPFFfMNWsqfE2UKqI/WCafUG1IQtn3 xlzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=kQSXF3vCFXtJBmGKtFUdnISR7FDsuETLWSWlmY0jnKQ=; b=XCrxAxGXlEtQQ8FWnAXz+d/ubwsSt/NLLfb/yEJqad+3cG0HFxwxME9TkFX4FZ3OtG FlqWjb3IL5UrzxfGDLPGfhDlBWBAvf49D9AaL20Z1317O1EjKluOGdAK4m8RJZ/a/3VP ddZ2gJLOpMGFe8mpCkHMhQKJKfq6p40U3qjcg3fyE3k4w++gOFfzNCgIp0MaRaOgGIuH XtoD0ZS9ncZjUYDZaNOUfZOLDA3HZIIZ/vGdSi2rV1tzyiJUp0BUdiEsyZdnnYQ9h/7P ILCoMpZFmh3SWcX21qZ3SgxqD2qSq+F8PjejJ/P7iJ/hu8LVIjZ3wclRm+KelHI6ROK2 ZKcQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id u80-20020a627953000000b005819980b1e2si109034pfc.1.2022.12.28.02.23.16 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 28 Dec 2022 02:23:16 -0800 (PST) Received-SPF: pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Received: from hp.localnet (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 2BSAMwiq003845 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Dec 2022 11:23:14 +0100 From: Uladzimir Bely To: "ibr@radix50.net" , isar-users@googlegroups.com, "Schild, Henning" Cc: "Moessbauer, Felix" Subject: Re: Better way to handle apt cache needed Date: Wed, 28 Dec 2022 13:23:18 +0300 Message-ID: <4769513.OV4Wx5bFTl@hp> In-Reply-To: <38d18c245baa4f685642eafa9a52ab9b9ae9001c.camel@siemens.com> References: <371e4d826cca6aaba11a4222fef547b134ed6ce7.camel@siemens.com> <38d18c245baa4f685642eafa9a52ab9b9ae9001c.camel@siemens.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: 4My1E62gF3xC In mail from =D1=81=D1=80=D0=B5=D0=B4=D0=B0, 28 =D0=B4=D0=B5=D0=BA=D0=B0=D0= =B1=D1=80=D1=8F 2022 =D0=B3. 12:45:07 +03 user Moessbauer, Felix=20 wrote: > On Wed, 2022-12-28 at 10:21 +0100, Baurzhan Ismagulov wrote: > > On Wed, Dec 28, 2022 at 09:02:13AM +0000, Moessbauer, Felix wrote: > > > The root cause for that behavior is the apt cache > > > (deb_dl_dir_(import|export)), that copies all previously downloaded > > > apt > > > packages into the WORKDIR of each (bitbake) package. > > > Given, that a common apt-cache is around 2GB and 8 tasks are run in > > > parallel, this gives already 16GB for the tasks, and 7 * 2GB for > > > the > > > buildchroots (host and target), in total ~30GB. > >=20 > > Thanks Felix for the report. IIRC, it was previously mounted and was > > supposed > > to be converted to per-package hardlinks to parallelize sbuild > > instances and > > ease debugging (by knowing later which exact snapshot was fed to a > > specific > > build). We use small (1- / 2-TB) SSDs as job storage and a huge > > increase would > > have been noticeable... We'll check. >=20 > Thanks! >=20 > I just noticed, that we even make an additional copy to have the > packages inside the sbuild chroot. >=20 > This behavior is hard to notice on small and medium sized projects (and > given that IOPS are not an issue). But any quadratic behavior will > eventually make the build impossible. And as Florian said, many of our > ISAR users build in VMs on shared filesystems, where IO is extremely > expensive / slow. If we could optimize that, it would be a huge benefit > for a lot of users. I've just did some measurements: =2D run Isar build for qemuarm64 (8 cores =3D max 8 build tasks in parallel) =2D measured system disk consumption every 5 seconds Results: =2D 'downloads/deb' directory finally takse 480MiB =2D After the build finished, disk space decreased by ~9GiB =2D During the build maximum disk space decrease was ~16GiB) It means, that we really had about 16 - 9 =3D 7GiB of space temporarly used= by=20 parallel builds and it really corresponds to 8 * 2 * 480MiB. So, the main goal now is to minimize this value. >=20 > Felix >=20 > > With kind regards, > > Baurzhan