Bitmap sehr schnell dirty

[richardl]

Hallo,

Ich bin gerade dabei, von ZFS Snapshots auf PBS umzusteigen. Nun sehe ich bei manchen VMs, dass der Bitmap extrem dirty ist:

INFO: scsi0: dirty-bitmap status: OK (442.7 GiB of 852.0 GiB dirty), obwohl das letzte Backup vor einer halben Stunde durchgeführt wurde.

Normalerweise liegt die Dirty-Bitmap bei 20–50 GiB pro Stunde (obwohl tatsächlich nur ca. 500 MB geschrieben werden). Aber wie im obigen Beispiel ersichtlich, ist es jetzt plötzlich extrem schlimm: 50 % der Disk sollen geschrieben worden sein.

Leider konnte ich bisher nur einen ähnlichen Beitrag zu einer Windows-VM finden. In meinem Fall handelt es sich jedoch um eine DirectAdmin CloudLinux-Installation mit XFS und Discard auf ZFS.

Meine Versionen sind leider veraltet; ich plane, so schnell wie möglich ein Upgrade durchzuführen. Derzeit nutze ich folgende Versionen: Backup Server 2.4-7 und PVE 7.2-15.

Meine Fragen an euch:

1. Hat jemand schon einmal so etwas beobachtet?
2. Könnte die neue Version (PVE 8.3) mit den folgenden Features eine Lösung für dieses Problem sein?

New change detection modes for speeding up container backups to Proxmox Backup Server.

• Metadata and data of backup snapshots are now stored in two separate archives.
• Optionally, files that have not changed since the previous backup snapshot can be identified using the previous backup snapshot's metadata archive.
• Processing of unchanged files is avoided when possible, which can lead to significant reduction in backup runtime.
  
  
  

 

[fabian]

der change-detection mode bezieht sich auf file-basierte backups (container/host), nicht auf VM-backups..

kannst du noch mehr details zum storage setup in der VM posten? und einen ganzen backup task log?

 

[richardl]

Guten Morgen Fabian,

Danke. Ist ja logisch, hab das Wort "container" irgendwie nicht verarbeitet Dann muss ich mich keine Hoffnung machen mit diesem Punkt.

Hier ein Log mit ca 36GB an Änderungen auf der Festplatte, nach einer stunde;

2025-01-26T22:00:00+01:00: starting new backup on datastore 'backupstore1': "ns/CLIENTS/vm/107/2025-01-26T21:00:00Z"
2025-01-26T22:00:00+01:00: download 'index.json.blob' from previous backup.
2025-01-26T22:00:00+01:00: register chunks in 'drive-scsi0.img.fidx' from previous backup.
2025-01-26T22:00:00+01:00: download 'drive-scsi0.img.fidx' from previous backup.
2025-01-26T22:00:00+01:00: created new fixed index 1 ("ns/CLIENTS/vm/107/2025-01-26T21:00:00Z/drive-scsi0.img.fidx")
2025-01-26T22:00:00+01:00: add blob "/ssd_zfs/backupstore1/ns/CLIENTS/vm/107/2025-01-26T21:00:00Z/qemu-server.conf.blob" (399 bytes, comp: 399)
2025-01-26T22:09:36+01:00: Upload statistics for 'drive-scsi0.img.fidx'
2025-01-26T22:09:36+01:00: UUID: ed51ca9e569a41b5aa5c38e6c90e7b14
2025-01-26T22:09:36+01:00: Checksum: 2f79540cadf36ef771ac3fa85907da7c29a693279f3b1cd12773593c795ae4a5
2025-01-26T22:09:36+01:00: Size: 36926652416
2025-01-26T22:09:36+01:00: Chunk count: 8804
2025-01-26T22:09:36+01:00: Upload size: 36729520128 (99%)
2025-01-26T22:09:36+01:00: Duplicates: 47+3 (0%)
2025-01-26T22:09:36+01:00: Compression: 39%
2025-01-26T22:09:36+01:00: successfully closed fixed index 1
2025-01-26T22:09:36+01:00: add blob "/ssd_zfs/backupstore1/ns/CLIENTS/vm/107/2025-01-26T21:00:00Z/index.json.blob" (327 bytes, comp: 327)
2025-01-26T22:09:38+01:00: successfully finished backup
2025-01-26T22:09:38+01:00: backup finished successfully
2025-01-26T22:09:38+01:00: TASK OK

Ich hab das gestern auch noch mit einer anderen VM kontrolliert und bin zum gleichen Ergebnis gekommen. Was die beiden gemeinsam haben ist dat es Linux mit LVM ist. Die eine VM hat ext4 und die andere XFS. Beide kein SWAP. Auch wenn ich in die VM iostat anschau geht es um ca 0,5 - 2 MB writes pro Sekunde. Sogar wenn die dirty bitmap die gleichen Sektoren mehrere Mahle aufnehmen würde (was ich mir nicht vorstellen kann), stimmt die 36 GB nicht. Es wären dan maximaal 7 GB oder so.

