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 7292B90F58 for ; Fri, 10 Mar 2023 10:40:36 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5540D1EA4B for ; Fri, 10 Mar 2023 10:40:06 +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 ; Fri, 10 Mar 2023 10:40:05 +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=V6oGo4iQ948AbnF7My9wnTzaP7u67e1umKhp1HHul+4=; b=H2s65DS/+gazvdCgxYuJ2QhLjz2ntN0EYBo1aqRrc/9kDx4azM1VCyCdWGBkLakscHy868zfDOcxR uRdrlnmJz9jmtNklmdss3d6svN2qe6w6dfcZquqpEFw+o905ZLjR2SyR9+o0xEIVGgKFfJkuupdohR 8L8zExlfm7EH8IF2JYAhAEl1LgptWt/VTgbiuNMq/BCjTECMglVnb3kCRFcYg7B9cBOHP+l0aHb9PL gBzMijOdg030suydjuHTNSSZ0ANXoS/ktanOEg8dzDSPDbTXFMd5j7+wPqYIJ3mkbokHBhFOBlVfJ4 GqsP5WDtbru/uMB1tZGnqvmjtK+z6jQ== X-Footer: dHV4aXMubmw= Received: from [IPv6:2a03:7900:64::1000] ([2a03:7900:64::1000]) (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)); Fri, 10 Mar 2023 10:09:48 +0100 From: "Mark Schouten" To: "Thomas Lamprecht" , "Proxmox Backup Server development discussion" Date: Fri, 10 Mar 2023 09:09:42 +0000 Message-Id: In-Reply-To: References: <11d3a67b-bc11-483f-c25b-2c6b634e4326@proxmox.com> Reply-To: "Mark Schouten" User-Agent: eM_Client/9.2.1608.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.037 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record 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: Fri, 10 Mar 2023 09:40:36 -0000 Hi all, any thought on this? =E2=80=94 Mark Schouten, CTO Tuxis B.V. mark@tuxis.nl / +31 318 200208 ------ Original Message ------ >From "Mark Schouten" To "Thomas Lamprecht" ; "Proxmox Backup Server=20 development discussion" Date 1/26/2023 9:03:24 AM Subject Re[2]: [pbs-devel] Slow overview of existing backups >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. The= re is nothing wrong with demanding your user to don=E2=80=99t touch any fil= es, except via the tooling you provide. And the tooling you provide, can hi= nt the service to rebuild the index. Same goes for upgrades, you are in cha= rge of them. > >We also need to regularly run garbage collection, which is a nice moment t= o update my desired index and check if it=E2=80=99s actually correct. On ev= ery backup run, delete, verify, you can update and check the index. Those a= re all moments a user is not actually waiting for it and getting timeouts,= refreshing screens, and other annoyances. > >> >>> I have the feeling that when you request an overview now, all individu= al backups are checked, which seems suboptimal. >> >>We mostly walk the directory structure and read the (quite small) manifes= t >>files for some info like last verification, but we do not check the backu= p >>(data) itself. >> >>Note that using namespaces for separating many backups into multiple fold= er >>can help, as a listing then only needs to check the indices from the name= space. >> >>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 dev= ices > >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