From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 263EE96AA7 for ; Thu, 26 Jan 2023 09:04:04 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id EE6C81FE5A for ; Thu, 26 Jan 2023 09:03:33 +0100 (CET) Received: from kerio.tuxis.nl (alrami.saas.tuxis.net [31.3.111.57]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 26 Jan 2023 09:03:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tuxis.nl; s=mail; h=from:reply-to:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=qL1XwOyDNLX8b3hECUPm03KadrRbLP839GeE0CriVIo=; b=nUBMn9X4Nrm4mAFHAK/RlbfmH6o/+ZGObTqKGH3mQY5GnbW3p2ncFbcU8YYujQe1Tj5Qb01VKC5UN x5bLjzoeNHwGBOXncOp9AlrVdU0w7V65hjfVQn2GLy/Vh7kthM6m6hO4rBY5siNg6wrldT6bzOmZql 544gJ01Z/DiIiJ6NyCe1cPHUPN8dVrejr3WxbHjObcC/1oFNr8L1cXhfU6BsmNjOH/LqY2ZbjD6Uwf Oj+Zh27FL9/lPP89VBIS4s7GvRnale1DGJX5EJ8z2NbY0Z6Zvwjx7/1thPdNDh5ft3/q8mWOf5NeyD fLuRbBZcnP5vU6NqPNyhzbo7F7gkGKg== X-Footer: dHV4aXMubmw= Received: from [IPv6:2a03:7900:64::1001] ([2a03:7900:64::1001]) (authenticated user mark@tuxis.nl) by kerio.tuxis.nl (Kerio Connect 10.0.0) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 26 Jan 2023 09:03:30 +0100 From: "Mark Schouten" To: "Thomas Lamprecht" , "Proxmox Backup Server development discussion" Date: Thu, 26 Jan 2023 08:03:24 +0000 Message-Id: In-Reply-To: <11d3a67b-bc11-483f-c25b-2c6b634e4326@proxmox.com> References: <11d3a67b-bc11-483f-c25b-2c6b634e4326@proxmox.com> Reply-To: "Mark Schouten" User-Agent: eM_Client/9.2.1222.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.057 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain RCVD_IN_DNSWL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [tuxis.nl] Subject: Re: [pbs-devel] Slow overview of existing backups X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2023 08:04:04 -0000 Hi, >> PBS knows when something changed in terms of backups, and thus when it= =E2=80=99s time to update that index. >> > >PBS is build such that the file system is the source of truth, one can, >e.g., remove stuff there or use the manager CLI, multiple PBS instances >can also run parallel, e.g., during upgrade. > >So having a guaranteed in-sync cache is not as trivial as it might sound. > You can also remove stuff from /var/lib/mysql/, but then you break it.=20 There is nothing wrong with demanding your user to don=E2=80=99t touch any= =20 files, except via the tooling you provide. And the tooling you provide,=20 can hint the service to rebuild the index. Same goes for upgrades, you=20 are in charge of them. We also need to regularly run garbage collection, which is a nice moment=20 to update my desired index and check if it=E2=80=99s actually correct. On e= very=20 backup run, delete, verify, you can update and check the index. Those=20 are all moments a user is not actually waiting for it and getting=20 timeouts, refreshing screens, and other annoyances. > >> I have the feeling that when you request an overview now, all individua= l backups are checked, which seems suboptimal. > >We mostly walk the directory structure and read the (quite small) manifest >files for some info like last verification, but we do not check the backup >(data) itself. > >Note that using namespaces for separating many backups into multiple folde= r >can help, as a listing then only needs to check the indices from the names= pace. > >But, what data and backup amount count/sizes are we talking here? Server: 2x Intel Silver 4114 (10 cores, 20 threads each) 256GB RAM A zpool consisting of: - 17 three-way mirrors of 18TB Western Digital HC550=E2=80=99s, SAS - 2 three-way mirrors of 960GB Samsung PM9A3 nvme=E2=80=99s as special devi= ces Datastores: - 73 datastores - Total of 240T Allocated data Datastore that triggered my question: - 263 Groups - 2325 Snapshots - 60TB In use - Dedup factor of 19.3 >How many groups, how many snapshots (per group), many disks on backups? > >And what hardware is hosting that data (cpu, disk, memory). > >Hows PSI looking during listing? head /proc/pressure/* root@pbs003:/proc/pressure# head * =3D=3D> cpu <=3D=3D some avg10=3D0.74 avg60=3D0.58 avg300=3D0.21 total=3D8570917611 full avg10=3D0.00 avg60=3D0.00 avg300=3D0.00 total=3D0 =3D=3D> io <=3D=3D some avg10=3D20.45 avg60=3D23.93 avg300=3D27.69 total=3D176562636690 full avg10=3D19.25 avg60=3D22.69 avg300=3D26.82 total=3D165397148422 =3D=3D> memory <=3D=3D some avg10=3D0.00 avg60=3D0.00 avg300=3D0.00 total=3D67894436 full avg10=3D0.00 avg60=3D0.00 avg300=3D0.00 total=3D66761631 Currently running 9 tasks: - 3 Verifys - 1 Backup - 2 Syncjobs - 2 GC Runs - 1 Reader =E2=80=94 Mark Schouten, CTO Tuxis B.V. mark@tuxis.nl / +31 318 200208