bootdisk: scsi0
cores: 2
cpu: host
ide2: none,media=cdrom
memory: 4096
name: xxx-yyy-zzz
net0: virtio=0E:A8:F9:42:76:92,bridge=vmbr0,rate=30,tag=1053
numa: 0
onboot: 1
ostype: l26
parent: autohourly250127085404
scsi0: ssd_zfs:vm-199-disk-0,discard=on,iops_rd=2000,iops_rd_max=4000,iops_wr=2000,iops_wr_max=4000,mbps_rd=20,mbps_rd_max=40,mbps_wr=20,mbps_wr_max=40,size=250G
scsihw: virtio-scsi-pci
smbios1: uuid=45727837-e78e-41fd-8f8d-7fd3946bd5c5
sockets: 1
vmgenid: 4f39595e-3ba5-4270-8c16-7cbe095e03c3

Der node hat einen SSD mirrored ZFS pool.

Mit ZFS snapshots sieht man ganz schön das es in einer stunde nur ca 500MB an Änderungen auf der disk gibt (ich denke ca 5GB an Daten in tmp Tabellen für MySQL in 500MB an gleichen Sektoren).

Aber ZFS hat natürlich auch seine Nachteile und PBS ist halt schon ein hammer Produkt wenn ich es mir so anschaue. Wäre schön wenn ich der Fehler bin und es zu lösen ist

Danke

Richard

 

[fabian]

kannst du den PVE-seitigen task log zu dem backup auch noch posten?

und die lvm.conf aus der VM?

 

[richardl]

Danke,

Im Anhang das LVM conf (habe es .log genannt weil .conf nicht hochladen wollte). Ich hab da übrigens nichts geändert.

