Het grote zuinige server topic - deel 3

[I-Lynx]

Monitoring zat ik ook nog aan te denken. Maar weet nog niet helemaal hoe en waar dat zit.
En wat daar aan veranderd is sinds een week.

De ZFS mirror zit op 2 SATA SSD schijven.
Die mirror hangt aan de OMV VM.
Dit is een cold storage, Time Machine backup (SMB) en een wekelijkse backup van een Synology Nas (RSync).
Er is, behalve die paar uur per week, niet veel activiteit.

[RobertMe]

ramonlambal schreef op woensdag 5 november 2025 @ 22:49:
Je had ook een ZFS mirror ingesteld toch? op NVME? Dat betekend namelijk, als die een beetje hyperactief wil mirrororen je PCI-e states nooit naat beneden gaan natuurlijk, omdat de twee schijven constant van elkaar aan het lezen zijn of ze wel hetzelfde zijn, via de PCI bus.

Whut? Zolang er geen disk activiteit is gaat ZFS echt niet "hyperactief kijken of beide disks gelijk zijn". Schrijf acties worden sowieso dubbel gedaan, maar lees acties volgens mij niet. Immers is ZFS volledig met checksums. Op basis van 1 disk kan die dus prima bepalen of die corrupt is, want dan klopt de checksum niet (en in dit geval zal die terugvallen op het gebruik van een andere disk in de mirror).
Enige waarbij ZFS op de achtergrond bezig is is bij een scrub. Dan leest die wel alle data, valideert de checksums, etc. Maar dat draait natuurlijk niet 24/7, en moet je zelf aftrappen (, en mijn 3 way RAIDZ1 met 18TB als kleinste disk heeft nog geen 30 uur nodig om te scrubben. Mirror is vast sneller, NVME is veel sneller, en 18TB SSDs bestaan niet zijn onbetaalbaar)

[ramonlambal]

RobertMe schreef op woensdag 5 november 2025 @ 23:09:
[...]

Whut? Zolang er geen disk activiteit is gaat ZFS echt niet "hyperactief kijken of beide disks gelijk zijn". Schrijf acties worden sowieso dubbel gedaan, maar lees acties volgens mij niet. Immers is ZFS volledig met checksums. Op basis van 1 disk kan die dus prima bepalen of die corrupt is, want dan klopt de checksum niet (en in dit geval zal die terugvallen op het gebruik van een andere disk in de mirror).
Enige waarbij ZFS op de achtergrond bezig is is bij een scrub. Dan leest die wel alle data, valideert de checksums, etc. Maar dat draait natuurlijk niet 24/7, en moet je zelf aftrappen (, en mijn 3 way RAIDZ1 met 18TB als kleinste disk heeft nog geen 30 uur nodig om te scrubben. Mirror is vast sneller, NVME is veel sneller, en 18TB SSDs bestaan niet zijn onbetaalbaar)

Stel dat je logt naar 1 van die SSDs(proxmox houd allerlei gegevens bij toch?), dan moet die andere toch mirroren? Of kun je afdwingen dat die dat maar 1 keer in de x-minuten doet? Anders raak je data kwijt als de schijf die de meeste data bevat net stuk gaat? Stel dat je nieuwe mirror-ssd nou niet zo snel in lage PCI states wil komen, en hij constant moett mirroren, dan is die toch bijna steeds iets aan het doen waardoor die niet in C4 of lager komt?

ik heb bijvoorbeeld altijd 300+ torrents draaine, ik draai nooit idel, tot ik die uit zet, dan zit ik bijna direct in C8

[dcm360]

Proxmox logt wel wat intensief, maar zeker niet zo intensief dat een SSD niet het grootste deel van de tijd gewoon in een power saving state kan. Iedere seconde wat logs wegschrijven kan je beter vergelijken met eens in de maand een brief ontvangen, dan met rusteloos blijven doomscrollen op social media.

[tuxie6]

Ik zou bijna willen weten wat een oude installatie-iso zonder updates doet qua verbruik.

Een ssd mirror schrijft de logging en gaat in slaap, en zou dus nog maar <1 watt mogen gebruiken.

Wat verbruikt het geheel als je alleen proxmox opstart, zoals ik het begrijp heb je een passtrough gedaan van de sata controller naar ovm, wat zijn de instellingen binnen ovm.

Het valt me op dat veel besturingssystemen ingesteld staan op performance ipv belanced of goed voor de portemonnee als je op je zelf woont.

[I-Lynx]

Ter verduidelijking: De mirror is alleen voor OMV. Proxmox en alle VM's en Containers staan op een M.2 WD Green SSD.

De configs van de VM's:
Omada controller:

code:

arch: amd64
cores: 2
features: nesting=1
hostname: Omada-SDN
memory: 4096
net0: name=eth0,bridge=vmbr0,gw=10.0.14.254,hwaddr=BC:24:11:39:41:9B,ip=10.0.14.10/24,type=veth
onboot: 1
ostype: ubuntu
rootfs: local-lvm:vm-102-disk-0,size=8G
startup: order=3
swap: 512
tags: sdn
unprivileged: 1
lxc.cgroup2.cpuset.cpus: 14,15

Frigate:

code:

arch: amd64
cores: 4
features: nesting=1
hostname: frigate
memory: 4096
mp0: NVR:vm-103-disk-0,mp=/media/frigate,size=1860G
net0: name=eth0,bridge=vmbr0,firewall=0,gw=10.0.14.254,hwaddr=BC:24:11:CD:DC:11,ip=10.0.14.253/24,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-103-disk-0,size=50G
startup: order=4
swap: 512
tags: nvr
lxc.cgroup2.devices.allow: a
lxc.cap.drop: 
lxc.cgroup2.devices.allow: c 188:* rwm
lxc.cgroup2.devices.allow: c 189:* rwm
lxc.cgroup2.devices.allow: c 226:128 rwm
lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file
lxc.cgroup2.devices.allow: c 226:0 rwm
lxc.mount.entry: /dev/dri/card0 dev/dri/card0 none bind,optional,create=file
lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir
lxc.cgroup2.cpuset.cpus: "16-19"

pfSense (VM):

code:

balloon: 0
bios: ovmf
boot: order=scsi0;ide2
cores: 2
cpu: host
efidisk0: local-lvm:vm-100-disk-0,efitype=4m,pre-enrolled-keys=1,size=4M
ide2: none,media=cdrom
machine: q35
memory: 8192
meta: creation-qemu=10.0.2,ctime=1760360361
name: pfSense
net0: virtio=BC:24:11:76:CB:B1,bridge=vmbr0,queues=8
net1: virtio=BC:24:11:F9:1E:3E,bridge=vmbr0,queues=8,tag=6
net2: virtio=BC:24:11:DF:AB:AE,bridge=vmbr0,queues=8,tag=4
net3: virtio=BC:24:11:34:B3:5D,bridge=vmbr0,queues=8,tag=999
net4: virtio=BC:24:11:91:AF:77,bridge=vmbr0,queues=8,tag=101
net5: virtio=BC:24:11:E4:90:C5,bridge=vmbr0,queues=8,tag=102
net6: virtio=BC:24:11:63:BA:A8,bridge=vmbr0,queues=8,tag=105
numa: 0
onboot: 1
ostype: other
scsi0: local-lvm:vm-100-disk-1,cache=writeback,discard=on,iothread=1,size=32G
scsihw: virtio-scsi-single
smbios1: uuid=1c70b95f-ea58-4332-a909-3e5a9f7c62a0
sockets: 1
startup: order=1
tablet: 0
tags: pfsn
vmgenid: 214acf76-59f0-4134-8a02-4f0ffc855f07

OMV (VM)

code:

affinity: 12,13
boot: order=sata0;net0
cores: 2
cpu: x86-64-v2-AES
memory: 4096
meta: creation-qemu=10.0.2,ctime=1759254290
name: OMV
net0: virtio=BC:24:11:39:4B:CE,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
sata0: local-lvm:vm-105-disk-0,size=16G
sata1: OMV_Nas:vm-105-disk-0,size=3540G
scsihw: virtio-scsi-single
smbios1: uuid=cb3caa95-28a9-46a2-bf02-b96623f945c5
sockets: 1
startup: order=5
tablet: 0
tags: nas
vga: memory=4
vmgenid: 9c2e7172-3673-4619-ba3d-31523d659809

Home Assistant (VM)

code:

agent: enabled=1
bios: ovmf
boot: order=scsi0
cores: 4
efidisk0: local-lvm:vm-106-disk-1,efitype=4m,size=4M
localtime: 1
machine: q35
memory: 16384
meta: creation-qemu=10.0.2,ctime=1760273017
name: homeassistant
net0: virtio=02:BA:78:E2:30:CC,bridge=vmbr0
net1: virtio=BC:24:11:66:84:A1,bridge=vmbr0,tag=101
numa: 0
onboot: 1
ostype: l26
scsi0: local-lvm:vm-106-disk-0,discard=on,size=32G,ssd=1
scsihw: virtio-scsi-pci
serial0: socket
smbios1: uuid=643c3504-ab54-4a4b-9d47-e56356ce9fb3
sockets: 1
startup: order=2
tablet: 0
tags: homeassistant
usb0: host=0403:6001
usb1: host=10c4:ea70
usb2: host=0658:0200
vmgenid: ec53030a-6b86-4187-93fa-b5861dd68e0a