IO reach 12% with Laravel container backup

UK SPEED

Member
Dec 23, 2023
61
1
8
Hi guys

I have an issue with the Laravel container( almalinux & openlightspeed ), this container has a large number of files Laravel-OLS 1,472,694 files

When I try to tack backup through
Proxmox server I/O delay is high.
I/O delay: ( 26% )
1 minute: ( 80.52% )
5 minutes: ( 66.80% )
15 minutes: ( 52.11% )

1742733272488.png

There are no issues with the other four containers

MariaDB 176,879 files

Archive 88,316 files

Elasticsearch 374,677 files

Laravel-OLS 1,472,694 files

Can I overcome this issue by or/and

1- fresh installation of container.

2-Install VM rather than containers.

3- ِ Add another 2 storages for logs and cache to support the ZFS configuration.

4- I limited the IO anyway, which I tried to do through the picture below, but there was no success.

1742733036195.png



Any other suggestion to fix this issue, please.
 
Last edited:
the log of the issue


INFO: starting new backup job: vzdump 108 --storage OSF-Backup --notification-mode auto --notes-template '{{guestname}}' --node asus --remove 0 --mode snapshot
INFO: Starting Backup of VM 108 (lxc)
INFO: Backup started at 2025-03-23 18:52:02
INFO: status = running
INFO: CT Name: Laravel-OLS
INFO: including mount point rootfs ('/') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
INFO: creating Proxmox Backup Server archive 'ct/108/2025-03-23T15:52:02Z'
INFO: set max number of entries in memory for file-based backups to 1048576
INFO: run: lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client backup --crypt-mode=none pct.conf:/var/tmp/vzdumptmp2255425_108/etc/vzdump/pct.conf root.pxar:/mnt/vzsnap0 --include-dev /mnt/vzsnap0/./ --skip-lost-and-found --exclude=/tmp/?* --exclude=/var/tmp/?* --exclude=/var/run/?*.pid --backup-type ct --backup-id 108 --backup-time 1742745122 --entries-max 1048576 --repository root@pam@XX:XX
INFO: Starting backup: ct/108/2025-03-23T15:52:02Z
INFO: Client name: asus
INFO: Starting backup protocol: Sun Mar 23 18:52:03 2025
INFO: Downloading previous manifest (Fri Aug 16 06:00:01 2024)
INFO: Upload config file '/var/tmp/vzdumptmp2255425_108/etc/vzdump/pct.conf' to 'root@pam@XX:8007:capsula' as pct.conf.blob
INFO: Upload directory '/mnt/vzsnap0' to 'root@pam@XX.XX.XX.XX:8007:XX' as root.pxar.didx
INFO: processed 2.2 GiB in 1m, uploaded 1.075 GiB
INFO: processed 4.879 GiB in 2m, uploaded 2.086 GiB
INFO: processed 6.806 GiB in 3m, uploaded 3.419 GiB
INFO: processed 8.08 GiB in 4m, uploaded 4.592 GiB
INFO: processed 9.24 GiB in 5m, uploaded 5.756 GiB
INFO: processed 10.389 GiB in 6m, uploaded 6.914 GiB
INFO: processed 11.592 GiB in 7m, uploaded 8.084 GiB
INFO: processed 12.746 GiB in 8m, uploaded 9.2 GiB
INFO: processed 13.931 GiB in 9m, uploaded 10.389 GiB
INFO: processed 15.063 GiB in 10m, uploaded 11.569 GiB
INFO: processed 16.283 GiB in 11m, uploaded 12.769 GiB
INFO: processed 17.423 GiB in 12m, uploaded 13.983 GiB
INFO: processed 18.575 GiB in 13m, uploaded 15.145 GiB
INFO: processed 19.779 GiB in 14m, uploaded 16.225 GiB
INFO: processed 20.922 GiB in 15m, uploaded 17.496 GiB
INFO: processed 22.121 GiB in 16m, uploaded 18.592 GiB
INFO: processed 23.266 GiB in 17m, uploaded 19.853 GiB
INFO: processed 24.512 GiB in 18m, uploaded 20.941 GiB
INFO: processed 25.615 GiB in 19m, uploaded 22.153 GiB
INFO: processed 26.848 GiB in 20m, uploaded 23.317 GiB
INFO: processed 27.972 GiB in 21m, uploaded 24.509 GiB
INFO: processed 31.914 GiB in 22m, uploaded 27.888 GiB
INFO: processed 39.46 GiB in 23m, uploaded 35.566 GiB
INFO: processed 47.047 GiB in 24m, uploaded 43.046 GiB
INFO: processed 54.644 GiB in 25m, uploaded 50.433 GiB
INFO: processed 62.182 GiB in 26m, uploaded 57.834 GiB
INFO: processed 69.786 GiB in 27m, uploaded 65.253 GiB
INFO: processed 71.851 GiB in 28m, uploaded 67.551 GiB
INFO: processed 72.379 GiB in 29m, uploaded 68.071 GiB
INFO: processed 72.875 GiB in 30m, uploaded 68.577 GiB
INFO: processed 73.13 GiB in 31m, uploaded 68.831 GiB
INFO: processed 73.335 GiB in 32m, uploaded 69.027 GiB
INFO: processed 73.533 GiB in 33m, uploaded 69.239 GiB
INFO: processed 74.823 GiB in 34m, uploaded 69.563 GiB
INFO: processed 75.588 GiB in 35m, uploaded 70.949 GiB
 
this just means that the backup-client keeps your system busy reading the input data for the backup, this is not a bad thing ;)

if you have many files and not too much of them changing between backups, you might want to look at the metadata change detection mode, which should make the second and following runs much faster by skipping a lot of the read I/O for unchanged data.