INFO: starting new backup job: vzdump 197 149 148 107 --quiet 1 --mailnotification failure --mailto xxx@xxx.yy --mode snapshot --storage BACKUP-clients --notes-template '{{guestname}}' --prune-backups 'keep-daily=6,keep-hourly=24,keep-monthly=4,keep-weekly=3'
INFO: skip external VMs: 148, 149, 197
INFO: Starting Backup of VM 107 (qemu)
INFO: Backup started at 2025-01-26 22:00:00
INFO: status = running
INFO: VM Name: xx-yy-zzzz
INFO: include disk 'scsi0' 'ssd_zfs:vm-107-disk-0' 852G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: snapshots found (not included into backup)
INFO: creating Proxmox Backup Server archive 'vm/107/2025-01-26T21:00:00Z'
INFO: started backup task '996bf4b6-3a55-46e7-a5d0-0085e70b939e'
INFO: resuming VM again
INFO: scsi0: dirty-bitmap status: OK (34.4 GiB of 852.0 GiB dirty)
INFO: using fast incremental mode (dirty-bitmap), 34.4 GiB dirty of 852.0 GiB total
INFO: 1% (400.0 MiB of 34.4 GiB) in 3s, read: 133.3 MiB/s, write: 133.3 MiB/s
INFO: 2% (748.0 MiB of 34.4 GiB) in 6s, read: 116.0 MiB/s, write: 116.0 MiB/s
INFO: 3% (1.1 GiB of 34.4 GiB) in 13s, read: 52.6 MiB/s, write: 52.6 MiB/s
INFO: 4% (1.4 GiB of 34.4 GiB) in 20s, read: 42.9 MiB/s, write: 42.9 MiB/s
INFO: 5% (1.7 GiB of 34.4 GiB) in 39s, read: 18.5 MiB/s, write: 18.3 MiB/s
INFO: 6% (2.1 GiB of 34.4 GiB) in 50s, read: 34.9 MiB/s, write: 34.9 MiB/s
INFO: 7% (2.5 GiB of 34.4 GiB) in 58s, read: 45.0 MiB/s, write: 45.0 MiB/s
INFO: 8% (2.8 GiB of 34.4 GiB) in 1m 8s, read: 32.4 MiB/s, write: 32.4 MiB/s
INFO: 9% (3.1 GiB of 34.4 GiB) in 1m 15s, read: 50.9 MiB/s, write: 50.9 MiB/s
INFO: 10% (3.5 GiB of 34.4 GiB) in 1m 22s, read: 49.7 MiB/s, write: 49.7 MiB/s
INFO: 11% (3.8 GiB of 34.4 GiB) in 1m 29s, read: 49.7 MiB/s, write: 48.6 MiB/s
INFO: 12% (4.2 GiB of 34.4 GiB) in 1m 36s, read: 55.4 MiB/s, write: 55.4 MiB/s
INFO: 13% (4.5 GiB of 34.4 GiB) in 1m 42s, read: 56.0 MiB/s, write: 55.3 MiB/s
INFO: 14% (4.8 GiB of 34.4 GiB) in 1m 54s, read: 28.7 MiB/s, write: 28.7 MiB/s
INFO: 15% (5.3 GiB of 34.4 GiB) in 1m 57s, read: 154.7 MiB/s, write: 145.3 MiB/s
INFO: 16% (5.5 GiB of 34.4 GiB) in 2m 1s, read: 62.0 MiB/s, write: 62.0 MiB/s
INFO: 17% (5.9 GiB of 34.4 GiB) in 2m 8s, read: 50.3 MiB/s, write: 50.3 MiB/s
INFO: 18% (6.2 GiB of 34.4 GiB) in 2m 14s, read: 56.7 MiB/s, write: 56.7 MiB/s
INFO: 19% (6.6 GiB of 34.4 GiB) in 2m 21s, read: 51.4 MiB/s, write: 51.4 MiB/s
INFO: 20% (6.9 GiB of 34.4 GiB) in 2m 28s, read: 53.7 MiB/s, write: 53.7 MiB/s
INFO: 21% (7.2 GiB of 34.4 GiB) in 2m 34s, read: 54.7 MiB/s, write: 54.7 MiB/s
INFO: 22% (7.6 GiB of 34.4 GiB) in 2m 46s, read: 32.3 MiB/s, write: 32.3 MiB/s
INFO: 23% (8.0 GiB of 34.4 GiB) in 2m 49s, read: 117.3 MiB/s, write: 113.3 MiB/s
INFO: 24% (8.3 GiB of 34.4 GiB) in 2m 55s, read: 50.7 MiB/s, write: 50.0 MiB/s
INFO: 25% (8.6 GiB of 34.4 GiB) in 3m 1s, read: 58.7 MiB/s, write: 58.7 MiB/s
INFO: 26% (9.0 GiB of 34.4 GiB) in 3m 7s, read: 62.7 MiB/s, write: 62.7 MiB/s
INFO: 27% (9.4 GiB of 34.4 GiB) in 3m 13s, read: 63.3 MiB/s, write: 62.7 MiB/s
INFO: 28% (9.7 GiB of 34.4 GiB) in 3m 18s, read: 61.6 MiB/s, write: 61.6 MiB/s
INFO: 29% (10.0 GiB of 34.4 GiB) in 3m 24s, read: 58.7 MiB/s, write: 58.7 MiB/s
INFO: 30% (10.4 GiB of 34.4 GiB) in 3m 32s, read: 47.5 MiB/s, write: 47.5 MiB/s
INFO: 31% (10.7 GiB of 34.4 GiB) in 3m 37s, read: 71.2 MiB/s, write: 71.2 MiB/s
INFO: 32% (11.1 GiB of 34.4 GiB) in 3m 51s, read: 29.1 MiB/s, write: 28.9 MiB/s
INFO: 33% (11.6 GiB of 34.4 GiB) in 3m 54s, read: 150.7 MiB/s, write: 150.7 MiB/s
INFO: 34% (11.8 GiB of 34.4 GiB) in 3m 57s, read: 98.7 MiB/s, write: 98.7 MiB/s
INFO: 35% (12.1 GiB of 34.4 GiB) in 4m 2s, read: 48.8 MiB/s, write: 48.8 MiB/s
INFO: 36% (12.4 GiB of 34.4 GiB) in 4m 8s, read: 62.7 MiB/s, write: 62.0 MiB/s
INFO: 37% (12.8 GiB of 34.4 GiB) in 4m 12s, read: 78.0 MiB/s, write: 78.0 MiB/s
INFO: 38% (13.1 GiB of 34.4 GiB) in 4m 18s, read: 64.0 MiB/s, write: 64.0 MiB/s
INFO: 39% (13.5 GiB of 34.4 GiB) in 4m 31s, read: 30.5 MiB/s, write: 30.5 MiB/s
INFO: 40% (14.0 GiB of 34.4 GiB) in 4m 34s, read: 152.0 MiB/s, write: 152.0 MiB/s
INFO: 41% (14.2 GiB of 34.4 GiB) in 4m 37s, read: 66.7 MiB/s, write: 64.0 MiB/s
INFO: 42% (14.5 GiB of 34.4 GiB) in 4m 44s, read: 46.3 MiB/s, write: 44.0 MiB/s
INFO: 43% (14.9 GiB of 34.4 GiB) in 4m 50s, read: 68.7 MiB/s, write: 62.7 MiB/s
INFO: 44% (15.1 GiB of 34.4 GiB) in 4m 54s, read: 66.0 MiB/s, write: 66.0 MiB/s
INFO: 45% (15.5 GiB of 34.4 GiB) in 5m, read: 63.3 MiB/s, write: 62.7 MiB/s
INFO: 46% (15.8 GiB of 34.4 GiB) in 5m 4s, read: 84.0 MiB/s, write: 84.0 MiB/s
INFO: 47% (16.2 GiB of 34.4 GiB) in 5m 11s, read: 50.3 MiB/s, write: 48.0 MiB/s
INFO: 48% (16.5 GiB of 34.4 GiB) in 5m 15s, read: 86.0 MiB/s, write: 85.0 MiB/s
INFO: 49% (16.9 GiB of 34.4 GiB) in 5m 21s, read: 63.3 MiB/s, write: 60.0 MiB/s
INFO: 50% (17.2 GiB of 34.4 GiB) in 5m 26s, read: 70.4 MiB/s, write: 70.4 MiB/s
INFO: 51% (17.6 GiB of 34.4 GiB) in 5m 33s, read: 56.6 MiB/s, write: 56.6 MiB/s
INFO: 52% (17.9 GiB of 34.4 GiB) in 5m 39s, read: 52.7 MiB/s, write: 52.7 MiB/s
INFO: 53% (18.3 GiB of 34.4 GiB) in 5m 45s, read: 62.0 MiB/s, write: 61.3 MiB/s
INFO: 54% (18.6 GiB of 34.4 GiB) in 5m 51s, read: 51.3 MiB/s, write: 50.7 MiB/s
INFO: 55% (19.0 GiB of 34.4 GiB) in 5m 56s, read: 84.8 MiB/s, write: 84.8 MiB/s
INFO: 56% (19.3 GiB of 34.4 GiB) in 6m, read: 67.0 MiB/s, write: 67.0 MiB/s
INFO: 57% (19.6 GiB of 34.4 GiB) in 6m 7s, read: 53.7 MiB/s, write: 53.7 MiB/s
INFO: 58% (19.9 GiB of 34.4 GiB) in 6m 12s, read: 65.6 MiB/s, write: 64.8 MiB/s
INFO: 59% (20.3 GiB of 34.4 GiB) in 6m 17s, read: 71.2 MiB/s, write: 71.2 MiB/s
INFO: 60% (20.6 GiB of 34.4 GiB) in 6m 24s, read: 51.4 MiB/s, write: 51.4 MiB/s
INFO: 61% (21.0 GiB of 34.4 GiB) in 6m 28s, read: 95.0 MiB/s, write: 95.0 MiB/s
INFO: 62% (21.4 GiB of 34.4 GiB) in 6m 34s, read: 61.3 MiB/s, write: 61.3 MiB/s
INFO: 63% (21.7 GiB of 34.4 GiB) in 6m 40s, read: 53.3 MiB/s, write: 53.3 MiB/s
INFO: 64% (22.0 GiB of 34.4 GiB) in 6m 45s, read: 68.8 MiB/s, write: 68.8 MiB/s
INFO: 65% (22.4 GiB of 34.4 GiB) in 6m 50s, read: 74.4 MiB/s, write: 74.4 MiB/s
INFO: 66% (22.7 GiB of 34.4 GiB) in 6m 56s, read: 58.7 MiB/s, write: 58.7 MiB/s
INFO: 67% (23.1 GiB of 34.4 GiB) in 7m 3s, read: 49.1 MiB/s, write: 49.1 MiB/s
INFO: 68% (23.4 GiB of 34.4 GiB) in 7m 9s, read: 61.3 MiB/s, write: 61.3 MiB/s
INFO: 69% (23.7 GiB of 34.4 GiB) in 7m 14s, read: 64.0 MiB/s, write: 64.0 MiB/s
INFO: 70% (24.1 GiB of 34.4 GiB) in 7m 19s, read: 82.4 MiB/s, write: 82.4 MiB/s
INFO: 71% (24.4 GiB of 34.4 GiB) in 7m 27s, read: 38.0 MiB/s, write: 38.0 MiB/s
INFO: 72% (24.9 GiB of 34.4 GiB) in 7m 30s, read: 154.7 MiB/s, write: 154.7 MiB/s
INFO: 73% (25.3 GiB of 34.4 GiB) in 7m 33s, read: 138.7 MiB/s, write: 138.7 MiB/s
INFO: 74% (25.5 GiB of 34.4 GiB) in 7m 36s, read: 78.7 MiB/s, write: 78.7 MiB/s
INFO: 75% (25.9 GiB of 34.4 GiB) in 7m 40s, read: 83.0 MiB/s, write: 83.0 MiB/s
INFO: 76% (26.2 GiB of 34.4 GiB) in 7m 44s, read: 89.0 MiB/s, write: 89.0 MiB/s
INFO: 77% (26.6 GiB of 34.4 GiB) in 7m 49s, read: 76.0 MiB/s, write: 76.0 MiB/s
INFO: 78% (26.9 GiB of 34.4 GiB) in 7m 53s, read: 77.0 MiB/s, write: 77.0 MiB/s
INFO: 79% (27.2 GiB of 34.4 GiB) in 8m 2s, read: 37.8 MiB/s, write: 37.8 MiB/s
INFO: 80% (27.6 GiB of 34.4 GiB) in 8m 5s, read: 129.3 MiB/s, write: 128.0 MiB/s
INFO: 81% (28.0 GiB of 34.4 GiB) in 8m 8s, read: 134.7 MiB/s, write: 134.7 MiB/s
INFO: 82% (28.2 GiB of 34.4 GiB) in 8m 12s, read: 69.0 MiB/s, write: 69.0 MiB/s
INFO: 83% (28.6 GiB of 34.4 GiB) in 8m 16s, read: 90.0 MiB/s, write: 90.0 MiB/s
INFO: 84% (28.9 GiB of 34.4 GiB) in 8m 20s, read: 79.0 MiB/s, write: 79.0 MiB/s
INFO: 85% (29.3 GiB of 34.4 GiB) in 8m 25s, read: 82.4 MiB/s, write: 82.4 MiB/s
INFO: 86% (29.6 GiB of 34.4 GiB) in 8m 32s, read: 38.9 MiB/s, write: 38.9 MiB/s
INFO: 87% (30.0 GiB of 34.4 GiB) in 8m 35s, read: 150.7 MiB/s, write: 150.7 MiB/s
INFO: 88% (30.3 GiB of 34.4 GiB) in 8m 38s, read: 108.0 MiB/s, write: 108.0 MiB/s
INFO: 89% (30.6 GiB of 34.4 GiB) in 8m 41s, read: 98.7 MiB/s, write: 98.7 MiB/s
INFO: 90% (31.0 GiB of 34.4 GiB) in 8m 46s, read: 79.2 MiB/s, write: 79.2 MiB/s
INFO: 91% (31.3 GiB of 34.4 GiB) in 8m 54s, read: 43.0 MiB/s, write: 43.0 MiB/s
INFO: 92% (31.8 GiB of 34.4 GiB) in 8m 57s, read: 145.3 MiB/s, write: 145.3 MiB/s
INFO: 93% (32.1 GiB of 34.4 GiB) in 9m, read: 116.0 MiB/s, write: 116.0 MiB/s
INFO: 94% (32.3 GiB of 34.4 GiB) in 9m 3s, read: 80.0 MiB/s, write: 80.0 MiB/s
INFO: 95% (32.7 GiB of 34.4 GiB) in 9m 8s, read: 69.6 MiB/s, write: 69.6 MiB/s
INFO: 96% (33.0 GiB of 34.4 GiB) in 9m 13s, read: 69.6 MiB/s, write: 69.6 MiB/s
INFO: 97% (33.4 GiB of 34.4 GiB) in 9m 18s, read: 71.2 MiB/s, write: 71.2 MiB/s
INFO: 98% (33.7 GiB of 34.4 GiB) in 9m 23s, read: 71.2 MiB/s, write: 71.2 MiB/s
INFO: 99% (34.1 GiB of 34.4 GiB) in 9m 28s, read: 72.0 MiB/s, write: 72.0 MiB/s
INFO: 100% (34.4 GiB of 34.4 GiB) in 9m 32s, read: 81.0 MiB/s, write: 81.0 MiB/s
INFO: backup was done incrementally, reused 817.80 GiB (95%)
INFO: transferred 34.39 GiB in 579 seconds (60.8 MiB/s)
INFO: adding notes to backup
INFO: prune older backups with retention: keep-daily=6, keep-hourly=24, keep-monthly=4, keep-weekly=3
INFO: running 'proxmox-backup-client prune' for 'vm/107'
INFO: pruned 0 backup(s)
INFO: Finished Backup of VM 107 (00:09:39)
INFO: Backup finished at 2025-01-26 22:09:39
INFO: Backup job finished successfully
TASK OK

 

