Het grote zuinige server topic - deel 3

[DaanHetEendje]

Mars Warrior schreef op vrijdag 10 oktober 2025 @ 11:26:
[...]

Red Hat is goed in het maken van dingen volgens hun eigen manier, die niet altijd compatible zijn met al bestaande applicaties, terwijl ze vaak wel claimen dat het een drop-in replacement is.

Podman is gewoon niet 100% compatible met Docker. En je krijgt garantie tot de voordeur, ondanks service contracten

Maar aan de andere kant is expermenteren leuk. De enige reden dat ik weet dat Podman niet compatible is met wat ik/wij gebruiken, is namelijk omdat ik er mee gespeeld heb. Maar wie weet in de toekomst is het een mooi alternatief voor het Docker eco systeem

Op reddit word ik downvoted als de pest als ik benoem dat Podman absoluut geen drop-in replacement voor docker is omdat het allerlei functionaliteit mist. Maar het is gewoon de realiteit.

Ik zit nu naar nerdctl te kijken als docker vervanger. Dat is een cli tool voor containerd om containertjes te spawnen die ook als doel heeft om docker cli compatible te zijn. En dan geen gare red hat meuk op mijn machines

[RobertMe]

DaanHetEendje schreef op maandag 13 oktober 2025 @ 13:07:
Ik zit nu naar nerdctl te kijken als docker vervanger. Dat is een cli tool voor containerd om containertjes te spawnen die ook als doel heeft om docker cli compatible te zijn. En dan geen gare red hat meuk op mijn machines

Maar ondersteund het ook Quadlets?

Containers definiëren in een systemd unit file is eigenlijk best wel cool. Waarbij individuele containers dus ook kunnen wachten op specifieke zaken (ook van buiten containers dus). Ik heb nu bv Gatus draaien als "uptime checker", maar na een reboot faalt die op een aantal services die die over een VPN moet bereiken omdat de VPN nog niet up is. Met Quadlets kan ik gewoon een Wants=systemd-networkd-wait-online@wg-mesh + After=systemd-networkd-wait-online@wg-mesh toevoegen en klaar. Deze container start pas nadat deze netwerk interface online is. Met Docker kan ik dat niet. Dan zou ik met het handje een docker run ... in een systemd service moeten plaatsen incl goed uitzoeken hoe om te gaan met zaken als stoppen, bijhouden active state, etc (en uiteraard niet Dockers restart optie gebruiken) zodat ik specifiek die unit de afhankelijkheid kan geven. Want uiteraard kan/wil ik niet de hele Docker daemon de afhankelijkheid van één enkele container geven.
Maar dus ook uberhaupt dat alles veel meer "native" voelt. Een container starten/stoppen kan gewoon met systemctl restart gatus bv. Logging gaat automatisch naar de system logs (journald, en dus doorzoekbaar met bv journalctl -u gatus). Standaard monitoring tools voor systemd nemen dus automatisch ook containers mee (of de service aka container wel active is, logging dan, ...).

Dus nee, ik ben niet getrouwd met Podman of vind het super vet cool omdat het van Red Hat is. Maar Quadlets is wel een feature waar ik de voordelen van in zie en die AFAIK geen enkel alternatief heeft.

[Shivs]

DaanHetEendje schreef op maandag 13 oktober 2025 @ 13:07:
[...]
Ik zit nu naar nerdctl te kijken als docker vervanger. Dat is een cli tool voor containerd om containertjes te spawnen die ook als doel heeft om docker cli compatible te zijn. En dan geen gare red hat meuk op mijn machines