[fabian]

okay, und eine letzte frage noch - "mount" output aus der VM?

 

[richardl]

Gerne. Ist halt ein chaos mit dem cgroups von cloudlinux. Auch so viel wie möglich relatime benutzt. Aber... in der anderen VM mit dem gleichen Problem ist das mit den vielen mounts/cgroups nicht so, und nur ext4 + LVM so ganz "vanilla". Also denke das es nichts damit zu tun hat.

rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime,gid=1004,hidepid=2 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=24633500k,nr_inodes=6158375,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/ve cgroup rw,nosuid,nodev,noexec,relatime,ve 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_prio,net_cls 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/beancounter cgroup rw,nosuid,nodev,noexec,relatime,beancounter 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/mapper/centos-root / xfs rw,relatime,attr2,inode64,noquota 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=26,pipe_ino=8407,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=8407 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
none /var/lve/dbgovernor-shm tmpfs rw,nosuid,nodev,relatime,mode=777 0 0
/dev/sda1 /boot xfs rw,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-home /home xfs rw,nosuid,relatime,attr2,inode64,usrquota,prjquota 0 0
/dev/mapper/centos-tmplv /tmp xfs rw,nosuid,noexec,relatime,attr2,inode64,noquota 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
devpts /usr/share/cagefs-skeleton/dev/pts devpts rw,nosuid,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/lib xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/lib64 xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/opt xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/include xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/lib xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/lib64 xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/local/directadmin/shared xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/local/lib/php xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/share/l.v.e-manager/cl.nodejs xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/share/l.v.e-manager/cl.python xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/share/locale xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/share/man xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/share/terminfo xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/usr/share/zoneinfo xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/var/lib/mysql xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/var/lib/proxyexec/cagefs.sock xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/var/passenger xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
tmpfs /usr/share/cagefs-skeleton/run/dbus tmpfs rw,nosuid,mode=755 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/var/spool/at xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/var/www/cgi-bin xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/var/www/html xfs rw,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/opt/suphp/sbin xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
/dev/mapper/centos-root /usr/share/cagefs-skeleton/var/lve/lveinfo.ver.cagefs xfs ro,nosuid,relatime,attr2,inode64,noquota 0 0
proc /usr/share/cagefs-skeleton/proc proc rw,nosuid,relatime,gid=1004,hidepid=2 0 0
systemd-1 /usr/share/cagefs-skeleton/proc/sys/fs/binfmt_misc autofs rw,relatime,fd=26,pipe_ino=8407,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=8407 0 0
binfmt_misc /usr/share/cagefs-skeleton/proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,relatime 0 0
tmpfs /run/user/0 tmpfs rw,nosuid,nodev,relatime,size=4929148k,mode=700 0 0

 

[fabian]

ich vermute das problem ist, dass XFS default ohne discard laeuft (ext4 im uebrigen auch), d.h. temporaere files machen die disk auch dirty wenn sie schon wieder geloescht sind.. du koenntest testweise mal "fstrim -av" direkt vor dem backup ausfuehren und schauen ob das was bringt?

 

[richardl]

Danke, werde das machen.

trimfs ist bewust nicht eingeschaltet und dreht über cron. Aber wer weiss was für Einfluss das hat. Trotzdem komisch das ZFS snapshots das problem nicht haben. Die sollten ja wie das bitmap nichts van der storage in der VM wissen und es pur als "raw blockstorage" sehen.

Bin auch dran eine neue VM zu machen um so aus zo schliessen das es eventuell daran liegt das die ZFS noch unterliegende snapshots hat. Sollte ja nichts ausmachen, weil es theoretisch nichts mit dem Bitmap zu tun hat von Qemu. Mal schauen.

Ich melde mich wieder. Danke für die schnelle Antworten.

 

[fabian]

ja, ZFS und bitmap operieren auf ganz anderem level. vielleicht den ZFS output nicht korrekt interpretiert? oder die ZFS compression reduziert die effektive usage einfach enorm..

 

[richardl]

Also, fstrim -av hatte als Resultat das fast die ganze bitmap dirty wurde. Wahrscheinlich weil die Blocks die nicht gebraucht wurden, kurz markiert wurden. Ist eigentlich nicht schlimm, weil das eigentlich auch die einzige Weise ist dem PBS zu sagen das die Blöcke lehr sind. Die werden ja dann als lehr gelesen. Bis PBS irgendwie das trimfs commando's interpretieren kann, ist das nehme ich an eine gute Sache und wenn mann das über cron ein mahl im Monat mach ganz OK. Aber es löst mein Problem leider nicht.