Hoewel ik snap dat je niet met Podman wilt werken, heb je zeker wel Red Hat meuk op je machines. De kernel wordt mede door Red Hat ontwikkelt, dus je komt er niet echt onderuit (https://insights.linuxfou...project/korg/contributors)

[Mars Warrior]

RobertMe schreef op maandag 13 oktober 2025 @ 15:41:
[...]

Maar ondersteund het ook Quadlets?

Containers definiëren in een systemd unit file is eigenlijk best wel cool. Waarbij individuele containers dus ook kunnen wachten op specifieke zaken (ook van buiten containers dus). Ik heb nu bv Gatus draaien als "uptime checker", maar na een reboot faalt die op een aantal services die die over een VPN moet bereiken omdat de VPN nog niet up is. Met Quadlets kan ik gewoon een Wants=systemd-networkd-wait-online@wg-mesh + After=systemd-networkd-wait-online@wg-mesh toevoegen en klaar. Deze container start pas nadat deze netwerk interface online is. Met Docker kan ik dat niet. Dan zou ik met het handje een docker run ... in een systemd service moeten plaatsen incl goed uitzoeken hoe om te gaan met zaken als stoppen, bijhouden active state, etc (en uiteraard niet Dockers restart optie gebruiken) zodat ik specifiek die unit de afhankelijkheid kan geven. Want uiteraard kan/wil ik niet de hele Docker daemon de afhankelijkheid van één enkele container geven.
Maar dus ook uberhaupt dat alles veel meer "native" voelt. Een container starten/stoppen kan gewoon met systemctl restart gatus bv. Logging gaat automatisch naar de system logs (journald, en dus doorzoekbaar met bv journalctl -u gatus). Standaard monitoring tools voor systemd nemen dus automatisch ook containers mee (of de service aka container wel active is, logging dan, ...).

Dus nee, ik ben niet getrouwd met Podman of vind het super vet cool omdat het van Red Hat is. Maar Quadlets is wel een feature waar ik de voordelen van in zie en die AFAIK geen enkel alternatief heeft.

Ik heb wel eens een container gedraaid die dat soort zaken kon checken, dus of bijv. VPN/Netwerk op is, en pas DAARNA naar healthy gaat.

Als je dan een depends on doet in de andere container op basis van "healthy", dan kun je via een omweg toch bereiken wat jij wilt.

Het is wel één van de dingen die Podman tracht op te lossen, naast dat ze zich eerder richten op Kubernetes, dan Docker Swarm of Docker Compose.

[I-Lynx]

I-Lynx schreef op zaterdag 4 oktober 2025 @ 10:33:
Ik heb ondertussen weer wat tijd gehad om te proberen.

De bios instellingen van @Bontje Blauw over genomen.
Dat gaf geen merkbaar verschil.

Daarna alle onderdelen stuk voor stuk eruit gehaald en weer terug geplaatst.
De basis was 24 watt.
Zonder Netwerkkaart: 18 watt.
Zonder Netac SSD: 15 watt

We zijn weer een ruime week verder.
Het systeem draait nu volledig.
De netwerkkaart en Netac SSD zijn eruit. De SSD is vervangen voor een 2e WD Green 512gb SSD die ik nog had liggen.

Zoals in mijn vorige post gemeld komt het idle verbruik met alle apparatuur aan, zonder VM's en Containers in Proxmox rond de 15 watt.

Nu alles VM's en containers draaien is het verbruik toegenomen tot ongeveer 35 watt.
Er draait nu het volgende:
VM: pfSense
VM: Home Assistant
VM: Open Media Vault
CT: Omada controller
CT: Frigate.

De containers heb ik voor zover mogelijk op de E-Cores ingesteld.
Ook Frigate draait op de E-Core's.

Dit is mijn Powertop:

code:

           Pkg(HW)  |            Core(HW) |            CPU(OS) 0   CPU(OS) 1
                    |                     | C0 active   4.3%        3.3%
                    |                     | POLL        0.0%    0.1 ms  0.0%    0.1 ms
                    |                     | C1_ACPI    17.9%    0.2 ms  3.9%    0.1 ms
C2 (pc2)    0.0%    |                     | C2_ACPI    33.7%    0.4 ms 13.6%    0.6 ms
C3 (pc3)    0.0%    | C3 (cc3)    0.0%    | C3_ACPI    43.8%    1.6 ms 79.0%    5.8 ms
C6 (pc6)    0.0%    | C6 (cc6)    2.7%    |
C7 (pc7)    0.0%    | C7 (cc7)   15.8%    |
C8 (pc8)    0.0%    |                     |
C9 (pc9)    0.0%    |                     |
C10 (pc10)  0.0%    |                     |

                    |            Core(HW) |            CPU(OS) 2   CPU(OS) 3
                    |                     | C0 active   4.3%        1.2%
                    |                     | POLL        0.1%    0.1 ms  0.1%    0.1 ms
                    |                     | C1_ACPI    20.8%    0.2 ms  4.4%    0.2 ms
                    |                     | C2_ACPI    36.0%    0.4 ms 15.5%    0.5 ms
                    | C3 (cc3)    0.0%    | C3_ACPI    39.1%    1.5 ms 78.8%    5.6 ms
                    | C6 (cc6)    1.1%    |
                    | C7 (cc7)   10.4%    |
                    |                     |
                    |                     |
                    |                     |

Zelfs met alleen pfSense VM (als ik die uitzet dan hebben we geen internet meer en heb ik ruzie thuis ) blijft bovenstaande het zelfde.

Ik doe dus iets fout.... maar wat...
Het enige wat qua hardware veranderd is, is dat de USB > Serial devices voor Z-Wave, P1 meter en UPS zijn ingeplugd.

Al met al is het totale verbruik van de oude situatie (Chineese router, Synology nas etc) gedaald van 90watt naar 50 watt (server plus PoE Switch).
Dus het is al wel een verbetering maar het kan beter.

Nog een kleine test:
Alleen pfSense en Home Assistant draaien: 30 watt.
Omada controller erbij: 32 watt
OMV erbij: 32 watt
Frigate erbij: 35 watt. Afhankelijk of de camera's beweging detecteren.

We gaan nog wat stoeien met E-Cores.

[Appesteijn]

I-Lynx schreef op maandag 13 oktober 2025 @ 21:37:
[...]

We zijn weer een ruime week verder.
Het systeem draait nu volledig.
De netwerkkaart en Netac SSD zijn eruit. De SSD is vervangen voor een 2e WD Green 512gb SSD die ik nog had liggen.

Zoals in mijn vorige post gemeld komt het idle verbruik met alle apparatuur aan, zonder VM's en Containers in Proxmox rond de 15 watt.

Nu alles VM's en containers draaien is het verbruik toegenomen tot ongeveer 35 watt.
Er draait nu het volgende:
VM: pfSense
VM: Home Assistant
VM: Open Media Vault
CT: Omada controller
CT: Frigate.

De containers heb ik voor zover mogelijk op de E-Cores ingesteld.
Ook Frigate draait op de E-Core's.

Dit is mijn Powertop:

code:

           Pkg(HW)  |            Core(HW) |            CPU(OS) 0   CPU(OS) 1
                    |                     | C0 active   4.3%        3.3%
                    |                     | POLL        0.0%    0.1 ms  0.0%    0.1 ms
                    |                     | C1_ACPI    17.9%    0.2 ms  3.9%    0.1 ms
C2 (pc2)    0.0%    |                     | C2_ACPI    33.7%    0.4 ms 13.6%    0.6 ms
C3 (pc3)    0.0%    | C3 (cc3)    0.0%    | C3_ACPI    43.8%    1.6 ms 79.0%    5.8 ms
C6 (pc6)    0.0%    | C6 (cc6)    2.7%    |
C7 (pc7)    0.0%    | C7 (cc7)   15.8%    |
C8 (pc8)    0.0%    |                     |
C9 (pc9)    0.0%    |                     |
C10 (pc10)  0.0%    |                     |

                    |            Core(HW) |            CPU(OS) 2   CPU(OS) 3
                    |                     | C0 active   4.3%        1.2%
                    |                     | POLL        0.1%    0.1 ms  0.1%    0.1 ms
                    |                     | C1_ACPI    20.8%    0.2 ms  4.4%    0.2 ms
                    |                     | C2_ACPI    36.0%    0.4 ms 15.5%    0.5 ms
                    | C3 (cc3)    0.0%    | C3_ACPI    39.1%    1.5 ms 78.8%    5.6 ms
                    | C6 (cc6)    1.1%    |
                    | C7 (cc7)   10.4%    |
                    |                     |
                    |                     |
                    |                     |

Zelfs met alleen pfSense VM (als ik die uitzet dan hebben we geen internet meer en heb ik ruzie thuis ) blijft bovenstaande het zelfde.

Ik doe dus iets fout.... maar wat...
Het enige wat qua hardware veranderd is, is dat de USB > Serial devices voor Z-Wave, P1 meter en UPS zijn ingeplugd.

Al met al is het totale verbruik van de oude situatie (Chineese router, Synology nas etc) gedaald van 90watt naar 50 watt (server plus PoE Switch).
Dus het is al wel een verbetering maar het kan beter.

Nog een kleine test:
Alleen pfSense en Home Assistant draaien: 30 watt.
Omada controller erbij: 32 watt
OMV erbij: 32 watt
Frigate erbij: 35 watt. Afhankelijk of de camera's beweging detecteren.

We gaan nog wat stoeien met E-Cores.

Toevallig ook vorige week geprobeerd om een vergelijkbare setup met opnsense en Home Assistant met een USB P1 meter en een USB Zigbee eraan in C1 of beter te krijgen. Niet gelukt.

Lang verhaal kort:
De USB devices en het netwerkverkeer zorgden ervoor dat het systeem niet in C1 kwam. P1 meter nog wel vervangen door een Esphome-Wifi versie, maar dat mocht niet baten.

[RobertMe]

Appesteijn schreef op maandag 13 oktober 2025 @ 21:43:
[...]


Toevallig ook vorige week geprobeerd om een vergelijkbare setup met opnsense en Home Assistant met een USB P1 meter en een USB Zigbee eraan in C1 of beter te krijgen. Niet gelukt.

Mijn N5105 based router doet wel gewoon C8 voor 1,5% , alle percentages opgeteld ~30% dus 70% actief. Waarbij ik mij af vraag hoeveel verlies je niet maakt door een VM te draaien (met een *Sense variant). Alhoewel er volgens mij ook ervaringen waren dat Proxmox + *Sense zuiniger is/kan zijn dan *Sense bare metal. Dus je kunt er wel iets mee winnen ten opzichte van BSD dat "nog slechtere" power management heeft.

Dit doet mij overigens wel meteen "twijfelen" of ik wel "ooit" een all-in-one bak moet gaan bouwen met een i5 of zo die ook als firewall dienst doet. Als die onder internet gebruik in zo'n lage C-states blijft. Betekend dus gewoon dat er vele watts op zouden gaan puur aan "internet verkeer afhandelen" terwijl een low power bakje (of zelfs een dual NIC SBCtje) dan veel zuiniger zou zijn en een "grote bak" veel meer in de hoge C-states kan zijn.

[tuxie6]

I-Lynx schreef op maandag 13 oktober 2025 @ 21:37:
[...]

We zijn weer een ruime week verder.
Het systeem draait nu volledig.
De netwerkkaart en Netac SSD zijn eruit. De SSD is vervangen voor een 2e WD Green 512gb SSD die ik nog had liggen.

Zoals in mijn vorige post gemeld komt het idle verbruik met alle apparatuur aan, zonder VM's en Containers in Proxmox rond de 15 watt.

Nu alles VM's en containers draaien is het verbruik toegenomen tot ongeveer 35 watt.
Er draait nu het volgende:
VM: pfSense
VM: Home Assistant
VM: Open Media Vault
CT: Omada controller
CT: Frigate.

De containers heb ik voor zover mogelijk op de E-Cores ingesteld.
Ook Frigate draait op de E-Core's.

Dit is mijn Powertop:

code:

           Pkg(HW)  |            Core(HW) |            CPU(OS) 0   CPU(OS) 1
                    |                     | C0 active   4.3%        3.3%
                    |                     | POLL        0.0%    0.1 ms  0.0%    0.1 ms
                    |                     | C1_ACPI    17.9%    0.2 ms  3.9%    0.1 ms
C2 (pc2)    0.0%    |                     | C2_ACPI    33.7%    0.4 ms 13.6%    0.6 ms
C3 (pc3)    0.0%    | C3 (cc3)    0.0%    | C3_ACPI    43.8%    1.6 ms 79.0%    5.8 ms
C6 (pc6)    0.0%    | C6 (cc6)    2.7%    |
C7 (pc7)    0.0%    | C7 (cc7)   15.8%    |
C8 (pc8)    0.0%    |                     |
C9 (pc9)    0.0%    |                     |
C10 (pc10)  0.0%    |                     |

                    |            Core(HW) |            CPU(OS) 2   CPU(OS) 3
                    |                     | C0 active   4.3%        1.2%
                    |                     | POLL        0.1%    0.1 ms  0.1%    0.1 ms
                    |                     | C1_ACPI    20.8%    0.2 ms  4.4%    0.2 ms
                    |                     | C2_ACPI    36.0%    0.4 ms 15.5%    0.5 ms
                    | C3 (cc3)    0.0%    | C3_ACPI    39.1%    1.5 ms 78.8%    5.6 ms
                    | C6 (cc6)    1.1%    |
                    | C7 (cc7)   10.4%    |
                    |                     |
                    |                     |
                    |                     |

Zelfs met alleen pfSense VM (als ik die uitzet dan hebben we geen internet meer en heb ik ruzie thuis ) blijft bovenstaande het zelfde.

Ik doe dus iets fout.... maar wat...
Het enige wat qua hardware veranderd is, is dat de USB > Serial devices voor Z-Wave, P1 meter en UPS zijn ingeplugd.

Al met al is het totale verbruik van de oude situatie (Chineese router, Synology nas etc) gedaald van 90watt naar 50 watt (server plus PoE Switch).
Dus het is al wel een verbetering maar het kan beter.

Nog een kleine test:
Alleen pfSense en Home Assistant draaien: 30 watt.
Omada controller erbij: 32 watt
OMV erbij: 32 watt
Frigate erbij: 35 watt. Afhankelijk of de camera's beweging detecteren.

We gaan nog wat stoeien met E-Cores.

Staat pfsense nog op performance, dit is default tegenover adaptive of powersave, op de nieuwerwetse cpu's kan hij gewoon op powersave staan tegenover de atom heeft een i-core iets meer oempf

Als je vm's draait zul je die appart op zuinigheid moeten controleren, 1 voor 1 draaien en wattage checken op een wattmeter.

Usb device's zijn niet perse zuinig. Soms is een apparte espwifi to Homeassistent oplossing zuiniger als een usbtje in de server steken.
Controleer dit per usb device.
Ook proxmox staat volgens mij default op performance het kan schelen om deze op balanced of powersave te zetten.

[Mich]

RobertMe schreef op maandag 13 oktober 2025 @ 22:45:
[...]

Mijn N5105 based router doet wel gewoon C8 voor 1,5% , alle percentages opgeteld ~30% dus 70% actief. Waarbij ik mij af vraag hoeveel verlies je niet maakt door een VM te draaien (met een *Sense variant). Alhoewel er volgens mij ook ervaringen waren dat Proxmox + *Sense zuiniger is/kan zijn dan *Sense bare metal. Dus je kunt er wel iets mee winnen ten opzichte van BSD dat "nog slechtere" power management heeft.

Dit doet mij overigens wel meteen "twijfelen" of ik wel "ooit" een all-in-one bak moet gaan bouwen met een i5 of zo die ook als firewall dienst doet. Als die onder internet gebruik in zo'n lage C-states blijft. Betekend dus gewoon dat er vele watts op zouden gaan puur aan "internet verkeer afhandelen" terwijl een low power bakje (of zelfs een dual NIC SBCtje) dan veel zuiniger zou zijn en een "grote bak" veel meer in de hoge C-states kan zijn.

Ik in proxmox alleen mijn opnsense vm aanzet blijf ik nog steeds op +-45% c10 hangen. Maar het klopt wel, doe je er nog een vm of 2 bij ben je helemaal uit je power states, maar het kan dan nog steeds "zuinig" draaien door de goede basis.

[Appesteijn]

RobertMe schreef op maandag 13 oktober 2025 @ 22:45:
[...]

Dit doet mij overigens wel meteen "twijfelen" of ik wel "ooit" een all-in-one bak moet gaan bouwen met een i5 of zo die ook als firewall dienst doet. Als die onder internet gebruik in zo'n lage C-states blijft. Betekend dus gewoon dat er vele watts op zouden gaan puur aan "internet verkeer afhandelen" terwijl een low power bakje (of zelfs een dual NIC SBCtje) dan veel zuiniger zou zijn en een "grote bak" veel meer in de hoge C-states kan zijn.

Ik draai op Proxmox:
- OPNSense (VM)
- Home Assistant (VM) (Met nog 1 Zzigbee USB device direct passthrough)
- Debian met 4 dockers (VM)
- TrueNAS (VM) (twee hdd's direct passthrough)
- Immich (LXC)
- PiHole (LXC)
- Vaultwarden (LXC)
- Omada (LXC)

In powertop houden de X550-T2 netwerkkaart, het USB device en de NVME schijf waar alle VM's op draaien allemaal 100% waardoor ik heel af en toe 0.3% in C1 zit. Dit is ongeveer 45-50 Watt minimaal.

[RobertMe]

RobertMe schreef op maandag 13 oktober 2025 @ 22:45:
[...]

Mijn N5105 based router doet wel gewoon C8 voor 1,5% , alle percentages opgeteld ~30% dus 70% actief. Waarbij ik mij af vraag hoeveel verlies je niet maakt door een VM te draaien (met een *Sense variant). Alhoewel er volgens mij ook ervaringen waren dat Proxmox + *Sense zuiniger is/kan zijn dan *Sense bare metal. Dus je kunt er wel iets mee winnen ten opzichte van BSD dat "nog slechtere" power management heeft.

Dit doet mij overigens wel meteen "twijfelen" of ik wel "ooit" een all-in-one bak moet gaan bouwen met een i5 of zo die ook als firewall dienst doet. Als die onder internet gebruik in zo'n lage C-states blijft. Betekend dus gewoon dat er vele watts op zouden gaan puur aan "internet verkeer afhandelen" terwijl een low power bakje (of zelfs een dual NIC SBCtje) dan veel zuiniger zou zijn en een "grote bak" veel meer in de hoge C-states kan zijn.

Blijkbaar komt dat door qBittorrent. Als ik dan toch een zelfbouw router heb met gewoon Debian kan ik ook mijn netwerk ontlasten door op de router de Linux ISOs binnen te halen Als ik die stop doet die alleen al ~30% C8 (hoger komt die nog steeds niet, maar C8 vs C10 zal ook niet het verschil maken). In verbruik lijkt het met kort testen ook niet uit te maken. Smartplug met UPS met daarop router + Ziggo modem + PoE switch (met daarop access point + kleine switch + Tado bridge via PoE) blijft 35, 36W verbruiken. Lijkt dus niet iets te zijn dat echt verschil maakt in daadwerkelijk stroomverbruik.

[spoor12b]

@Mich zojuist eindelijk eraan toegekomen om dit te proberen:

nano /etc/modprobe.d/i915.conf (en de andere stappen). Het had helaas geen resultaat maar altijd goed om te proberen.

@mrmrmr zojuist ook re-size bar support ingeschakeld maar dat hielp helaas ook niet.

Wellicht ga ik nog een post doen, de 6.10 kernel heeft helaas hetzelfde probleem. Dit terwijl het eerder wel werkte. Is ongetwijfeld een combinatie van meerdere factoren.

Voor nu gaat de NAS toch maar weer terug naar z'n oude plek want die pruttelende geluiden van de array heb ik nu wel gehoord

Wel als maatregel in de BIOS de GT max frequency van 1200mHz naar 200 teruggebracht. Scheelt wellicht ook weer nu het systeem dit niet zelf kan regelen.

[I-Lynx]

tuxie6 schreef op dinsdag 14 oktober 2025 @ 09:13:
[...]


Staat pfsense nog op performance, dit is default tegenover adaptive of powersave, op de nieuwerwetse cpu's kan hij gewoon op powersave staan tegenover de atom heeft een i-core iets meer oempf

Als je vm's draait zul je die appart op zuinigheid moeten controleren, 1 voor 1 draaien en wattage checken op een wattmeter.

Usb device's zijn niet perse zuinig. Soms is een apparte espwifi to Homeassistent oplossing zuiniger als een usbtje in de server steken.
Controleer dit per usb device.
Ook proxmox staat volgens mij default op performance het kan schelen om deze op balanced of powersave te zetten.

pfSense staat alles op Powersafe
Proxmox staat ook op Powersafe
De USB Devices zijn een Z-Wave USB Stick (aeotec z-Stick 10 pro), een USB P1 kabel (is volgens mij een USB serieel dingetje) en de EATON UPS.
De UPS hangt direct aan Proxmox met NUT server.
De andere 2 USB devices zijn passthrough naar HA.

Ik zal de overige VM's en CT's nog eens na lopen. Misschien dan OMV ook nog wel wat te tweaken valt.

[bjp]

Mars Warrior schreef op zondag 12 oktober 2025 @ 22:38:
[...]
en on-demand containers kunnen starten en stoppen. Dat was ook een reden om Traefik te gaan gebruiken. Of dat lekker werkt en het verbruik nog iets kan verminderen is afwachten.

dat lijkt me een prima reden! ik zoek zoiets voor NginxProxyManager on proxmox om CT/VM's op te starten/pauzeren wanneer niet nodig.

Bijvoorbeeld nextcloud, jellyfin of zo. Geen access -> geen verbruik. Zou tof zijn.

[Mars Warrior]

bjp schreef op woensdag 15 oktober 2025 @ 19:51:
[...]
dat lijkt me een prima reden! ik zoek zoiets voor NginxProxyManager on proxmox om CT/VM's op te starten/pauzeren wanneer niet nodig.

Bijvoorbeeld nextcloud, jellyfin of zo. Geen access -> geen verbruik. Zou tof zijn.

Dit gaat zuiver over containers: https://sablierapp.dev/#/

Deze heeft dus wel plug-ins voor allerhande proxies. Maar ik zie bij de providers enkel containers staan.

[janvdw]

Momenteel heb ik een server draaien met Ubuntu 24.04.3 LTS (headless, geen GUI) op een samenraapsel van oude hardware:

• MSI B250
• intel i5-7500
• 16 GB RAM
• M.2 SSD 128 GB (OS)
• intel SATA SSD 500GB (Ebay) (voor Docker containers)
• HDD 2 TB (Frigate opslag)
• HDD 2 TB (*Linux Distro's* en persoonlijke foto's)
• Coral TPU in PCI extension card
• Be Quiet PSU350w

Volgende Dockers actief en half te bereiken via eigen domein (Cloudflare > Caddy) of Wireguard VPN op Unifi Ultra Gateway:

• Portainer
• Beszel
• downloadtools voor *distro's* met Gluetun
• Nextcloud AIO
• Ghostfolio
• Actual budget
• HomeAssistant (via een Zwave stick voor aansturen van zwave verlichtingsschakelaars en meldingen van Frigate)
• Frigate (3 camera's)
• Immich
• Arr*
• Emby
• Caddy

Dit trekt gemiddeld 32 Watt uit het stopcontact met continue opname door camera's.

Backups van belangrijkste zaken (vooral de foto's) lopen via rsync naar Hetzner storage box. De opbouw is wat organisch gegroeid en misschien is herinstalleren van proxmox met VM (backup volledige VM) en een RAID-Z* oplossing interessanter. Ik vermoed dat het niet interessant is om Frigate naar de RAID-Z pool te laten schrijven? Kwestie van verbruik en meerdere schijven te verslijten?

[buell]

Hallo,
Ik gebruik proxmox op mijn Odroid h4+ en die heb ik nu ongeveer 100 dagen met compleet nieuwe hardware. Wat mij vandaag opvalt is dat ik in de smart result een wearout krijg van 1% op mijn SSD. Dit lijkt erg snel mijn inziens. Ik draai over de laatste maanden enkel Pfsense, Homeassistant, Omada controller en een fileserver. volgens mij niet erg intensieve taken. temperatuur van de SSD is overigens vrij stabiel rond de 35 graden.






Ik gebruik al jaren proxmox en het viel me in mijn vorige setup ook op dat ik een wearout had maar die starte met een nieuwe ssd al op 10%. Ik dacht dat het in dit geval aan de SSD lag maar nu zie ik het weer met comleet nieuwe hardware.

Zijn er meerdere die dit zelfde fenomeen hebben en moet ik me hier zorgen gaan maken? (wellichtbegrijp ik de term Wear out verkeerd)

[GioStyle]

Ik voorzie geen problemen, ik heb het ook en ervaar het als normaal gedrag. Een ssd moet je ook meer zien als een gebruiksvoorwerp waar je 'tijdelijk' je data opslaat en gebruikt.

[dcm360]

Als ik dat extrapoleer kom je ook nog uit op een verwachte levensduur van meer dan 25 jaar, gebaseerd op de writes. Dat valt toch best mee?

[buell]

dcm360 schreef op woensdag 22 oktober 2025 @ 12:14:
Als ik dat extrapoleer kom je ook nog uit op een verwachte levensduur van meer dan 25 jaar, gebaseerd op de writes. Dat valt toch best mee?

Heb je denk ik helemaal gelijk in. Ik vroeg me gewoon af stel de waarde is 50% of dat dit dan ook dataverlies geeft? Zo niet laat ik hem lekker de komende jaren door pruttelen zo en vervang ik hem wel na een jaartje of 10.
Achteraf had ik wellicht beter een kleinere SSD kunnen nemen. Ik gebruik hem nu maar voor 25%. Heb een deel van mijn files op de SSD staan waar ik vaker toegang tot nodig heb.

Mijn sata controller is via PCI passtrough doorgegeven aan Truenas. Daar hangen op dit moment 2 5Tb 2,5inch segate diskjes aan. die gaan automatish in spindown om het verbruik te verminderen. Die data heb ik echt maar sporadisch nodig.

overigens zit mijn totate setup full running op 11 watt. (brensthull meter)
Pfsense
Home assistant met 3 usb aansluitingen (Zwave, Zigbee en P1)
Influxdb (container)
Truenas
Omada (Container) controler voor de wifi accecpoins.

Ik heb er powertop op gezet en vermoed dat het nog wel iets zuiniger kan maar ben overall meer dan tevreden.

Hiervoor had ik een supermicro server met een continue verbruik van 25 tot 35 watt.
Ik heb hem nog staan en weet nog niet wat ik er mee ga doen. Onlangs ff kaal proxmox geinstalleerd en dan zit ik op 17 watt met spindown. Blijft wel een beest vergeleken met de odroid.

#	Categorie	Product	Prijs	Subtotaal
1	Processors	Intel Xeon E3-1230 v6 Boxed	€ 362,40	€ 362,40
1	Moederborden	Supermicro X11SSH-LN4F	€ 0,-	€ 0,-
4	Interne harde schijven	WD Red WD30EFRX, 3TB	€ 139,-	€ 556,-
1	USB/Opslag-controllers	Conceptronic PCI Express Card SATA 600	€ 32,99	€ 32,99
1	Behuizingen	Fractal Design Define R5 Zwart	€ 123,17	€ 123,17
1	Kabels	Startech.com 4x SATA Power Splitter Adapter Cable (PYO4SATA)	€ 5,90	€ 5,90
1	Processorkoeling	Noctua NH-U9B SE2	€ 0,-	€ 0,-
1	Ventilators	be quiet! Pure Wings 2, 140mm	€ 0,-	€ 0,-
4	Geheugen intern	Kingston ValueRAM KVR21E15D8/16	€ 0,-	€ 0,-
1	Voedingen	Cooler Master V Series V550	€ 0,-	€ 0,-
1	Interne SSD's	Samsung 960 EVO 250GB	€ 94,90	€ 94,90
			Totaal	€ 1.175,36

[Mars Warrior]

buell schreef op woensdag 22 oktober 2025 @ 11:34:
Hallo,
Ik gebruik proxmox op mijn Odroid h4+ en die heb ik nu ongeveer 100 dagen met compleet nieuwe hardware. Wat mij vandaag opvalt is dat ik in de smart result een wearout krijg van 1% op mijn SSD. Dit lijkt erg snel mijn inziens. Ik draai over de laatste maanden enkel Pfsense, Homeassistant, Omada controller en een fileserver. volgens mij niet erg intensieve taken. temperatuur van de SSD is overigens vrij stabiel rond de 35 graden.

[Afbeelding]
[Afbeelding]


Ik gebruik al jaren proxmox en het viel me in mijn vorige setup ook op dat ik een wearout had maar die starte met een nieuwe ssd al op 10%. Ik dacht dat het in dit geval aan de SSD lag maar nu zie ik het weer met comleet nieuwe hardware.

Zijn er meerdere die dit zelfde fenomeen hebben en moet ik me hier zorgen gaan maken? (wellichtbegrijp ik de term Wear out verkeerd)

Mijn Black in mijn PC:

code:

WD_BLACK SN770 2TB --------------------------------------------------------

 [Algemene informatie]
  Schijfstationcontroller:                NVMe (PCIe 4x 16.0 GT/s)
  Hostcontroller:                         Sandisk, Device ID: 5017
  Schijfmodel:                            WD_BLACK SN770 2TB
  Aandrijvingscapaciteit:                 1,907,729 MBytes (2000 GB)
 [Mogelijkheden]
 [Self-Monitoring, Analysis and Reporting Technology (S.M.A.R.T.)]
  Beschikbare ruimte onder drempel:       Normaal
  Temperatuur overschrijdt kritische drempel: Normaal
  Apparaatbetrouwbaarheid verslechterd:   Normaal
  Media in alleen-lezen modus:            Normaal
  Vluchtig geheugenback-upapparaat mislukt: Normaal
  Schijftemperatuur:                      32  C
  Waarschuwingstemperatuurdrempel:        84  C
  Kritische temperatuurdrempel:           88  C
  Tijd boven waarschuwingstemperatuurdrempel: 0 minuten
  Tijd boven kritische temperatuurdrempel: 0 minuten
  Reservecapaciteit beschikbaar:          100%
  Apparaatstatus:                         98%
  Vermogenscycli:                         1398
  Inschakeluren:                          1294 uur
  Onveilige afsluitingen:                 65
  Mediafouten:                            0
  Totaal aantal gelezen host:             72539 GBytes
  Totaal aantal hostschrijfacties:        73732 GBytes

Dat is dus 2% in 2 jaar waarbij totaal 73TB is geschreven, zo'n 36TB / jaar.
Lijkt minder slijtage dan wat jij hebt (dit zou 100 jaar gebruik betekenen), maar niks zorgwekkends volgens mij.

[dcm360]

buell schreef op woensdag 22 oktober 2025 @ 12:29:
[...]


Heb je denk ik helemaal gelijk in. Ik vroeg me gewoon af stel de waarde is 50% of dat dit dan ook dataverlies geeft? Zo niet laat ik hem lekker de komende jaren door pruttelen zo en vervang ik hem wel na een jaartje of 10.

Zou dat niet een beetje vreemd zijn, halverwege de levensduur al niet meer geschikt zijn voor opslag van data? Volgens de specificaties mag je er immers (zonder dat je problemen verwacht) 3PB naar wegschrijven.

[RobertMe]

Mars Warrior schreef op woensdag 22 oktober 2025 @ 12:30:
[...]

Mijn Black in mijn PC:

code:

WD_BLACK SN770 2TB --------------------------------------------------------

 [Algemene informatie]
  Schijfstationcontroller:                NVMe (PCIe 4x 16.0 GT/s)
  Hostcontroller:                         Sandisk, Device ID: 5017
  Schijfmodel:                            WD_BLACK SN770 2TB
  Aandrijvingscapaciteit:                 1,907,729 MBytes (2000 GB)
 [Mogelijkheden]
 [Self-Monitoring, Analysis and Reporting Technology (S.M.A.R.T.)]
  Beschikbare ruimte onder drempel:       Normaal
  Temperatuur overschrijdt kritische drempel: Normaal
  Apparaatbetrouwbaarheid verslechterd:   Normaal
  Media in alleen-lezen modus:            Normaal
  Vluchtig geheugenback-upapparaat mislukt: Normaal
  Schijftemperatuur:                      32  C
  Waarschuwingstemperatuurdrempel:        84  C
  Kritische temperatuurdrempel:           88  C
  Tijd boven waarschuwingstemperatuurdrempel: 0 minuten
  Tijd boven kritische temperatuurdrempel: 0 minuten
  Reservecapaciteit beschikbaar:          100%
  Apparaatstatus:                         98%
  Vermogenscycli:                         1398
  Inschakeluren:                          1294 uur
  Onveilige afsluitingen:                 65
  Mediafouten:                            0
  Totaal aantal gelezen host:             72539 GBytes
  Totaal aantal hostschrijfacties:        73732 GBytes

Dat is dus 2% in 2 jaar waarbij totaal 73TB is geschreven, zo'n 36TB / jaar.
Lijkt minder slijtage dan wat jij hebt (dit zou 100 jaar gebruik betekenen), maar niks zorgwekkends volgens mij.

Maar jij gebruikt ook geen Proxmox. Proxmox is nogal schrijf intensief doordat die zeer regelmatig statistieken opslaat (CPU-, geheugen-, schijf- verbruik per LXC / VM).

Het stoppen van die statistieken daemon scheelt dus vast nogal in hoe veel er geschreven wordt (en ook in energieverbruik doordat systeem veel meer idle kan blijven).

[buell]

RobertMe schreef op woensdag 22 oktober 2025 @ 13:11:
[...]

Maar jij gebruikt ook geen Proxmox. Proxmox is nogal schrijf intensief doordat die zeer regelmatig statistieken opslaat (CPU-, geheugen-, schijf- verbruik per LXC / VM).

Het stoppen van die statistieken daemon scheelt dus vast nogal in hoe veel er geschreven wordt (en ook in energieverbruik doordat systeem veel meer idle kan blijven).

dus als ik het goed begrijp het volgende uitvoeren?
systemctl disable pvestatd

en uiteraard als het systeem aan blijft
systemctl stop pvestatd

[RobertMe]

buell schreef op woensdag 22 oktober 2025 @ 13:14:
[...]

dus als ik het goed begrijp het volgende uitvoeren?
systemctl disable pvestatd

en uiteraard als het systeem aan blijft
systemctl stop pvestatd

Of combineren met systemctl disable --now pvestatd (overigens niet gecontroleerd of het daadwerkelijk de juiste service naam is, maar het klinkt wel correct).

En uiteraard zul je daarna geen / lege grafieken in het dashboard / de WebUI hebben.

[Mars Warrior]

Mars Warrior schreef op dinsdag 7 oktober 2025 @ 11:10:
Zo. Ff een update van het gemiddelde verbruik van mijn server vanaf Juli 2023...
De verschillende kleuren komen (denk ik) door reboots en container (Telegraf/Influx) updates.

Je ziet duidelijk een oplopende trend. Ooit kreeg ik de gemiddelde package-power op/onder de 2W, maar nieuwe containers (nu 50), wijzigingen/updates van containers en Ubuntu kunnen voor wisselend verbruik zorgen. Sommigen voegen plotseling een (voor mij onnodige) health-check toe - en dus toenemend verbruik, waar anderen die health-check plotseling weer verwijderen - en dus afnemend verbruik.

Het blijkt ook dat een aantal containers af en toe controleren of je één van de laatste versies draait: als dat niet zo is, dan worden ze drukker blijkbaar, want na updaten is het verbruik gewoon lager!

Al met al ga ik weer richting de 6W qua gemiddeld package-power verbruik. Een factor 3 meer dan waar ik in 2023 mee begon, maar aan de andere kant is het ook een illusie dat zware containers "gratis" zijn. Die zijn er eind 2024/begin 2025 bijgekomen. En dat is duidelijk te zien aan het gemiddelde verbruik.

Ik ben er nog niet achter waarom Ubuntu nu in ACPI mode draait, dus het kan zijn dat als Ubuntu weer gewoon in C-states draait (hopelijk c6-c10), dat het gemiddelde verbruik nog iets zakt.

Met 50 containers zal het geen 2W meer worden, maar 1-2W minder is weer leuk meegenomen.

De energierekening is nog steeds ca 400kWh/jaar lager dan met de oude server(s), dus nog steeds erg tevreden met deze setup op basis van een 13900K (8P + 16E) waarbij het grote aantal E-cores voor een significante kWh besparing zorgen tov alles op P-cores draaien.

[Afbeelding]

Zo. 7 oktober was ik al blij dat ik door health checks uit te zetten weer gemiddeld van 9W naar de 6W package power ging, en vroeg ik me af of het nog minder kon worden...

Nou ja, blijkbaar wel! Het is nu een week geleden dat ik CrowdSec heb geinstalleerd en getuned als firewall en Traefik als proxy. De bodem zit nu op 2,8W en het gemiddelde op 3,9W. Dat is bijna de oranje lijn (ca 3W) van 1 jaar geleden.



Het vroeg tegenhouden van al dat gerammel aan de poort scheelt gewoon duidelijk CPU cycles

Vanaf 16 oktober zit ik nu op 118 alerts per dag. En zoals je ziet gaat dit gewoon de hele dag door. Zo'n 60% van de 'aanvallen' is op IP adres (en dus kansloos), en de overige 40% is op een domein gericht.

Een Alert overigens komt gemiddeld voort uit 4 events, dus er wordt minimaal 470 keer per dag aan de poort gerammeld van mijn zuinige server
In de firewall staan nu 92 actieve bans, oftewel IP adressen die direct geblokkeerd worden als ze langskomen. En dat in 1 weekje De top-3 landen zijn Amerika, Engeland en Japan.

[PuijkeN]

bjp schreef op woensdag 15 oktober 2025 @ 19:51:
[...]


dat lijkt me een prima reden! ik zoek zoiets voor NginxProxyManager on proxmox om CT/VM's op te starten/pauzeren wanneer niet nodig.

Bijvoorbeeld nextcloud, jellyfin of zo. Geen access -> geen verbruik. Zou tof zijn.

Met Traefik en een soort "watchdog" container kan je zoiets vrij eenvoudig fixen, ik heb dit gedaan voor mijn Webtop container automatisch af te sluiten nadat er 15 minuten geen connectie is.

Samengevat, de watchdog-webtop container draait altijd, de webtop container staat standaard uit. In de watchdog container draaien 2 scripts die er voor zorgen dat de webtop container stopt indien er 15 minuten geen connectie is op de inkomende poort (van de webtop container) en anderzijds indien de webtop container uit staat en er een inkomende connectie is op de wactchdog container hij de webtop container opstart.

Verder zit de logica gewoon in Traefik waar je 2 containers dezelfde host rule kan geven maar een verschillende prioriteit. Tenzij de webtop container uit staat, zal verkeer altijd naar die container gaan (prio 20). Als de container uit staat wordt het verkeer naar de watchdog container gestuurd, welke de webtop container zal opstarten.

Watchdog container traefik docker-compose stukje:

code:

      traefik.http.routers.webtop-proxy.entrypoints: websecure
      traefik.http.routers.webtop-proxy.rule: Host(`webtop.domein.be`)
      traefik.http.routers.webtop-proxy.tls: true
      traefik.http.routers.webtop-proxy.tls.certresolver: wildcard-godaddy
      traefik.http.routers.webtop-proxy.priority: 10
      traefik.http.routers.webtop-proxy.tls.domains[0].main: "*.domein.be"
      traefik.http.services.webtop-proxy.loadbalancer.server.port: 5000
      traefik.enable: true

Webtop container traefik docker-compose stukje:

code:

      traefik.http.routers.webtop-secure.entrypoints: websecure
      traefik.http.routers.webtop-secure.rule: Host(`webtop.domein.be`)
      traefik.http.routers.webtop-secure.tls: true
      traefik.http.routers.webtop-secure.tls.certresolver: wildcard-godaddy
      traefik.http.routers.webtop-secure.priority: 20
      traefik.http.routers.webtop-secure.tls.domains[0].main: "*.domein.be"
      traefik.http.services.webtop-secure.loadbalancer.server.port: 3001
      traefik.http.services.webtop-secure.loadbalancer.server.scheme: https
      traefik.enable: true

De watchdog container heb ik redelijk eenvoudig kunnen opbouwen met ChatGPT/CoPilot en bestaat uit flask en de 2 scripts die uitgevoerd worden. Concreet is het een check die uitgevoerd wordt richting de webtop container (ss) om te zien of er activiteit is op de poort. Anderzijds is het een python script voor flask welke nagaat of de webtop container gestart is, en indien niet deze opstart en een redirect doet naar de originele URL (waardoor traefik door de hogere prio plots naar de andere container verwijst).

Enige nadeel is dat de watchdog container toegang nodig heeft tot de docker.sock om de nodige zaken te kunnen uitvoeren en er dus wel "veel" rechten nodig zijn voor die watchdog container, maar ach, ik draai hier geen geheime zaken
Als er interesse is kan ik hier wel de Dockerfile and scriptjes nog zetten ook, komt echter ook vrij eenvoudig uit AI assistenten.