Das mounten mit discard, hat eigentlich kein wirklichen unterschied gemacht. Mit und ohne discard sehe ich diese interessante Erscheinung:

1. ich schreibe 10 MB random IO so wie MySQL das machen würde in tmp Tabellen:

#!/bin/bash

# Directory to store the temp files
TEMP_DIR="/tmp/mysql_sim"
mkdir -p $TEMP_DIR

# Initialize total bytes counter
TOTAL_BYTES_WRITTEN=0

# Simulate MySQL temporary table writes
for ((i=1; i<=10000; i++)); do
    # Generate random file name
    FILENAME="$TEMP_DIR/tmp_table_$RANDOM"

    # Write random data to temp files and calculate bytes written
    dd if=/dev/urandom of=$FILENAME bs=4K count=4 oflag=dsync status=none
    BYTES_WRITTEN=$((4 * 4096))  # Calculate bytes written for this write (4 KB blocks * 4 count)
    TOTAL_BYTES_WRITTEN=$((TOTAL_BYTES_WRITTEN + BYTES_WRITTEN))

    # Simulate frequent deletions and re-writes
    if (( $i % 10 == 0 )); then
        rm -f $TEMP_DIR/tmp_table_*
    fi

    # Print progress every 100 writes
    if (( $i % 100 == 0 )); then
        # Convert total bytes to MB for display
        TOTAL_MB_WRITTEN=$(echo "scale=2; $TOTAL_BYTES_WRITTEN / 1024 / 1024" | bc)
        echo "Progress: $i writes completed. Total data written so far: $TOTAL_MB_WRITTEN MB."
    fi

    sleep 0.005  # Adjust this delay as needed
done

# Final output
TOTAL_MB_WRITTEN=$(echo "scale=2; $TOTAL_BYTES_WRITTEN / 1024 / 1024" | bc)
echo "Simulation completed. Total data written: $TOTAL_MB_WRITTEN MB."

# Cleanup
rm -rf $TEMP_DIR

Das macht ca 250 MB dirty in den bitmap! Obwohl nur 10 MB geschrieben wurde.

2. schreibe ich 10 MB mit

dd if=/dev/urandom of=testfile bs=1M count=10

wird ca 10 - 20 MB dirty.

Ich denke dat der unterschied kommt weil der bitmap eine standart "granularity" hat van 64K aber ZFS von 8k. Ist es möglich diesen Wert an zu passen? Und was meint ihr dazu?

 

[fabian]

ZFS liegt ja ueber der bitmap ist also erstmal "egal". wenn du 16k schreibst in der VM, wird das in 1-4 bloecken passieren (4k standardbloeckgroesse vom dateisystem), und dementsprechend 1-4 bits in der bitmap als dirty markiert werden. jedes bit entspricht dabei 64k, d.h. im worst case hast du damit 4*64k als dirty markiert, also nen faktor 16 drauf. in deinem beispiel schreibst du ja 10000 * 16K , also 156MB (nicht 10?), da ist ein overhead von nicht ganz 2x gar nicht so schlecht.. wirkt aber ein bisschen so, als haettest du da ein pathologisches access pattern dass dazu fuehrt, dass die (temporaeren) writes gut ueber die disk verteilt werden..

du kannst natuerlich auch mit den bloeckgroessen in der VM spielen, aber im normalfall verschiebst du dadurch das problem nur.. ist der pfad fuer die temporaeren writes konfigurierbar? dann waere ein verschieben auf eine nicht gesicherte disk eventuell auch ein ansatz..

 

[richardl]

Hallo Fabian,

Danke für deine Antwort. Ich denke, die Schätzung Faktor 16x ist realistisch.

Die temporären Writes sind, glaube ich, nicht wirklich konfigurierbar, ohne Risiken einzugehen. Vielleicht eine RAM-Disk oder so, aber das würde ich lieber nicht angehen. Ganz am Anfang meines Posts habe ich einen Vorfall besprochen, bei dem viel mehr dirty war:

INFO: scsi0: dirty-bitmap status: OK (442.7 GiB of 852.0 GiB dirty)

Aber wer weiß, vielleicht war das eine cron-getriggerte fstrim…

Wie auch immer, ich denke, dass diese Situation anscheinend in gewissen Fällen auftaucht und für mich leider ein "breaking issue" ist (was ja auch kein Bug ist, sondern eine Folge des Bitmaps).

PBS ist ansonsten wirklich unglaublich gut! Ich denke, ich probiere trotzdem mal, etwas zu basteln – mit ZFS-Snapshots und Replikation zu einem Offsite-Server, der eine längere Retention hat als das lokale ZFS vdev. So kann ich lokal nur eine Woche Retention haben und offsite mehr. Mal gucken, ob das funktioniert.

Danke für deine Zeit und Mühe, auch an euer Team, das ein Hammer-Produkt (PVE und PBS) entwickelt. Wird wirklich geschätzt!

 

[fabian]

prinzipiell waere es glaube ich auch moeglich, die bitmap granularitaet fuer solche use cases konfigurierbar zu machen (ist halt ein tradeoff zwischen memory usage/.. und amplification)

@fiona ?

 

[richardl]

Automatische Erkennung der Blockgröße und Anpassung an die Bitmap-Granularität des zugrunde liegenden Speichers – vielleicht eine Idee?

So gut wie die Redirect-on-Write (RoW) Snapshots von ZFS wird es wahrscheinlich nicht werden, aber die wenigsten nutzen ZFS, oder? Ich erinnere mich, dass meine leistungsstarken Datenbank-Server auf qcow mit offenen Snapshots nicht gut funktioniert haben, weshalb ich damals auf ZFS umgestiegen bin. Allerdings lag das meiner Meinung nach eher am Copy-on-Write (CoW) von qcow als an der Bitmap selbst, die vermutlich einen viel geringeren Einfluss hat.

Mit der Standardgranularität von PBS habe ich jedenfalls bisher keine merkbare Verlangsamung festgestellt. Abgesehen vom fstrim-„Problem“ könnte das also möglicherweise gut funktionieren.

In meinem Fall benutze ich 8k Blockgrösse auf ZFS.

 

[fiona]

Hi,

prinzipiell waere es glaube ich auch moeglich, die bitmap granularitaet fuer solche use cases konfigurierbar zu machen (ist halt ein tradeoff zwischen memory usage/.. und amplification)

@fiona ?

ja könnte theoretisch exposed werden, hätte dann halt Auswirkungen auf den ganzen Backup-Stack und müsste verifiziert werden, dass das überall richtig gehandhabt wird. Z.B. kann kein inkrementelles Backup gemacht werden nachdem die Granularität geändert wurde.

Und der Verbrauch vom RAM steigt mit abnehmender Blockgröße. Wenn statt 4 MiB Blockgröße nur 8 KiB verwendet würde, braucht die Bitmap dann soweit ich weiß circa 512 mal so viel Speicher (jede Halbierung der Blockgröße sollte essentiell eine Verdoppelung der Bitmap-Größe sein).

 

[fabian]

stimmt, beim backup verwenden wir ja eine bitmap mit 4MB granularity um die fixed-size chunks zu matchen, nicht die standard 64k bitmap die sonst default ist.. damit verschiebt sich die berechnung oben natuerlich deutlich!

das groessere problem wird aber sein dass eine reduktion der granularitaet ohne aenderung der chunk groesse ja gar nichts bringt.. und da koennen wir definitv nicht in richtung kilobyte gehen ohne massive skalierungsprobleme..

koenntest du noch den task log vom backup direkt nach dem fstrim posten?

 

[richardl]

Es tut mir leid, ich kann das Log nicht mehr finden Ich habe noch mit meinem ISP telefoniert und die haben mit purem lokalen Storage nicht solche Probleme. Also ich denke das es auch mit ZFS schlimmer wird. Combination ZFS mit viel kleinen writes und PBS ist nicht ideaal anscheinend.

 

[Johannes S]

Es tut mir leid, ich kann das Log nicht mehr finden Ich habe noch mit meinem ISP telefoniert und die haben mit purem lokalen Storage nicht solche Probleme. Also ich denke das es auch mit ZFS schlimmer wird. Combination ZFS mit viel kleinen writes und PBS ist nicht ideaal anscheinend.

Das würde mich wundern, es gibt hier doch diverse Leute, die ZFS mit PBS (auch in einer VM) einsetzen. Warum sollte das dann nicht klappen?

 

[richardl]

Hallo Johannes, es klapt auch. Immer. Bei vielen VMs auch wunderbar. Aber wie hier beschrieben gibt es halt in gewissen fällen Einfluss auf die benötigten Resourcen. Wer weiss spielt auch LVM eine rolle.

Mit einem 4MB bitmap ist das ja auch nicht so komisch das ZFS mit seine komplexere Metadata und 8k (viel kleiner als 4MB) Sektoren sich effizienter die geschriebene daten merken kann seit dem letzten backup.

Reproduzierbar ist es so:

1. VM mit Debian 12 und LVM machen
2. PBS Backup erstellen
3. Script was hier gepostet ist benutzen um viele kleine random writes zu machen => ca 10MB sollte reichen
4. nochmal ein Backup erstellen und dabei die Grösse des bitmaps / daten Übertragung anschauen und vergleichen mit dem Total an Daten das geschrieben wurde vom script. Resultat is factor 10+ Schreibeamplification (100 - 200MB an neue daten übers Netz zum PBS)

Ich hab selber auch ZFS snapshots noch "laufen" aber glaube kaum das das etwas ausmacht

Glaube das es in vielen Fallen gar kein problem is. Wenn mann nur ein mal am Tag Backups macht und die hardware ist gut, ist das absolut kein problem.

Bin aber neugierig ob jemand mit einem "guten" setup, das Script auch drehen kann ohne al zu grosse Amplification. Es könnte ja durchaus sein das das Problem was ich beschreibe jedem in ein gewissen Masse betrifft, aber es einfach niemand aufgefallen ist (und darum auch kein wirkliches Problem darstellt für die meisten). Wollte einfach mal fragen ob das jemanden aufgefallen ist.