Hallo und Guten Morgen
mein Hardwareserver ist leider ausgestiegen und ich bin am überlegen, ob es mittlerweile bessere Hardware als den Cubietruck mit SSD gibt.Ich habe bisher Homematik, IT und etliche LED Variationen in Betrieb gehabt.Ein zweiter Cubitruck läuft für die Alexa Version und für die Homematik IP Geräte hatte/habe ich die HM CCu2
Hat jemand Erfahrungen dazu?
Eine Info wäre toll
Ich wünsche einen schönen Tag
Rock Pi könnte interessant sein:
https://www.reichelt.de/index.html?ACTION=446&LA=2&q=rock%20pi%204
läuft auch mit ssd (NVMe).
Ich habe den aber nicht, daher kann ich keine Erfahrungen beisteuern.
Ich würde Dir mittlerweile BareBones Empfehlen (Intel NUC, Zotac (mein Favorit, etc...)
Allerdings sind die dann doch etwas teurer (mit ~260 für ein Zotac CI329 sollte man rechnen), dafür aber auch deutlich stabiler/schneller als ein Pi
Ich würde ebenfalls BareBones empfehlen, e.g ich hatte mit einem RasPi3 immer folgende Probleme:
- das Sonos Modul lief schlecht und blockierte
- alle 3-4 Tage Abstürze
- Fehlermeldung wegen zu wenig Speicher ......
Langfristig machts einfach mehr Spass und ist wesentlich stabiler.
Ich habe einen Intel NUC mit i3 und würde ihn immer wieder kaufen. Darauf Proxmox mit einzelnen LXC für jeden Dienst. Übersichtlich und einzeln updatebar. Backups laufen wie flüssige Butter.
Zitat von: gloob am 29 April 2019, 17:28:58
Ich habe einen Intel NUC mit i3 und würde ihn immer wieder kaufen. Darauf Proxmox mit einzelnen LXC für jeden Dienst. Übersichtlich und einzeln updatebar. Backups laufen wie flüssige Butter.
Welchen NUC?
Aktuell wird man wohl zum aktuellen Modell greifen, am besten BEH im Namen mit Platz für eine 2.5" Platte. Ich habe das Vorgängermodell als Arbeitsrechner.
https://www.amazon.de/Intel-NUC8i3BEH-Mainboard-Generation-Processors/dp/B07JB2M5JS/ref=sr_1_6?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=nuc&qid=1556555054&s=computers&sr=1-6
Und wer Proxmox einsetzen will sollte schauen das die CPU Hyper-V unterstützt.
Und gerne mal über den Tellerrand schauen, also nicht immer gleich "Intel NUC"
Nachteil von NUC: Sie haben einen Lüfter ....
Zitat von: Wernieman am 29 April 2019, 21:59:45
Und gerne mal über den Tellerrand schauen, also nicht immer gleich "Intel NUC"
Nachteil von NUC: Sie haben einen Lüfter ....
Viel gravierender als der Lüfter, den man übrigens beim nuc i3 kaum hört, ist der überteuerte Preis eines nucs.
Bei mir läuft FHEM seit paar Jahren darauf:
https://www.notebooksbilliger.de/pc+lenovo+ideacentre+200+01ibw+90fa003dge+intel+celeron+3215u
hat mich 150 € neu gekostet.
Ich habe Fhem auch auf einem Raspberry 3 am laufen, ich habe noch eine zbox id90 hier, die liegt seit über einem Jahr im Schrank und wird nicht mehr benutzt.
Ist es ein großer Aufwand mit Fhem auf die zbox umzuziehen?
Zitat von: elmer am 29 April 2019, 23:17:20
Ich habe Fhem auch auf einem Raspberry 3 am laufen, ich habe noch eine zbox id90 hier, die liegt seit über einem Jahr im Schrank und wird nicht mehr benutzt.
Ist es ein großer Aufwand mit Fhem auf die zbox umzuziehen?
Zotac hat linux im download. Sollte also laufen. installiere einfach mal debian drauf. Wenn das läuft hast den größten Schritt bezogen auf Kompatibilität gemacht.
Wenn sie "älter" ist, läuft FHEM bestimmt darauf. Meine CI327 (gib es nicht mehr) ist "damals" eigentlich für Windows gedacht, läuft aber super mit Linux ...
Für ein FHEM-Testsystem hatte ich mir mal ein ACEPC AK1 zugelegt ... Celeron-Prozessor, somit zwar deutlich unter einem i3 auf durchaus ausreichend und gemessen am Preis sehr interessant.
Debian installiert, Treiber für LAN und WLAN musste ich extra aus dem Internet laden der Rest wurde problemlos erkannt. Das Teil läuft erstaunlich stabil und auch ruhig.
Intern ist nur eMMC installiert (nicht der schnellste), es ist aber noch Platz für ne mSATA-SSD und in den Erweiterungseinsatz passt ne 2,5 HDD oder SSD (per USB3 angebunden).
https://www.amazon.de/dp/B075RZT2PW
Unter den EinplatinenComputer ist der Cubietruck aber schon mit die beste Lösung bzgl SSD-Anbindung. Dafür gibt es vernünftige Gehäuse, die auch gleich noch ein Akku als "USV" mit unterbringen können. Alternative evtl noch der Odroid H1.
Alles andere was ich kenne hat meist kein SATA oder es bleibt eine "optische Bastellösung". Vom Dauerbetrieb auf SD-Karte würde ich abraten, vor allem wenn man noch eine Datenbank drauf laufen lassen will.
Dann ich auch noch:
https://www.esm-computer.de/fujitsu-esprimo-q520-core-i5-4590t-2-0-ghz-1017227/
+ SSD-CD-Caddy und zweite SSD rein
+ Proxmox
= macht bei mir erstmal "alles" (Squeezeserver, PiHole, FHEM, SAMBA)
(Win 10 Lizenz hab ich eh gebraucht).
Alternative wäre ein neues gebrauchtes ThinkPad kaufen (T450s) und dann das alte T420s als Server aller Art nehmen. Aber der Vorteil der integrierten USV bei weniger Leistung wars mir nicht wert.
hast du auch mal geschrieben was für Voraussetzungen du hast?
Wenn du ein 19" Rack im Keller hast würde ich zb. nicht zum Pi oder Cubie raten.
Dann kann ich dir diese Seite empfehlen, das habe ich (bis auf die NAS Platten aber mit 2x SSD für Raid1 für die SystemPlatte) auch aufgebaut in einem 19Rack 1HE
https://www.technikaffe.de/anleitung-404-nas_basic_3.0_mit_passiv_gekuehltem_apollo_lake_4_kern_prozessor
Man sollte sich auch mal die Frage stellen, wie viel ist einem der Dauerläufer wert.
Bei 10 Watt (Idle), kostet der Spaß ohne PV-Anlage ca. 25 Euro pro Jahr.
Der NUC i3 kommt z. B bei potenter Hardware mit ca. 5 Watt (Idle) aus.
Nur mal als Anmerkung ... haben wir hier nicht schon einige Diskussionen über die Hardware?
Stromverbrauch der zbox id90 schwankt zwischen 19 und 25 Watt wenn der Rechner nichts macht. Auf der Box ist Win 10 installiert, das ist zu viel, wenn Debian installiert ist kann man mit einem geringeren Verbrauch rechnen oder wird dieser auch so hoch sein?
Es kommt auf die Konfiguration drauf an und was man laufen lässt.
Also Pauschal nicht beantwortbar.
Ok, dann wird die id90 wohl nicht geeignet sein, diese war einige Jahre mein Mediaplayer und da wurde nie etwas installiert außer Windows und Kodi.
Ich würde es probieren ... Du kannst doch einfach mal Debian (oder besser Ubuntu-Server) drauflegen und nachmessen ...
Und selbst wenn die Stromkosten 25 Euro im Jahr sind, ein neuer kostet mehr als 3 Jahre, d.h. es würde sich erst in 3 Jahrn lohnen, mit einem "neuen" anzufangen.
Und von der Umweltbelastung ... besser ein alt-gerät weiter nutzen als ein neues kaufen ... (solange eben die Energiebilanz (s.o.) stimmt)
Ich würde die GPIOs vermissen ohne Pi. Der steht im Wohnzimmer und da sind einige Sensoren dran, 2 Bewegungsmelder SR501, IR senden und empfangen und über I2C BMP180, SHT21, TSL2561. Das ist nicht leicht preiswert zu ersetzen. Und wenn auch KODI auf dem Mini-PC laufen soll, fehlt das CEC-Modul.
Ich muß gestehen, das ich ein produktives FHEM-System und KODI auf einem PI .... zum Gruseln finde ... (individuelle persönliche Meinung)
Zitat von: Wernieman am 30 April 2019, 19:30:43
FHEM-System und KODI auf einem PI
Davon war nicht die Rede, sondern im Zuge einer möglichen Migration auf einen Mini-PC.
Man muß bei einem Umstieg berücksichtigen, ob einem danach etwas fehlt.
Es spricht nichts dagegen einen Raspi für bestimmte Aufgaben herzurichten, ich habe meinen alten wieder reaktiviert - als Testsystem, Model B braucht noch ca. 1,5 Watt (Idle) - produziert also kaum laufende Kosten.
Was Preis/Leistung angeht, verliert ein Raspi allerdings schnell:
Beispiel:
PI- Vollausstattung: https://www.amazon.de/ABOX-Raspberry-Ultimatives-Starterkit-aus-Schaltnetzteil/dp/B07DDCRFP6/ref=sr_1_1_sspa?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2ZJH9OPE0NM6G&keywords=raspberry+pi+3+b%2B&qid=1556650739&s=gateway&sprefix=rasp%2Caps%2C172&sr=8-1-spons&psc=1
kostet schnell 80 €
Dagegen Intel-Plattform:
https://www.amazon.de/Intel-NUC-BOXNUC6CAYH-Computer-CELERON/dp/B01MSZTD8N/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=nuc+3455&qid=1556650831&s=gateway&sr=8-1
+
https://www.amazon.de/Kingston-KVR16LS11-Arbeitsspeicher-Non-ECC-204-pin/dp/B00CQ35GYE/ref=pd_bxgy_147_img_2/258-5760406-2743531?_encoding=UTF8&pd_rd_i=B00CQ35GYE&pd_rd_r=81923bda-6b79-11e9-b2bb-656476ee377c&pd_rd_w=mEkwO&pd_rd_wg=5rq25&pf_rd_p=449f5fd6-8f81-46b7-aa57-ca96572671a1&pf_rd_r=BRYSZ5MVAFYK6VP0FRC5&psc=1&refRID=BRYSZ5MVAFYK6VP0FRC5
+
https://www.amazon.de/Crucial-BX500-CT240BX500SSD1Z-Internes-5-Zoll/dp/B07G3KRZBX/ref=sr_1_8?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=ssd&qid=1556650881&s=computers&sr=1-8
kostet zwar etwas mehr als das Doppelte, dafür hat man eine stabile Plattform mit SSD und mit Power von sechs Raspis.
Edit: Auch die Stromkosten halten sich in Grenzen: 5 Watt (Intel) gegen 3,5 Watt (3B+)
Jemand schon Erfahrung mit https://www.gearbest.com/mini-pc/pp_009920577490.html?wid=1433363#goodsDetail ? Na... ok... bis auf die 15W
Zitat von: amenomade am 30 April 2019, 21:52:03
Jemand schon Erfahrung mit https://www.gearbest.com/mini-pc/pp_009920577490.html?wid=1433363#goodsDetail ? Na... ok... bis auf die 15W
Wenn ich es mit meiner vorherigen Intel-Konfiguration vergleiche, dann verliert dieses System, denn
kostet nicht weniger, braucht vermutlich mehr als 5 Watt im Leerlauf, hat nur 128 GB SSD und CPU ist schwächer:
https://www.cpubenchmark.net/compare/Intel-Celeron-1007U-vs-Intel-Celeron-J3455/1847vs2875
Hat aber 8 USB Ports, was mir ein externes USB Hub mit eigener Stromversorgung sparen würde.
Zitat von: amenomade am 30 April 2019, 22:10:52
Hat aber 8 USB Ports, was mir ein externes USB Hub mit eigener Stromversorgung sparen würde.
Willst du dir im Ernst eine sechs Jahre alte CPU zulegen ;)
Naja... bin noch auf der Suche nach der ideale Konfiguration ;)
Zitat von: amenomade am 30 April 2019, 22:45:59
Naja... bin noch auf der Suche nach der ideale Konfiguration ;)
Klar, ist ein schwieriges Thema und auch kein Neues. Jeder hat seine Präferenzen und die sind ja für seine Entscheidung von Bedeutung.
Wenn z. B. jemand eine PV-Anlage hat, den stört vielleicht auch nicht, wenn sein System 30 Watt im Leerlauf verbraucht.
Wenn man sich aber über Stromkosten Gedanken machen muss, dann sollte man beachten, dass üblicherweise ältere Systeme nicht so sparsam waren, wie heutige.
Ich gehe davon aus, dass das alte Schätzchen (Mainboard ca. 5 Jahre alt) insgesamt über 10 Watt im Leerlauf verbraucht.
Wobei auch immer meine "obige" Abschätzung gilt.
Wenn man das System im "Schrank liegen hat" sieht es auch wieder anders aus. Bei einem Neukauf würe ich für FHEM nicht mehr auf einen PI setzen.
Btw:
Auch die GPIOs vom PI werden überschätze. Ich persönlich würde (bei neuen Projekten) dann lieber auf eine Plattform wie esp8266 setzen, also trennen von Hardwareansteuerung und FHEM-Server.
Ich würde den Umzug ja evtl. wagen, ich bin mir aber nicht sicher ob ich das als Laie hinbekomme. Meine größte Sorge ist das fhem dann nicht mehr richtig läuft.
Ich habe viele Monate und Nächte damit verbracht alles einzubinden damit es läuft, ich weiß schon gar nicht welche Pakete ich alles neu installieren muß damit alles in fhem wieder geht.
Welchen Server sollte ich installieren, Ubuntu 18.04.2 live Server amd64 oder Ubuntu 19.04 live Server amd64?
Gibt es Probleme wenn ich bisher Debian installiert hatte und nun auf Ubuntu wechsle?
Ob sich ein Umstieg auf andere Hardware, zumindest aus Sicht der Performance lohnt, kann man ja mal mit der Single-Core-Leistung unter Perl vergleichen.
Der Aufruf auf der Konsole:
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
ergibt bei mir:
Raspi 3B 2B 44 Sekunden.
Intel 3215U 8 Sekunden.
Intel i3-7100U 5 Sekunden
Ich schätze der Raspi 3B+ braucht für die hundert Millionen Durchläufe um die 37 20 Sekunden.
Die Plattenperformance (gegen eine SSD) vergleichen wir ein anderes Mal ;)
Zitat von: Damian am 01 Mai 2019, 15:38:40
Raspi 3B 44 Sekunden.
Da hast Du ein anderes Problem: bei mir auf dem Raspi ergibt das 27 ;)
Zitat von: Damian am 01 Mai 2019, 15:38:40
Ob sich ein Umstieg auf andere Hardware, zumindest aus Sicht der Performance lohnt, kann man ja mal mit der Single-Core-Leistung unter Perl vergleichen.
Der Aufruf auf der Konsole:
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
ergibt bei mir:
Raspi 3B 44 Sekunden.
Intel 3215U 8 Sekunden.
Intel i3-7100U 5 Sekunden
Ich schätze der Raspi 3B+ braucht für die hundert Millionen Durchläufe um die 37 Sekunden.
Die Plattenperformance (gegen eine SSD) vergleichen wir ein anderes Mal ;)
7 Sekunden auf einem i3-3217U unter Proxmox im LXC. :D
Zitat von: amenomade am 01 Mai 2019, 17:44:35
Da hast Du ein anderes Problem: bei mir auf dem Raspi ergibt das 27 ;)
Und du hast auch das vorletzte Pi-Modell? Wenn es sich um das aktuelle Modell 3B+ handelt, dann ist die aktuelle Pi-CPU besser als ich dachte .
Das ist der hier: https://www.amazon.de/gp/product/B01MQK27CV/
Zitat von: amenomade am 01 Mai 2019, 19:56:23
Das ist der hier: https://www.amazon.de/gp/product/B01MQK27CV/
OK. Ich habe gerade feststellen müssen, dass mein Modell noch etwas älter ist.
Mit
cat /sys/firmware/devicetree/base/modelbekomme ich:
Raspberry Pi 2 Model B Rev 1.1Also noch das zweier Model.
Dann wird das aktuelle Modell 3B+ wohl bei knapp über 20 Sekunden landen.
Raspberry Pi 3 Model B Rev 1.2habe ich
Aber gut... trotzdem mit dem NUC unvergleichbar ;)
Wenn man einen Raspberry Pi 3 hat und wechselt auf einen 3b+ kann man dann einfach die SD Karte umstecken und alles läuft wieder?
Zitat von: Damian am 01 Mai 2019, 15:38:40
Ob sich ein Umstieg auf andere Hardware, zumindest aus Sicht der Performance lohnt, kann man ja mal mit der Single-Core-Leistung unter Perl vergleichen.
Der Aufruf auf der Konsole:
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
...
Ein Intel® Core™ i3-7100 Dual-Core mit 3,9 GHz Prozessor braucht knappe 3Sekunden.
FHEM läuft in einer VM auf einem QNAP. Die VM läuft auf einem RAID1 mit 2x 1TB SSD und maximal 32GB RAM, wobei der FHEM VM nur eine CPU und 4GB RAM (DDR4) zugewiesen sind.
Nur zur Info.
Gruß
Mathze
Zitat von: t1me2die am 02 Mai 2019, 07:35:01
Ein Intel® Core™ i3-7100 Dual-Core mit 3,9 GHz Prozessor braucht knappe 3Sekunden.
FHEM läuft in einer VM auf einem QNAP.
Nur zur Info.
Gruß
Mathze
Ich denke, dass das schon ziemlich das Minimum ist, was man mit der heutigen Technik erreichen kann. Ich habe es auf die schnellste heutige CPU hochgerechnet: bei 2,7 Sekunden dürfte Schluss sein.
Auf der anderen Seite reden wir von FHEM, wenn sonst nichts darauf läuft, reicht ein aktueller raspi 3B+ vollkommen aus, wenn die fehlende Anbindung an eine Platte nicht wäre ;)
In diesem Zusammenhang viel mir ein, dass ich da noch etwas zum Testen in der Schublade hatte.
Falls jemand Power eines Raspis mit USV und HDD auf Intel-Basis sucht, mein alter FHEM-Rechner: https://forum.fhem.de/index.php/topic,100181.0.html
https://forum.fhem.de/index.php/topic,99124.0.html
Ciao, -MN
Zitat von: Damian am 03 Mai 2019, 19:36:52
In diesem Zusammenhang viel mir ein, dass ich da noch etwas zum Testen in der Schublade hatte.
Falls jemand Power eines Raspis mit USV und HDD auf Intel-Basis sucht, mein alter FHEM-Rechner: https://forum.fhem.de/index.php/topic,100181.0.html
... die Renaissance der Schrank-Notebooks :) ... .mein Fhem läuft auch auf einem alten Notebook. Geringer Stromverbrauch, "eh-da-Hardware", viel performanter als Raspi und Akku als USV. Das einzige was mir fehlt ist ein Watchdog, gebaut bevor Intel die itco-wdt einbauten.
Und was vieles vereinfacht, Tastatur und Bildschirm gleich mit dabei.
Hallo zusammen,
habe schon seit ein paar Jahren das cubieboard 2 im Einsatz. Braucht nur 1,2 W und ich nutze den Sata - Anschluß für ein Backup-System im Netzwerk.
Einziger Nachteil: Der Kernel von Igor ist schon recht alt....
Daher wollte ich ein weiteres System aufsetzen und wenn dann alles läuft mit fhem umziehn.
Hat jemand Erfahrungen mit den Nachfolgeboards cubieboard 3 - 7 schon gemacht?
Wenn ja, mit welcher Debian - Version und welchem Kernel?
Elektroluch
Der Cubietruck (Cubieboard 3) war mich mich das beste Gerät, da es dafür vernünftige Gehäuse gibt mit Platz für SSD und Pufferbatterie gibt. Auch wird das Teil aktuell (noch) von armbian supported.
Bei den späteren Modellen war SATA imho wieder abgeschafft oder nur noch via USB implementiert worden.
Zitat von: Damian am 01 Mai 2019, 15:38:40
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
ergibt bei mir:
Raspi 3B 2B 44 Sekunden.
Intel 3215U 8 Sekunden.
Intel i3-7100U 5 Sekunden
Ich schätze der Raspi 3B+ braucht für die hundert Millionen Durchläufe um die 37 20 Sekunden.
Hier noch eine interessante Alternative:
Odroid HC1: 9 Sekunden
Wird auch gut mit aktuellem Armbian-OS unterstützt. Direkter Anschluss für eine SATA-HDD/SSD, reiner Server, Konsole nur über seriellen Port.
https://www.pollin.de/p/odroid-hc1-einplatinen-computer-fuer-nas-und-cluster-anwendungen-810766
Ein guter Tipp, benutze bei dem cubieboard die Grafik sowieso nicht.
Schade nur, dass der wohl nur einen USB-Anschluß hat, denn ich habe für fhem zwei CULs angeschlossen. SATA über USB3 ist hier mit 300 MBs angegeben, dass schafft der cubie nach meiner Messung auch so gerade.
Mal sehen, wie eine Ersetzungsstrategie aussehen könnte. Danke für den Tipp.
Elektrolurch
Ich habe vor einiger Zeit meine Diskstation 214Play gegen eine 218+ (+8Gb Ram) ausgetauscht. Da diese sowieso wg. den Kameraaufzeichnungen läuft, habe ich eine Virtuelle Maschine mit Debian 9 drauf laufen. Das ist um einiges stabiler als mit dem Raspi3. Zudem ist es eine tolle Sache, einfach Snapshots oder ein Klon von der VM zu erstellen.
Selbst der USB Bluetooth Dongle wird durchgereicht und funktioniert einwandfrei in der virtuellen Umgebung :)
Gruß,
SteRa
@roedert
wieviel "Saft" gönnt sich denn das Teil?
also odroid-hc1 plus ssd?
ich suche ja auch irgendwie noch einen Ersatz für den Cubie3
Zitat von: roedert am 07 Mai 2019, 14:24:53
Hier noch eine interessante Alternative:
Odroid HC1: 9 Sekunden
Wird auch gut mit aktuellem Armbian-OS unterstützt. Direkter Anschluss für eine SATA-HDD/SSD, reiner Server, Konsole nur über seriellen Port.
https://www.pollin.de/p/odroid-hc1-einplatinen-computer-fuer-nas-und-cluster-anwendungen-810766
Zitat von: Damian am 01 Mai 2019, 15:38:40
Ob sich ein Umstieg auf andere Hardware, zumindest aus Sicht der Performance lohnt, kann man ja mal mit der Single-Core-Leistung unter Perl vergleichen.
Der Aufruf auf der Konsole:
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
ergibt bei mir:
Raspi 3B 2B 44 Sekunden.
Intel 3215U 8 Sekunden.
Intel i3-7100U 5 Sekunden
Ich schätze der Raspi 3B+ braucht für die hundert Millionen Durchläufe um die 37 20 Sekunden.
Die Plattenperformance (gegen eine SSD) vergleichen wir ein anderes Mal ;)
Ich habe gerade einen Raspi 4 installiert und gemessen, Ergebnis:
Raspi 4: 9 SekundenAlso ca. doppelt so schnell wie ein Raspi 3.
Kommt langsam an mein bisheriges FHEM-Intel-System mit Intel 3215U (hat allerdings nur zwei Kerne)
Gemessen wird natürlich nur die Single-Kernleistung, die aber für FHEM wesentlich ist.
Wenn nur die Stabilität vergleichbar wäre ... ;o)
Zitat von: Wernieman am 24 Januar 2020, 21:08:58
Wenn nur die Stabilität vergleichbar wäre ... ;o)
Naja Fhem bekommt im dauerbetrieb alles kaputt Hd's Sd's SSD's vorallem Netzgeräte
Solche Hardware Leichen kannste bei mirhaben
Also das hat FHEM hier noch nie geschafft ...
Berufmäßig habe ich schon diverse kaputte Harware gehabt, aber mit Stabilität meinte ich eher die Softwarestabilität.
Zitat von: Damian am 02 Mai 2019, 07:40:30
Auf der anderen Seite reden wir von FHEM, wenn sonst nichts darauf läuft, reicht ein aktueller raspi 3B+ vollkommen aus, wenn die fehlende Anbindung an eine Platte nicht wäre ;)
Das wollte ich gerade fragen: Was habt Ihr denn da alles am Laufen? Ich habe einen load von
top - 21:20:34 up 4 days, 14:50, 3 users, load average: 0,32, 0,28, 0,17
Tasks: 145 total, 1 running, 144 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,1 us, 0,3 sy, 0,0 ni, 99,6 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
MiB Mem : 926,1 total, 63,8 free, 430,5 used, 431,8 buff/cache
MiB Swap: 100,0 total, 67,5 free, 32,5 used. 425,7 avail Mem und das ist noch viel, Standard sind eher 0,0irgendwas. Deshalb würde ich nie umziehen, nur die SD Karte, die werde ich mal regelmäßig wechseln (obwohl die letzte doch nicht kaputt war, wie ich dachte).
Hallo,
bei mir ist das ein J1900 Mainboard 8 GB und SSD. Reicht bei um die 10-12 W Leistungsaufnahme für meine gesammte IT Landschaft :-)
Grüße Peter
Mein Umzugsprojekt von der Intel-Plattform mit SSD auf PI4 mit SD ist zunächst gescheitert - zu viele Hänger. Werde wohl einzeln vorgehen müssen, um die Übeltäter bei meiner umfangreichen Konfiguration ausfindig zu machen - CPU-Performance ist eben nicht alles.
In diesem Zusammenhang habe ich 1wire von OWX auf ESPEasy umgestellt, so läuft jetzt wenigstens mein Altsystem noch etwas runder :)
@andies
Load ist bei einem System <> Systemlast.
Load bedeutet Prozesse, welche auf IO Warten. Siehe auch https://de.wikipedia.org/wiki/Load (https://de.wikipedia.org/wiki/Load)
Zitat von: andies
MiB Swap: 100,0 total, 67,5 free, 32,5 used. 425,7 avail Mem
Swap auf der SD :o , kann man machen
Interresannt wie man die begrenzte Schreibfähigkeit der SD ignoriert
Zitat von: fhem-hm-knecht am 26 Januar 2020, 18:46:53
Swap auf der SD :o , kann man machen
Interresannt wie man die begrenzte Schreibfähigkeit der SD ignoriert
Woher weiss Du, dass seine swap Datei auf der SD Karte liegt? ;)
Jedenfalls... Raspbian hat standardmässig eine swap Datei von 100MB und das ist gut so. Diese zu deaktivieren kann zwar die Lebensdauer der Karte verbessern (angenommen, dass das System permanent schreibt und liest, was nicht ubedingt der Fall ist: vielleicht wurde etwas seit Monaten geswapped und nie wieder gelesen), aber würde zu andere Problemen führen. Wenn das System swap benutzt hat, heisst es, dass ohne swap es gecrashed hätte, bzw. der Kernel hätte selbst Prozesse unfreundlich gekillt.
Zitat von: Wernieman am 26 Januar 2020, 17:46:41
@andies
Load ist bei einem System <> Systemlast.
Ja, ich weiss: aber meine Systemlast ist auch sehr gering:
~ $ top
top - 19:56:45 up 5 days, 13:26, 3 users, load average: 0,11, 0,09, 0,12
Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,5 us, 0,3 sy, 0,0 ni, 99,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
MiB Mem : 926,1 total, 58,3 free, 422,8 used, 445,0 buff/cache
MiB Swap: 100,0 total, 67,2 free, 32,8 used. 434,0 avail Mem
PID USER PR NI VIRT RES SHR S CPU MEM TIMECOMMAND
12724 fhem 20 0 123152 109032 9768 S 2,3 11,5 21:36.90 perl
19723 pi 20 0 10340 3128 2576 R 0,7 0,3 0:00.11 top
315 avahi 20 0 6036 2792 2416 S 0,3 0,3 3:13.91 avahi-daemon
511 mysql 20 0 749948 195800 8148 S 0,3 20,6 24:37.88 mysqld
1 root 20 0 33744 5960 4852 S 0,0 0,6 0:18.69 systemd
Hallo,
bin jetzt nach einem Tipp in diesem Thema auf einen ODROID H2 mit Intel umgezogen.
Mit einer SSD und einer HD braucht das Teil bei laufendem fhem und samba ca. 5 w. Das ist ja ok, finde ich.
Die Weboberfläche ist im Vergleich zu einem Cubieboard 2 deutlich schneller, auch fährt das ganze System in wenigen Sekunden hoch.
Portierung und ein gewisser Paralellbetrieb waren dann auch problemlos.
Nur das SYSMON - Modul ist wohl speziell für RPI geschrieben, da gibt es jetzt weder CPU - Infos wie Temperatur oder CPU-Auslastung...
Elektrolurch
Zitat von: Damian am 26 Januar 2020, 16:08:15
Mein Umzugsprojekt von der Intel-Plattform mit SSD auf PI4 mit SD ist zunächst gescheitert - zu viele Hänger. Werde wohl einzeln vorgehen müssen, um die Übeltäter bei meiner umfangreichen Konfiguration ausfindig zu machen - CPU-Performance ist eben nicht alles.
In diesem Zusammenhang habe ich 1wire von OWX auf ESPEasy umgestellt, so läuft jetzt wenigstens mein Altsystem noch etwas runder :)
Nachdem ich das Problem gefunden habe, wichtig für Windowsumsteiger siehe: https://forum.fhem.de/index.php/topic,107864.msg1018728.html#msg1018728
läuft der kleine PI4 "with 627 defined entities" seit drei Wochen stabil und performant, die Intel-Plattform unter Windows wird noch für Entwicklung genutzt.
Mit 178 MB von 3,81 GB belegten Arbeitsspeicher ist noch sehr viel Luft nach oben. Eine 30 Euro USB-SSD sollte für SD-Kritiker auch kein Problem sein.
Fazit: Empfehlung für einen PI4-Umstieg
Hallo,
mein HP T610 mit 4 GB RAM, 250 GB SSD mit Fhem, UniFi-Controller (also im laufenden Betrieb) braucht 11 Sekunden für diesen Befehl:
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
Nicht schlecht, aber auch nicht sonderlich gut.
Viele Grüße Gisbert
Mal eine Frage zur begrenzten Schreibkapazität von SD-Karten und einem möglichen Workaround:
Bei den Intel basierten Systemen hat man ja die >Möglichkeit das Boot - device schon im BIOS einzustellen.
Das geht m.W.n. bei den Arm-basierten Systemen ja nicht, bzw. das mit den Booten ist ja nicht ganz so trivial.
Meistens wird doch erst einmal nachgesehen, ob eine SD-Karte eingesteckt ist (wie beim cubieboard).
Um diese möglichst wenig durch Schreibvorgänge zu belasten könnte man auf der SD - Karte nur ein minimales Linux installieren und in der fstab folgende Zeile einfügen:
/dev/sda1 / ext4 defaults,noatime 0 2
[/cod]
Und auf das /dev/sda1 (SSD oder HD) ein komplettes Linux installieren.
Was spricht gegen so eine Vorgehensweise? Oder funktioniert das überhaupt nicht?
Elektrolurch
Dann solltest Du auf der SD_Card nur das boot-Device setzen und gleich im root auf die SSD zeigen. Dann schreibst Du definitiv nie auf die SD (abgesehen von der Installation)
@Gisbert
auch mein FHEM System ergibt mit der perl Zeile "nur" 11 Sekunden ...
(Mein Arbeitsrechner dagegen 3 .. da sind ind er CPU aber auch Welten dazwischen)
Diese Zeile ist aber auch nur ein reiner CPU (perl) Check. Es wird eben geprüft, wie schnell der Rechner in perl von 1 bis 100000000 zählen kann. Ob jetzt das IO-Device langsam oder schnell ist, ist dabei irrelevant ...
Vielleicht kommt ja mal irgendwann das UEFI in die originale Firmware, siehe : https://www.heise.de/newsticker/meldung/UEFI-Firmware-fuer-den-Raspberry-Pi-4-und-3-4663269.html
Unabhängig von der Hardware sollte man paar Minuten apptime laufen lassen. So habe ich bei mir einen der Übeltäter mit bis zu 8 Sekunden Blockade ausfindig gemacht. OWX brauchte bei mir ca. 1 Sekunde-Abfragezeit pro Device, bei 8 Sensoren, wenn sie hintereinander abgefragt wurden (gleiche Intervalldefinition) konnten es dann 8 Sekunden werden. Zunächst habe ich es auf Windows (auf Intel) geschoben. Dort habe ich die Intervalle unterschiedlich gewählt, um die Blockaden zu entzerren. Unter 30 Sekunden Abfrageintervall bin ich allerdings bei keinem Sensor gegangen. Leider war nach der Umstellung auf PI4 das gleiche Bild. Daraufhin habe ich 1-wire auf ESPeasy umgestellt. Das war schnell erledigt (einfach 1-wire-Bus vom USB-Adapter auf ESP2866 umgehängt), dort habe ich jetzt alle Sensoren auf 15 Sekunden Abfrageintervall stehen und keinerlei Hänger im System - per apptime nachweisbar.
Was jetzt am meisten Zeit braucht, ist bei mir der HM-LAN-Adapter mit ca. 150 mSek, aber das ist eher normal und nicht als Blockade zu sehen ;)
Auch hier kann man sagen: besseres Reaktionsverhalten, trotz langsamerer Hardware
Evtl. hätte es gereicht, OWX auf einen asynchronem Modus umzustellen; ich habe diesen Teil aus ähnlichen Gründen noch in der "vor-Asynchronen Zeit" auf MySensors@RS485 umgestellt und nutze seitem auch in der Regel irgendwelche MCU's, um die gemessenen Werte an FHEM zu senden.
Die 1 Sek. kommt übrigens daher, dass der Sensor erst die Anweisung braucht, dass er messen soll, und dann erst abgefragt werden kann - wie früh, hängt auch von der Auflösung ab (max. Auflösung = 12=750ms für die Messung) braucht man in der Regel gar nicht...
Ansonsten hatten wir zum Thema SSD an USB auch schon Fälle, in denen das zu Problemen geführt hatte, wenn nämlich die Platte kurz weg war; Linux mag Verbindungsunterbrechungen zu Systemplatten nämlich nicht besonders, jedenfalls afaik...
Mein T620 braucht übrigens zwischen 9 und 11 Sekunden, aber die reine Prozessorleistung ist für FHEM eigentlich völlig egal. Wichtiger sind mir z.B. ausreichend viele, vernünftige USB-Anschlüsse (da hängen u.A. diverse MySensors-Gateways dran).
Ich krame mal den alten Thread wieder hervor, weil die Hardwarefrage immer wieder im Raum steht. Zumal der Raspi 5 kommt.
Z. Zt. läuft fhem bei mir noch auf einem Raspi 4, da ich aber noch einen Windows-Server auf einem NUC 8i5 daneben laufen hatte, habe ich mir gedacht das kann man sicherlich auch eleganter und kostengünstiger mit einem Rechner lösen. Zuvor hatte ich mehrere Jahre fhem unter Windows laufen, aber diese Lösung war suboptimal. Angeregt durch den Beitrag von Andrea Spieß https://www.youtube.com/watch?v=rXc_zGRYhLo habe ich kurzer Hand Proxmox auf den NUC drauf gespielt und dort u. a. Windows und Debian als VM-System installiert.
Der Rechner braucht im Idle (in den VMs passiert ja nicht viel) um die 6 Watt, also nicht mehr als mein Raspi 4 mit einer externen SSD. Dabei steck dort eine 2 TB und eine 4 TB SSD drin (WLAN wurde abgeschaltet)
Der Performancetest:
perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
liefert in einer VM ca. 2 Sekunden (man müsste den Test langsam auf Millisekunden umstellen ;))
Wenn man bedenkt, dass Minirechner mit potenter Hardware inzwischen verhältnismäßig günstig zu bekommen sind (doppelte Performance meines alten NUCs mit Speicher und SSD für ca. 300 Euro) und nicht viel mehr als ein Raspi an Strom brauchen, sind sie eine gute Alternative zum Raspi, vor allem wenn man noch etwas mehr als nur fhem dauerhaft laufen lassen möchte.
Zusätzlich kommen die Vorteile eines VM-Systems insb. was die Flexibilität angeht noch hinzu.
Zitat von: Damian am 14 Oktober 2023, 13:27:27Angeregt durch den Beitrag von Andrea Spieß
man muss nicht jeden Vornamen gendern...
Zitat von: betateilchen am 14 Oktober 2023, 13:35:39Zitat von: Damian am 14 Oktober 2023, 13:27:27Angeregt durch den Beitrag von Andrea Spieß
man muss nicht jeden Vornamen gendern...
Solange es nicht Andrea Berg ist ;)
Zitat(man müsste den Test langsam auf Millisekunden umstellen ;))
z.Bsp. indem man "use Time::HiRes qw(time);" davorhaengt.
Zitat von: rudolfkoenig am 14 Oktober 2023, 13:41:19Zitat(man müsste den Test langsam auf Millisekunden umstellen ;))
z.Bsp. indem man "use Time::HiRes qw(time);" davorhaengt.
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'liefert: 2.20171403884888
Hallo Damian,
ich nutze einen gebraucht gekauften Futro S740 mit 16 GB Arbeitsspeicher und einer 1 TB SSD (letzteres neu eingebaut), auf dem Proxmox läuft. Je eine VM hab ich für Fhem, Pi-hole und den UniFi-Controller (mein eigenes Netz hinter der Fritzbox).
Ich bin äußerst zufrieden damit, vor allem auch mit den Backup-Möglichkeiten von Proxmox. Davor hatte ich einen HP T610. Der Futro S740 ist gemessene 5-6mal schneller bei einem Verbrauch von 10 W vs. 35 W beim HP T610.
Viele Grüße Gisbert
ja, da hat sich einiges getan, hier ein Powervergleich der CPU´s:
https://www.cpubenchmark.net/compare/3159vs3299vs4883/Intel-Celeron-J4105-vs-Intel-i5-8259U-vs-AMD-Ryzen-5-5560U
von links nach rechts:
Deine, meine und eine in so einem Minipc: https://www.amazon.de/TRIGKEY-Desktop-PC-Type-C-Radeon-Gaming/dp/B0BR5M9K28/ref=sr_1_1_sspa?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2N2VBZH29BUC8&keywords=5560U&qid=1697314852&sprefix=5560u%2Caps%2C224&sr=8-1-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&psc=1
Die tuckern alle mehr oder minder mit 10 Watt vor sich hin.
Darf ich mal unqualifiziert zwischenfragen? Smarthome ist doch sicherlich nicht die einzige Anwendung für "Server zu Hause"? Wer hat zusätzlich noch ein NAS (für Backup, etc.) daneben stehen?
Ich hab mir einen DELL T30 in den Keller gestellt, darauf ein ESXi (ich brauche auch noch Windows-VMs) und dann in unterschiedlichen VMs NAS (mit OMV), Smarthome und Nextcloud (alles mit Debian) installiert.
Wahrscheinlich hätte man da auch Docker verwenden können.
Am Ende habe ich eine physische Maschine für alles, damit sollte auch der Stromverbrauch im Rahmen bleiben.
jm2c
Ich kann hier nur den schon mehrfach geposteten Vorschlag empfehlen, ein altes Notebook als FHEM-Server einzusetzen !
Ich hatte auf dem RasPi3 vor einigen Jahren laufend Performance-Probleme mit FHEM, die auf einen Schlag erledigt waren, nachdem ich auf ein altes Intel 2-Kern CPU-Notebook mit SSD und ubuntu-Server migriert hatte. :)
Braucht vielleicht mit abgeschaltetem Screen ein paar Watt mehr, aber:
- vielfache Performance
- keine SD-Card-Probleme mehr
- und die USV ist (mit neuem Akku) auch mit dabei
- vermutlich sind alte Notebooks in 2023 immer noch leichter zu beschaffen als RasPi's ;)
Wobei ein Dauerversorgtes Notebook leicht einen Aufgeblähten Akku bekommen kann. Gab mal extra Laptops (oder Ersatzakkus) für solche Anwendungsfälle, die nicht dazu neigen.
Binn immer noch ein Freund der "Kleinstrechner", wie NUC, Zotac oder ...
Zitat von: pcbastler am 17 Oktober 2023, 21:52:13Darf ich mal unqualifiziert zwischenfragen? Smarthome ist doch sicherlich nicht die einzige Anwendung für "Server zu Hause"? Wer hat zusätzlich noch ein NAS (für Backup, etc.) daneben stehen?
Ich hab mir einen DELL T30 in den Keller gestellt, darauf ein ESXi (ich brauche auch noch Windows-VMs) und dann in unterschiedlichen VMs NAS (mit OMV), Smarthome und Nextcloud (alles mit Debian) installiert.
Wahrscheinlich hätte man da auch Docker verwenden können.
Am Ende habe ich eine physische Maschine für alles, damit sollte auch der Stromverbrauch im Rahmen bleiben.
jm2c
Vor paar Tagen habe ich, wie bereits hier geschrieben, auf einem NUC 8i5 das Proxmox installiert. Von der Performance, der Bedienbarkeit von Proxmox und dem niedrigen Verbrauch des Minirechners war ich begeistert.
Leider schmierte das System immer wieder ab. Auch diverse Versuche durch Biosänderungen das Proxmox stabil zu bekommen waren nicht erfolgreich.
Installiert hatte ich dort eine Debian-VM für FHEM (FHEM lief aber noch nicht), eine Debian-VM mit OpenmediaVault als NAS mit SMB für Windowsrechner im Heimnetz und eine Windows-VM mit Windows 11.
Mein Verdacht ist, dass die Windows-VM das Problem bei mir darstellt, ich habe sie nun gestoppt - seit zwei Tagen läuft das System stabil. Leider ist das keine Option für mich.
Ich habe gerade das ESXi-ISO heruntergeladen und probiere mein Glück damit.
Sollte die Umgebung stabil laufen, möchte ich weitere VMs dort installieren:
eine zweite FHEM-Instanz für Entwicklung, Nextcloud, RaspberryMatic, ggf. Automatisierung der Konkurrenz zum Ausprobieren und was mir sonst so einfällt.
Die Power des kleinen Minis mit 6 TB SSDs und 32 GB Hauptspeicher sollte dafür ausreichen.
Zitat32 GB Hauptspeicher
Probiere mal für Debugzwecke mit weniger Hauptspeicher. Viele Minnirechner sind für weniger Hauptspeicher zertifiziert.
Und wenn der Rechner "abschmiert" .. gibt es Einträge bei den üblichen Verdächtigen? syslog/kern.log etc?
Offiziell sind beim 8i5beh 2x16 GB 2400 DDR4 zugelassen (eingebaut sind 2 x Crucial RAM 16GB DDR4 3200 MHz CL22 (oder 2933 MHz oder 2666 MHz) Laptop Arbeitsspeicher CT16G4SFRA32A)
Der Rechner lief zuvor stabil mit diesen Riegeln unter Windows.
kernel.log kann auf dem Proxmox-System nicht finden. In anderen Logs sehe ich auch nichts Verdächtiges.
Hallo Damian,
ich nutze einen NUC7 und einen NUC11 jeweils mit Proxmox und ohne Probleme. Ich lese auch aktiv im Proxmox-Forum mit.
Wenn es da um NUCs geht, sind die ersten Fragen die, ob 1) das letzte aktuelle BIOS installiert ist und ob 2) VT-d und VT-x aktiviert sind.
Meine beiden NUCs laufen mit dem 8.0.4 und dem Kernel 6.2.16-15-pve #1.
Übrigens bin ich von ESXi umgestiegen, weil gerade das Thema lxc micht gereizt hat - so habe ich bspw. verschiedene Services containerisiert statt alles in eine VM zu packen. Außerdem wollte ich des Spieltriebs wegen einen Cluster aufbauen und sogar Pseudo-HA realisieren - das alles geht mit einen ESXi-free nicht.
Edit: das Kernel.log findest du in /var/log/kern.log
Ich habe mal zwischendurch ESXi (mit free-key) installiert. Lief absolut stabil. Habe dort Debian installiert. Allerdings klappte eine Windows 11 Installation schon mal nicht, da ESXi (ohne vCenter) den TPM-Chipsatz des NUC nicht unterstützt - schade eigentlich.
Mir gefällt die Sache mit den lxc-Containern bei Proxmox auch ganz gut. Ich habe jetzt das BIOS aktualisiert und damit auch die Einstellungen zurückgesetzt, VT-d und VT-x waren immer schon aktiviert.
Nach dem Motto: die Hoffnung stirbt zuletzt - schauen wir mal, wann der nächste "freeze" kommt.
übrigens, kern.log gibt es bei mir unter /var/log nicht
Ich habe mal im Proxmox-Forum etwas herumgestöbert, man findet direkt bei den neusten Threads diverse Probleme mit der Stabilität des Systems -vor allem beim Upgrade auf die 8er-Version. Bei mir wurde es leider nicht besser. Bin erst mal auf die 7er-Version gegangen, mal schauen ob es besser wird.
Sehr spannender Thread. Ich habe seit 2 Jahren einen Raspi 4 mit einer unterdessen recht umfangreichen FHEM Installation. z.T. dauert der Seitenaufbau 4-5 Sekunden. Wenn ich mir die Optionen ansehe, so würde ich nicht mehr auf den Pi zurückgreifen. Die PIN Leiste brauche ich kaum und die Performance ist nicht so berauschend. Der Pi 5 soll wesentlich schneller sein, braucht dann allerdings auch mehr Strom (gemäss heise/ c't).
Pi 4 braucht 9s für den "perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'" Test, mein Uralt-Intel Server mit Intel(R) Pentium(R) CPU G2020 2.9Ghz nur 4s.
ZitatUralt-Intel Server
Verwendung von alter Hardware 24*7 sollte man sich immer Gründlich überlegen. Ein aktueller Mini PC mit Intel® Celeron® N4505 liegt bei c.a. 140,- + RAM und SSD (schnelle Suche, +- ist möglich). Wenn die Kiste dann 4-5 Jahre läuft, kann die Stromersparnis die Kosten wieder rausholen oder sogar überkompensieren.
Zitat von: ansgru am 19 Oktober 2023, 12:01:17Sehr spannender Thread. Ich habe seit 2 Jahren einen Raspi 4 mit einer unterdessen recht umfangreichen FHEM Installation. z.T. dauert der Seitenaufbau 4-5 Sekunden. Wenn ich mir die Optionen ansehe, so würde ich nicht mehr auf den Pi zurückgreifen. Die PIN Leiste brauche ich kaum und die Performance ist nicht so berauschend. Der Pi 5 soll wesentlich schneller sein, braucht dann allerdings auch mehr Strom (gemäss heise/ c't).
Pi 4 braucht 9s für den "perl -e 'my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'" Test, mein Uralt-Intel Server mit Intel(R) Pentium(R) CPU G2020 2.9Ghz nur 4s.
Aus diesem Grund habe ich mir ein "refurbished ThinkCenter M900" für wenig Geld gegönnt.
Damit habe ich neben fhem den MySQL-Server vom alten NAS mit umziehen können.
Zudem läuft Grafana, Wekan etc... alles sehr geschmeidig...
Seitenaufbau - insbesondere wenn graphen dabei sind - hing bei mir meist an der SQl-Performance. Der Stromverbrauch ist vergleichsweise höher als beim PI, aber dafür laufen auch viel mehr Dienste. Das NAS dient aktuell nur für Backups.
Ich hab da noch potential einiges an Verbrauchern zu sparen - wie z.B. die HM-CCU. Aber dafür brauch ich erstmal Zeit.
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)' liefert mir
2.8207 s
Ok, dann mache ich mal mit 8) :
NUC7i5: 2.35804009437561 s
NUC11i7: 1.42791604995728 s
lxc-Container, in dem FHEM auf dem NUC11 läuft, 2 Kerne und 4GB zugewiesen: 1.43110513687134 s
pi3: 21.3367218971252 s 8)
Da geht mehr: Pi2B 37 sec ;D
Beim sparsamen LAPTOP (Lenovo B50-30 mit Celeron N2815) komme ich auf ca. 6-7 Watt ohne bzw. dunkler Bildschirm - immerhin. Dürfte aber vermutlich mit seinen 2 Kernen kein berauschender Performancegewinn (macht 12sec für die Schleife) sein.
Könnte mir einen Einsatz als Kombi: FHEM-Server und Anzeige Board vorstellen. Aber mehrere VM oder Container sicher nicht.
Architektur: x86_64
CPU Operationsmodus: 32-bit, 64-bit
Adressgrößen: 48 bits physical, 48 bits virtual
Byte-Reihenfolge: Little Endian
CPU(s): 32
Liste der Online-CPU(s): 0-31
Anbieterkennung: AuthenticAMD
BIOS-Anbieterkennung: Advanced Micro Devices, Inc.
Modellname: AMD Ryzen 9 5950X 16-Core Processor
BIOS-Modellname: AMD Ryzen 9 5950X 16-Core Processor Unknown CPU @ 3.4GHz
BIOS-Prozessorfamilie: 107
Prozessorfamilie: 25
Modell: 33
Thread(s) pro Kern: 2
Kern(e) pro Sockel: 16
Sockel: 1
Stepping: 2
Übertaktung: aktiviert
Skalierung der CPU(s): 73%
Maximale Taktfrequenz der CPU: 5083,3979
Minimale Taktfrequenz der CPU: 2200,0000
BogoMIPS: 6787,36
Markierungen: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc
rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx
cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsave
opt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale
vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor
smca fsrm
Virtualisierungsfunktionen:
Virtualisierung: AMD-V
Caches (Gesamtsumme):
L1d: 512 KiB (16 Instanzen)
L1i: 512 KiB (16 Instanzen)
L2: 8 MiB (16 Instanzen)
L3: 64 MiB (2 Instanzen)
NUMA:
NUMA-Knoten: 1
NUMA-Knoten0 CPU(s): 0-31
Schwachstellen:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Not affected
FHEM Test und Demo läufen als Container in einem 3 Node Kubernetes Cluster
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
k8s-control01 Ready control-plane 195d v1.26.7 10.6.6.22 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-23-amd64 containerd://1.6.22
k8s-node01 Ready <none> 195d v1.26.7 10.6.6.31 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-23-amd64 containerd://1.6.22
k8s-node02 Ready <none> 195d v1.26.7 10.6.6.35 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-23-amd64 containerd://1.6.22
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
container-registry private-repository-7f8f64867d-cdfjm 1/1 Running 0 47h 172.20.58.234 k8s-node02 <none> <none>
fhem-demo fhem-7c4d757fb-7chnp 1/1 Running 0 68m 172.20.58.199 k8s-node02 <none> <none>
fhem-testing t-fhem01-5d8fb46d6b-55wf5 1/1 Running 1 (32h ago) 32h 172.20.58.243 k8s-node02 <none> <none>
jumphost-production ssh-jumphost-8795b7fdb-p5lvr 1/1 Running 0 2d1h 172.20.85.227 k8s-node01 <none> <none>
jumphost-production web-nginx-reverseproxy-d6bdc4957-nmqhn 1/1 Running 0 8d 172.20.58.215 k8s-node02 <none> <none>
kaniko fhem-docker 0/1 Completed 0 80m 172.20.58.193 k8s-node02 <none> <none>
keycloak-production keycloak-0 1/1 Running 1 (14d ago) 14d 172.20.58.205 k8s-node02 <none> <none>
kochbuch recipes-8459f475d5-9b5t8 2/2 Running 2 (14d ago) 14d 172.20.58.207 k8s-node02 <none> <none>
kube-system calico-kube-controllers-949d58b75-k9g5t 1/1 Running 11 (14d ago) 69d 172.20.246.81 k8s-control01 <none> <none>
kube-system calico-node-f6cwt 1/1 Running 11 (14d ago) 69d 10.6.6.22 k8s-control01 <none> <none>
kube-system calico-node-n5bzd 1/1 Running 11 (14d ago) 69d 10.6.6.31 k8s-node01 <none> <none>
kube-system calico-node-sv4gk 1/1 Running 12 (14d ago) 69d 10.6.6.35 k8s-node02 <none> <none>
kube-system coredns-754b6c9d98-2dpvt 1/1 Running 8 (14d ago) 19d 172.20.246.82 k8s-control01 <none> <none>
kube-system coredns-754b6c9d98-pxncm 1/1 Running 9 (14d ago) 68d 172.20.246.80 k8s-control01 <none> <none>
kube-system etcd-k8s-control01 1/1 Running 20 (14d ago) 77d 10.6.6.22 k8s-control01 <none> <none>
kube-system kube-apiserver-k8s-control01 1/1 Running 4 (14d ago) 14d 10.6.6.22 k8s-control01 <none> <none>
kube-system kube-controller-manager-k8s-control01 1/1 Running 23 (14d ago) 77d 10.6.6.22 k8s-control01 <none> <none>
kube-system kube-proxy-42blq 1/1 Running 15 (14d ago) 69d 10.6.6.22 k8s-control01 <none> <none>
kube-system kube-proxy-68wlv 1/1 Running 15 (14d ago) 69d 10.6.6.35 k8s-node02 <none> <none>
kube-system kube-proxy-mzztz 1/1 Running 14 (14d ago) 69d 10.6.6.31 k8s-node01 <none> <none>
kube-system kube-scheduler-k8s-control01 1/1 Running 23 (14d ago) 77d 10.6.6.22 k8s-control01 <none> <none>
kube-system metrics-server-69bc768f87-r9kqm 1/1 Running 1 (14d ago) 14d 172.20.85.245 k8s-node01 <none> <none>
metallb-system controller-68bf958bf9-c86lm 1/1 Running 1 (14d ago) 14d 172.20.85.249 k8s-node01 <none> <none>
metallb-system speaker-hwqrq 1/1 Running 190 (14d ago) 195d 10.6.6.22 k8s-control01 <none> <none>
metallb-system speaker-qhv8r 1/1 Running 99 (14d ago) 195d 10.6.6.31 k8s-node01 <none> <none>
metallb-system speaker-rmdcv 1/1 Running 99 (14d ago) 195d 10.6.6.35 k8s-node02 <none> <none>
nfs-client nfs-client-provisioner-7cc79b4877-6qrmq 1/1 Running 1 (14d ago) 14d 172.20.85.243 k8s-node01 <none> <none>
paperless-production paperless-paperless-ngx-9cf5ccd96-cp62h 1/1 Running 0 14d 172.20.85.248 k8s-node01 <none> <none>
paperless-production paperless-redis-master-0 1/1 Running 1 (14d ago) 14d 172.20.58.206 k8s-node02 <none> <none>
stirlingpdf-testing stirlingpdf-79986c979d-vsf7z 1/1 Running 0 12d 172.20.85.199 k8s-node01 <none> <none>
traefik-system traefik-5554c9fdc4-5j4q6 1/1 Running 0 4d22h 172.20.58.226 k8s-node02 <none> <none>
tuxnetwiki-production tuxnetwiki-dokuwiki-64d6df4bf9-b5pcf 1/1 Running 0 7d 172.20.85.222 k8s-node01 <none> <none>
Der Produktive FHEM läuft aktuell noch als LX Container
VMID Status Lock Name
200 running p-checkmk
201 running p-fhem
202 running p-jitsi
205 running p-stun
206 running p-debmirror
207 running puppetmaster
208 running p-gitserver
210 running p-matrix
212 running p-psql01
213 running p-nextcloud
214 running p-mail
220 stopped p-jumphost
221 running p-mastodon
222 running p-ncsignal
ZitatAMD Ryzen 9 5950X
Wie lange braucht die "dicke Kiste" fuer die Schleife (s.o)?
Bei welchem Verbrauch?
Zitat von: rudolfkoenig am 19 Oktober 2023, 16:56:23ZitatAMD Ryzen 9 5950X
Wie lange braucht die "dicke Kiste" fuer die Schleife (s.o)?
Bei welchem Verbrauch?
Ich schätze mal 1.5 Sekunden im besten Fall. Die Stromkosten dürften dafür nicht unerheblich sein.
Zitat von: Ralli am 19 Oktober 2023, 14:03:37Ok, dann mache ich mal mit 8) :
NUC7i5: 2.35804009437561 s
NUC11i7: 1.42791604995728 s
lxc-Container, in dem FHEM auf dem NUC11 läuft, 2 Kerne und 4GB zugewiesen: 1.43110513687134 s
Proxmox 7er läuft bei mir seit Stunden stabil, die 8er blieb teilweise schon beim Booten hängen. Leider braucht die Schleife im debian lxc-Container fast 10 Sekunden, während sie in der 8er Version die Geschwindigkeit vom Host hatte, also 2,2 Sekunden.
Also nix mit lxc unter Proxmox 7, bei VMs wird dagegen die Hostpower der Kerne durchgereicht - schade eigentlich.
Zitat von: rudolfkoenig am 19 Oktober 2023, 16:56:23ZitatAMD Ryzen 9 5950X
Wie lange braucht die "dicke Kiste" fuer die Schleife (s.o)?
Bei welchem Verbrauch?
Also ich hab hier nen Ryzen 9 3900X mit 12 Kernen als Desktop-Rechner.
Macht unter Windows mit StrawberryPerl: 2.71870112419128
Dabei gönnt er sich ohne Last (Monitor dabei...) so 120W. Mit CPU Benchmark gerne 220 W. Da lief die GraKa aber noch nicht mit ;-)
Zitat von: Damian am 19 Oktober 2023, 17:46:52Zitat von: Ralli am 19 Oktober 2023, 14:03:37Ok, dann mache ich mal mit 8) :
NUC7i5: 2.35804009437561 s
NUC11i7: 1.42791604995728 s
lxc-Container, in dem FHEM auf dem NUC11 läuft, 2 Kerne und 4GB zugewiesen: 1.43110513687134 s
Proxmox 7er läuft bei mir seit Stunden stabil, die 8er blieb teilweise schon beim Booten hängen. Leider braucht die Schleife im debian lxc-Container fast 10 Sekunden, während sie in der 8er Version die Geschwindigkeit vom Host hatte, also 2,2 Sekunden.
Also nix mit lxc unter Proxmox 7, bei VMs wird dagegen die Hostpower der Kerne durchgereicht - schade eigentlich.
Welche Netzwerkkarte hast Du verbaut? Und schau mal bitte unter /var/log/kern.log oder journalctl -kr was dort so steht. So Auffälligkeiten.
Zitat von: rudolfkoenig am 19 Oktober 2023, 16:56:23ZitatAMD Ryzen 9 5950X
Wie lange braucht die "dicke Kiste" fuer die Schleife (s.o)?
Bei welchem Verbrauch?
Da habe ich mich ehrlich gesagt nie drum gekümmert ;D
Zitat von: CoolTux am 19 Oktober 2023, 19:42:52Zitat von: Damian am 19 Oktober 2023, 17:46:52Zitat von: Ralli am 19 Oktober 2023, 14:03:37Ok, dann mache ich mal mit 8) :
NUC7i5: 2.35804009437561 s
NUC11i7: 1.42791604995728 s
lxc-Container, in dem FHEM auf dem NUC11 läuft, 2 Kerne und 4GB zugewiesen: 1.43110513687134 s
Proxmox 7er läuft bei mir seit Stunden stabil, die 8er blieb teilweise schon beim Booten hängen. Leider braucht die Schleife im debian lxc-Container fast 10 Sekunden, während sie in der 8er Version die Geschwindigkeit vom Host hatte, also 2,2 Sekunden.
Also nix mit lxc unter Proxmox 7, bei VMs wird dagegen die Hostpower der Kerne durchgereicht - schade eigentlich.
Welche Netzwerkkarte hast Du verbaut? Und schau mal bitte unter /var/log/kern.log oder journalctl -kr was dort so steht. So Auffälligkeiten.
Die Netzwerkkarte ist: Intel® Ethernet Connection I219-V
Ich glaube mit der dieser Hardware wird das nix mit Proxmox, auch die 7er Version hat sich verabschiedet.
kern.log hat die gleichen Meldungen wie journalctl:
-- Journal begins at Thu 2023-10-19 09:32:01 CEST, ends at Thu 2023-10-19 20:36:46 CEST. --
Oct 19 19:05:41 pve pvedaemon[1046]: <root@pam> end task UPID:pve:0000437E:0007EAD6:65315CFA:vncproxy:105:root@pam: OK
Oct 19 19:05:44 pve pvedaemon[1045]: <root@pam> starting task UPID:pve:00005207:0009D78C:653161E7:vncproxy:105:root@pam:
Oct 19 19:05:44 pve pvedaemon[20999]: starting vnc proxy UPID:pve:00005207:0009D78C:653161E7:vncproxy:105:root@pam:
Oct 19 19:07:32 pve pveproxy[1053]: worker 11761 finished
Oct 19 19:07:32 pve pveproxy[1053]: starting 1 worker(s)
Oct 19 19:07:32 pve pveproxy[1053]: worker 21319 started
Oct 19 19:07:34 pve pveproxy[21318]: got inotify poll request in wrong process - disabling inotify
Oct 19 19:12:27 pve pvedaemon[1046]: worker exit
Oct 19 19:12:27 pve pvedaemon[1044]: worker 1046 finished
Oct 19 19:12:27 pve pvedaemon[1044]: starting 1 worker(s)
Oct 19 19:12:27 pve pvedaemon[1044]: worker 22161 started
Oct 19 19:13:16 pve pvedaemon[1045]: <root@pam> successful auth for user 'root@pam'
Oct 19 19:13:37 pve pvedaemon[1045]: <root@pam> end task UPID:pve:00005207:0009D78C:653161E7:vncproxy:105:root@pam: OK
Oct 19 19:13:37 pve pveproxy[21318]: worker exit
Oct 19 19:17:01 pve CRON[22994]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Oct 19 19:17:01 pve CRON[22995]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Oct 19 19:17:01 pve CRON[22994]: pam_unix(cron:session): session closed for user root
Oct 19 19:18:14 pve pvedaemon[1045]: <root@pam> successful auth for user 'root@pam'
Oct 19 19:21:44 pve pvedaemon[1045]: <root@pam> starting task UPID:pve:00005D29:000B4ECE:653165A8:vncproxy:102:root@pam:
Oct 19 19:21:44 pve pvedaemon[23849]: starting lxc termproxy UPID:pve:00005D29:000B4ECE:653165A8:vncproxy:102:root@pam:
Oct 19 19:21:44 pve pvedaemon[1047]: <root@pam> successful auth for user 'root@pam'
Oct 19 19:22:05 pve pvedaemon[1045]: <root@pam> end task UPID:pve:00005D29:000B4ECE:653165A8:vncproxy:102:root@pam: OK
Oct 19 19:22:23 pve pvedaemon[1047]: <root@pam> starting task UPID:pve:00005DD4:000B5DD9:653165CF:qmdestroy:101:root@pam:
Oct 19 19:22:23 pve pvedaemon[24020]: destroy VM 101: UPID:pve:00005DD4:000B5DD9:653165CF:qmdestroy:101:root@pam:
Oct 19 19:22:23 pve pvedaemon[1047]: <root@pam> end task UPID:pve:00005DD4:000B5DD9:653165CF:qmdestroy:101:root@pam: OK
Oct 19 19:23:00 pve pvedaemon[22161]: <root@pam> starting task UPID:pve:00005E3F:000B6C43:653165F4:qmstart:103:root@pam:
Oct 19 19:23:00 pve pvedaemon[24127]: start VM 103: UPID:pve:00005E3F:000B6C43:653165F4:qmstart:103:root@pam:
Oct 19 19:23:00 pve systemd[1]: Started 103.scope.
Oct 19 19:23:00 pve systemd-udevd[24139]: Using default interface naming scheme 'v247'.
Oct 19 19:23:00 pve systemd-udevd[24139]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 19 19:23:00 pve kernel: device tap103i0 entered promiscuous mode
Oct 19 19:23:00 pve systemd-udevd[24155]: Using default interface naming scheme 'v247'.
Oct 19 19:23:00 pve systemd-udevd[24155]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 19 19:23:00 pve systemd-udevd[24155]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 19 19:23:00 pve systemd-udevd[24139]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 19 19:23:00 pve kernel: vmbr0: port 5(fwpr103p0) entered blocking state
Oct 19 19:23:00 pve kernel: vmbr0: port 5(fwpr103p0) entered disabled state
Oct 19 19:23:00 pve kernel: device fwpr103p0 entered promiscuous mode
Oct 19 19:23:00 pve kernel: vmbr0: port 5(fwpr103p0) entered blocking state
Oct 19 19:23:00 pve kernel: vmbr0: port 5(fwpr103p0) entered forwarding state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 1(fwln103i0) entered blocking state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 1(fwln103i0) entered disabled state
Oct 19 19:23:00 pve kernel: device fwln103i0 entered promiscuous mode
Oct 19 19:23:00 pve kernel: fwbr103i0: port 1(fwln103i0) entered blocking state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 1(fwln103i0) entered forwarding state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 2(tap103i0) entered blocking state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 2(tap103i0) entered disabled state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 2(tap103i0) entered blocking state
Oct 19 19:23:00 pve kernel: fwbr103i0: port 2(tap103i0) entered forwarding state
Oct 19 19:23:00 pve pvedaemon[22161]: <root@pam> end task UPID:pve:00005E3F:000B6C43:653165F4:qmstart:103:root@pam: OK
Oct 19 19:32:27 pve pvedaemon[1047]: <root@pam> successful auth for user 'root@pam'
-- Boot 6b2a8bba6753410caf030f7429fbfa23 --
Oct 19 20:21:17 pve kernel: Linux version 5.15.102-1-pve (build@proxmox) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) >
Oct 19 20:21:17 pve kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.102-1-pve root=/dev/mapper/pve-root ro quiet
Oct 19 20:21:17 pve kernel: KERNEL supported cpus:
Oct 19 20:21:17 pve kernel: Intel GenuineIntel
Oct 19 20:21:17 pve kernel: AMD AuthenticAMD
Oct 19 20:21:17 pve kernel: Hygon HygonGenuine
Oct 19 20:21:17 pve kernel: Centaur CentaurHauls
Oct 19 20:21:17 pve kernel: zhaoxin Shanghai
Oct 19 20:21:17 pve kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Oct 19 20:21:17 pve kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Oct 19 20:21:17 pve kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Oct 19 20:21:17 pve kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
Oct 19 20:21:17 pve kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Oct 19 20:21:17 pve kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Oct 19 20:21:17 pve kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64
Oct 19 20:21:17 pve kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64
Oct 19 20:21:17 pve kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
Oct 19 20:21:17 pve kernel: signal: max sigframe size: 2032
Oct 19 20:21:17 pve kernel: BIOS-provided physical RAM map:
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000079b2bfff] usable
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x0000000079b2c000-0x0000000079f97fff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x0000000079f98000-0x000000007a014fff] ACPI data
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000007a015000-0x000000007a0c5fff] ACPI NVS
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000007a0c6000-0x000000007ab4ffff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000007ab50000-0x000000007ac0dfff] type 20
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000007ac0e000-0x000000007ac0efff] usable
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x000000007ac0f000-0x000000007fffffff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
Oct 19 20:21:17 pve kernel: BIOS-e820: [mem 0x0000000100000000-0x000000087dffffff] usable
Oct 19 20:21:17 pve kernel: NX (Execute Disable) protection: active
Oct 19 20:21:17 pve kernel: efi: EFI v2.70 by American Megatrends
Oct 19 20:21:17 pve kernel: efi: ACPI 2.0=0x79fb1000 ACPI=0x79fb1000 TPMFinalLog=0x7a050000 SMBIOS=0x7a9a4000 SMBIOS 3.0=0x7a9a3000 MEMATTR=0x77c23018 ESR>
Oct 19 20:21:17 pve kernel: secureboot: Secure boot disabled
Oct 19 20:21:17 pve kernel: SMBIOS 3.2.1 present.
Oct 19 20:21:17 pve kernel: DMI: Intel(R) Client Systems NUC8i5BEH/NUC8BEB, BIOS BECFL357.86A.0092.2023.0214.1114 02/14/2023
Oct 19 20:21:17 pve kernel: tsc: Detected 2300.000 MHz processor
Oct 19 20:21:17 pve kernel: tsc: Detected 2299.968 MHz TSC
Oct 19 20:21:17 pve kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Oct 19 20:21:17 pve kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Oct 19 20:21:17 pve kernel: last_pfn = 0x87e000 max_arch_pfn = 0x400000000
Oct 19 20:21:17 pve kernel: x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
Oct 19 20:21:17 pve kernel: last_pfn = 0x7ac0f max_arch_pfn = 0x400000000
Oct 19 20:21:17 pve kernel: esrt: Reserving ESRT space from 0x000000007ab4cf98 to 0x000000007ab4cfd0.
...
Der letzte Eintrag vor dem erzwungenen Neustart war um 19:32:27, die Meldungen beim Neustart um 20:21:17 und folgende waren auch alle unauffällig.
Da steht ja so gar nichts drin im Log was auffällig ist. MEM Test war Unauffällig?
Zitat von: CoolTux am 19 Oktober 2023, 21:15:33Da steht ja so gar nichts drin im Log was auffällig ist. MEM Test war Unauffällig?
ja, memtest86 ist mit 0 Fehlern durchgelaufen.
Als letztes probiere ich noch statt der NVMe-SSDs (EV0 970 plus 2tb bzw. EVO 980 pro 2tb) das System auf einer Sata-SSD (EVO 870 4tb) zu installieren.
ansonsten mit "stress" mal das System durchtesten.
Zitat von: Wernieman am 20 Oktober 2023, 08:18:00ansonsten mit "stress" mal das System durchtesten.
Einen Hardwaredefekt würde ich eher ausschließen, der Rechner lief vorher drei Jahre lang unter Windows ohne Probleme. Zum Teil bleibt er schon kurz nach dem Booten stehen, da wird er noch nicht mal warm.
Zitat von: Damian am 19 Oktober 2023, 17:46:52Proxmox 7er läuft bei mir seit Stunden stabil, die 8er blieb teilweise schon beim Booten hängen. Leider braucht die Schleife im debian lxc-Container fast 10 Sekunden, während sie in der 8er Version die Geschwindigkeit vom Host hatte, also 2,2 Sekunden.
Also nix mit lxc unter Proxmox 7, bei VMs wird dagegen die Hostpower der Kerne durchgereicht - schade eigentlich.
Ich hatte vor einer Weile auch solche Freezes mit ähnlichem Setup, 32 GB, Intel 8i5, meine Probleme waren mit PVE8 aber einem der ersten 6er Kernel aber mit verschiedenen.
Was letztendlich das Problem gelöst hat weiß ich nicht. Läuft jetzt stabil
Ich habe
- USB-HDD und SMB zum NAS(nicht immer Online) rausgenommen. Da waren mal Files offen und das hat Proxmox irgendwie nicht gemocht ohne was im Log aufzunehmen. Das war vermutlich bei mir das Problem
- Vollständig neu installiert ohne Backup oder clonen
- damals war auch einer der Kernel buggy
Ich war damals kurz vorm umsteigen. Es gibt keinen PVE Watchdog für Single Host sonst würde der Server wenigstens neu starten.
Linux Stresst den Rechner anders als Windows.
Zitat von: Damian am 20 Oktober 2023, 08:32:09Einen Hardwaredefekt würde ich eher ausschließen, der Rechner lief vorher drei Jahre lang unter Windows ohne Probleme. Zum Teil bleibt er schon kurz nach dem Booten stehen, da wird er noch nicht mal warm.
Um ggf. den Proxmox Kernel auszuschließen kannst ja mal Proxmox auf reinem Debian installieren. Ohne PVE Kernel werden manche Funktionen nicht laufen aber wenn dein Rechner schon nach dem Booten hängt könnte es der Kernel sein.
https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_11_Bullseye
Unter Debian kann man Proxmox zwar installieren. Aber es wird keine Virtualisierung laufen. War zu mindest bei mir so. Hatte vergessen in den Proxmox Kernel zu booten.
Aber nur so zum testen kann man es mal machen.
@Damian
Was für Speicherriegel hast Du da drin?
2 gleiche a 16GB?
Zitat von: CoolTux am 20 Oktober 2023, 10:18:46@Damian
Was für Speicherriegel hast Du da drin?
2 gleiche a 16GB?
ja, zwei mal die gleichen (identischen)
Zitat von: kadettilac89 am 20 Oktober 2023, 08:33:10Zitat von: Damian am 19 Oktober 2023, 17:46:52Proxmox 7er läuft bei mir seit Stunden stabil, die 8er blieb teilweise schon beim Booten hängen. Leider braucht die Schleife im debian lxc-Container fast 10 Sekunden, während sie in der 8er Version die Geschwindigkeit vom Host hatte, also 2,2 Sekunden.
Also nix mit lxc unter Proxmox 7, bei VMs wird dagegen die Hostpower der Kerne durchgereicht - schade eigentlich.
Ich hatte vor einer Weile auch solche Freezes mit ähnlichem Setup, 32 GB, Intel 8i5, meine Probleme waren mit PVE8 aber einem der ersten 6er Kernel aber mit verschiedenen.
Was letztendlich das Problem gelöst hat weiß ich nicht. Läuft jetzt stabil
Ich habe
- USB-HDD und SMB zum NAS(nicht immer Online) rausgenommen. Da waren mal Files offen und das hat Proxmox irgendwie nicht gemocht ohne was im Log aufzunehmen. Das war vermutlich bei mir das Problem
- Vollständig neu installiert ohne Backup oder clonen
- damals war auch einer der Kernel buggy
Ich war damals kurz vorm umsteigen. Es gibt keinen PVE Watchdog für Single Host sonst würde der Server wenigstens neu starten.
Ich habe auch schon alle USB-Platten abgehängt. Ich hatte ihm sogar verboten andere C-State einzunehmen, normalerweise hängt der im C08, was recht sparsam ist. Selbst als ich nur C01 erlaubt hatte (der Verbrauch war dann im Idle drei mal höher) ist der abgeschmiert.
Alleine die Tatsache, dass im Proxmox-Forum oft über "freezes" berichtet wird, ist kein gutes Zeichen für dieses System. Beim ESXi hatte z.B. ich keine Probleme. Ich könnte mir neue Hardware zulegen, ein AMD 5700U z.B. ist recht sparsam und hat die doppelte Power von dem intel-8259, aber irgendwie will ich das nicht einsehen, wegen Software gute und vor allem sparsame Hardware in Rente zu schicken.
Wenn das mit der Sata-SSD auch nicht klappt, werde ich einfach mal KVM unter debian ausprobieren. Ist zwar nicht so komfortabel wie Proxmox, aber hoffentlich stabiler.
Hab gerade mal meinen Thin Client Wyse N03D (https://www.parkytowers.me.uk/thin/wyse/3030/n03d.shtml) gemessen: 10 Sek.
Solche (lüfterlosen) Geräte gibt es immer wieder recht günstig in der Bucht.
Die verlinkte Seite ist übrigens eine tolle Quelle für die Suche nach weiteren geeigneten "Miniservern".
Zitat von: rudolfkoenig am 19 Oktober 2023, 16:56:23ZitatAMD Ryzen 9 5950X
Wie lange braucht die "dicke Kiste" fuer die Schleife (s.o)?
Bei welchem Verbrauch?
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
2.18686199188232
ZitatIch habe auch schon alle USB-Platten abgehängt. Ich hatte ihm sogar verboten andere C-State einzunehmen, normalerweise hängt der im C08, was recht sparsam ist. Selbst als ich nur C01 erlaubt hatte (der Verbrauch war dann im Idle drei mal höher) ist der abgeschmiert.
Alleine die Tatsache, dass im Proxmox-Forum oft über "freezes" berichtet wird, ist kein gutes Zeichen für dieses System. Beim ESXi hatte z.B. ich keine Probleme. Ich könnte mir neue Hardware zulegen, ein AMD 5700U z.B. ist recht sparsam und hat die doppelte Power von dem intel-8259, aber irgendwie will ich das nicht einsehen, wegen Software gute und vor allem sparsame Hardware in Rente zu schicken.
Wenn das mit der Sata-SSD auch nicht klappt, werde ich einfach mal KVM unter debian ausprobieren. Ist zwar nicht so komfortabel wie Proxmox, aber hoffentlich stabiler.
Hier mal ein Zwischenstand zum freeze-Problem:
hiernach https://forum.proxmox.com/threads/proxmox-freeze-on-intel-nuc.68322/#post-598926
bin ich nicht allein mit dem Problem. Die Beschreibung passt sehr gut zu meinem Problem und ich habe schon lange die Vermutung, dass es mit den Stromspar-Modi etwas zu tun hat. Intel scheint bei den NUCs alles aus dem Chipsatz an Stromsparmaßnahmen herauszuholen, was geht. Das macht sich auch in dem sehr niedrigen Stromverbrauch im Idle positiv bemerkbar.
Nachdem auch die SATA-SSD bei mir nicht geholfen hat, habe ich nun angefangen die Stromsparmaßnahmen abzuschalten. Als erstes habe ich die Speedstep-Technologie abgeschaltet. Ich könnte mir vorstellen, das durch das Absenken der Frequenz und vor allem der Reduzierung der Spannung der CPU bei der Virtualisierung eine Instabilität entsteht. Erstaunlicherweise macht das Abschalten von Speedstep nicht viel aus, ich kann kaum einen erhöhten Strombedarf im Idle feststellen, das Gesamtsystem pendelt weiterhin um die 6 Watt.
So jetzt erst mal schauen, wie lange die Kiste durchhält. Es gibt noch zwei weitere Optionen im Bios, die ich ggf. noch ausprobieren kann, wenn es nicht die Lösung war. Allerdings kommt das Abstellen des Turbomodus für mich nicht in Frage. Man kauft sich ja nicht einen teuren Rechner, um ihn dann zu einem Billigteil zu degradieren, die Performance halbiert sich.
Ich werde weiter berichten, sobald ich neue Erkenntnisse habe.
Danke für das Update.
Ich weiß, das hilft dir nicht, aber ich möchte hier noch einmal feststellen, dass ich seit über einem Jahr - angefangen mit der damaligen Version von PVE - auf dem NUC7 und dem NUC11 Proxmox einsetze und bislang NICHT EINEN EINZIGEN Freeze oder Absturz oder Reboot oder oder hatte - weder mit 5er noch mit 6er Kernel.
Zitat von: Ralli am 25 Oktober 2023, 16:57:09Danke für das Update.
Ich weiß, das hilft dir nicht, aber ich möchte hier noch einmal feststellen, dass ich seit über einem Jahr - angefangen mit der damaligen Version von PVE - auf dem NUC7 und dem NUC11 Proxmox einsetze und bislang NICHT EINEN EINZIGEN Freeze oder Absturz oder Reboot oder oder hatte - weder mit 5er noch mit 6er Kernel.
ja, es gibt ja immer Streuungen bei den CPUs, es kann ja sein, dass meine z. B. beim Reduzieren der Spannung kritischer im Zusammenhang mit der Virtualisierung ist, als deine. Ich habe schon Posts gelesen, dass jemand seinen NUC zurückgeschickt hat und beim neuen keine Probleme hatte.
Ich denke, die meisten NUCs laufen nicht im Virtualisierungsmodus und da fallen solche Probleme nicht auf, denn mein Rechner lief zuvor jahrelang ohne Virtualisierung ohne einen einzigen Absturz.
Sorry wenn Du es schon gemacht hast: Ist das BIOS aktuell?
ich war gerade etwas überrascht:
Die Schleife liefert in einer Debian-VM auf einem DELL T30
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
2.712406873703
Zitat von: Wernieman am 25 Oktober 2023, 20:16:57Sorry wenn Du es schon gemacht hast: Ist das BIOS aktuell?
ja, hatte ich schon geschrieben
übrigens das Abschalten von Speedstep reichte bei mir schon mal nicht - es hat zwei Stunden gehalten. Ich habe die nächste Spar-Option im BIOS deaktiviert.
Wie schon geschrieben, wenn das alles nichts hilft, werde ich KVM ausprobieren, wenn das dauerhaft stabil läuft, dann liegt es nicht nur an meinem Rechner.
Zitat von: pcbastler am 25 Oktober 2023, 21:15:11ich war gerade etwas überrascht:
Die Schleife liefert in einer Debian-VM auf einem DELL T30
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
2.712406873703
Wieso? Das alte Schätzchen dürfte für diese Leistung schön Stromhungrig sein.
Zitat von: Damian am 25 Oktober 2023, 22:24:47Zitat von: Wernieman am 25 Oktober 2023, 20:16:57Sorry wenn Du es schon gemacht hast: Ist das BIOS aktuell?
ja, hatte ich schon geschrieben
übrigens das Abschalten von Speedstep reichte bei mir schon mal nicht - es hat zwei Stunden gehalten. Ich habe die nächste Spar-Option im BIOS deaktiviert.
Wie schon geschrieben, wenn das alles nichts hilft, werde ich KVM ausprobieren, wenn das dauerhaft stabil läuft, dann liegt es nicht nur an meinem Rechner.
Ich habe die letzte mögliche Option der Sparmodi deaktiviert mit der Konsequenz, dass der Rechner nicht mehr in den Turbomodus schalten kann, damit erreicht er bei der Performancemessung nur noch 3,5 Sekunden, also fast die halbe Leistung der möglichen. Ich lasse es jetzt so paar Tage laufen um sagen zu können, ob das System damit stabil ist oder nicht. Dass es für mich keine Option ist, habe ich schon geschrieben. Danach werde ich Proxmox von der Platte entfernen - zumindest auf diesem Rechner.
Eine Rückmeldung werde ich hier noch posten.
Zitat von: Damian am 26 Oktober 2023, 14:56:05Ich habe die letzte mögliche Option der Sparmodi deaktiviert mit der Konsequenz, dass der Rechner nicht mehr in den Turbomodus schalten kann, damit erreicht er bei der Performancemessung nur noch 3,5 Sekunden, also fast die halbe Leistung der möglichen. Ich lasse es jetzt so paar Tage laufen um sagen zu können, ob das System damit stabil ist oder nicht. Dass es für mich keine Option ist, habe ich schon geschrieben. Danach werde ich Proxmox von der Platte entfernen - zumindest auf diesem Rechner.
Eine Rückmeldung werde ich hier noch posten.
Update
Ich konnte in der Zwischenzeit neue Erkenntnisse sammeln. Ich denke es könnte für den einen oder anderen interessant sein.
Nachdem alle möglichen Optionen des BIOS keine Besserung brachten, habe ich zunächst Debian 12 installiert und darauf KVM. Es hat nicht lange gedauert - Absturz.
OK, dachte ich, vielleicht liegt es an Debian, da der gleiche Kernel verwendet wird wie bei Proxmox, also Ubuntu installiert, KVM brauchte ich schon nicht mehr installieren, denn auch da gleiches Verhalten. Also hat es vielleicht doch nichts mit Virtualisierung zu tun, war mein Gedanke.
Dann habe ich überlegt, was sich in der letzten Zeit an der Rechnerkonstellation geändert hat, schließlich lief er zuvor unter Windows lange Zeit ohne Probleme.
Der Rechner hatte von Anfang an einen 16 GB RAM-Riegel 2666 Mhz-Dual-Rank, dann habe ich ihm vor einem halben Jahr einen weiteren 16 GB RAM-Riegel 3200 Mhz-Single-Rank spendiert. Der Rechner selbst kann maximal 2400 Mhz. Diese Konstellation lief ein halbes Jahr ohne Problem.
Vor einem Monat brauchte ich für einen anderen Rechner einen 16 GB Riegel, also kaufte ich wieder den 16 GB 3200 Mhz-Single-Rank, um zukunftssicher zu sein. Dann dachte ich zwei gleiche Riegel in einem System wären besser als zwei verschiedene, also habe ich die beiden 3200 Mhz-Riegel in den NUC gesteckt und den 2666 Mhz in den anderen Rechner - das war wohl ein Fehler.
Offenbar verträgt der NUC8i5 die 3200 Mhz-Single-Rank Riegel nicht gut. In Kombination mit dem 2666 Mhz-Dual-Rank werden möglicherweise andere Einstellung vorgenommen, sodass der 3200 Mhz-Riegel keine Probleme macht - hat ja schließlich ein halbes Jahr unter Windows ohne Probleme funktioniert. Zumindest läuft Proxmox nun seit 16 Stunden ohne Zwischenfälle.
Sollte es doch noch einen Absturz geben, werde ich einen zweiten 16 GB 2666-Dual-Rank Riegel kaufen und hoffen, dass sich damit die Probleme erledigt haben.
Ein Memtest mit der alten Konfiguration hatte keinen Fehler produziert?
Zitat von: Wernieman am 29 Oktober 2023, 10:02:03Ein Memtest mit der alten Konfiguration hatte keinen Fehler produziert?
Nein. Ich denke, der hätte vermutlich nie Fehler gebracht, sondern der Rechner wäre eher abgestürzt, aber das machte er ja nach Tagesform mehr oder minder häufig.
Nun muss ich Proxmox in Schutz nehmen, wenn die Hardware stimmt, dann läuft alles.
Bisher keine Abstürze gehabt. Es sind einige VMs aktiv, sogar ein Proxmox Backup-Server (wegen inkrementeller Backups) als VM mit einer externen Platte - ist schon toll was man inzwischen alles zuhause laufen lassen kann, vor ein paar Jahren wäre das Home-Projekt alleine wegen der Stromkosten gescheitert.
Allerdings konnte ich heute einem Angebot nicht widerstehen und habe einen Minirechner mit doppelter Power (Ryzen 5560U) für knapp 200 Euro als zukünftigen Server erworben.
Freut mich, dass die Ursache gefunden wurde. Und nun wünsche ich dir viel Spaß mit deinem neuen Home-Lab :D .
Da auch ich in dieser Richtung ein Spielkind bin, habe ich mir zur Erweiterung meines Proxmox-Clusters mit HA noch einen refurbished HP EliteDesk G2 800 Mini Desktop i7-6700T gegönnt. Damit ersetze ich den RPi mit QDevice durch einen vollwertigen dritten Node. Haben ist besser als Brauchen 8) .
Nächstes Update zum Thema Hardware.
Ich habe nun auf dem neuen Mini (Ryzen 5560U) Proxmox installiert und die virtuellen Maschinen vom NUC (i5 8259U) per Server Backup herübergezogen - das hat funktioniert.
Einen kleinen Unterschied gibt es bei den C-States, während der Intel-Prozessor bis auf c10 herunter geht, ist beim AMD maximal c3 möglich, das macht sich etwas im Idle-Stromverbrauch bemerkbar.
Gemessen habe ich nur ein laufendes Proxmox ohne laufende VMs, also das absolute Minimum beim laufenden System (siehe Screenshot)
An die 3,27 Watt vom Intel-NUC muss ein Raspi mit einer Festplatte mit einem USB-Adapter erstmal herankommen :)
Beim AMD sind es dann 4,47 Watt, fairerweise muss man dazu sagen, steckt im AMD zusätzlich eine sata SSD drin, die allerdings im Idle kaum Energie verbraucht.
Etwas überrascht war ich allerdings von unserer Perl-Schleife, obwohl der AMD-5560U im Vergleich zum Intel-8259U lt. offizieller Benchmarks im Single Core fast 30 % mehr Performance bietet, läuft die Schleife mit ca. 2,2 Sekunden gleich schnell.
Dennoch werde ich den neuen Mini (AMD) zum Hauptserver machen, da er mit 6/12 Kernen insgesamt die doppelte Leistung des Intel-NUC mit 4/8 Kernen bietet und das bei 15 Watt TDP statt 28 Watt TDP beim NUC, was sich sicherlich unter Last bemerkbar machen würde.
Als nächstes werde ich die fhem-Installation vom raspi auf die neue VM-Maschine übertragen und danach den Raspi abschalten.
Mal schauen, was ich mit dem NUC nun mache, vermutlich lasse ich ihn als zweiten Proxmox-Server laufen, da kann er als Proxmox-Backupserver (als VM) weiter leben. Solange kein VM-Window-läuft tuckert er bei laufender Proxmox-Backupserver-VM auch nur mit 4,7 Watt.
Und wenn mir das noch zu viel an Stromverbrauch wird, dann kann man ihn per WOL-Script vor dem Backup wecken und danach wieder schlafen legen.
Wenn man bedenkt, dass man im Angebot für 213 Euro einen neuen Rechner mit der Power von 17! Raspis 4 als 6/12 Kernmaschine mit 16 GB und 500 GB SSD bekommt, die kaum mehr als ein Raspi an Strom verbraucht, dann erscheinen ca. 100 Euro für einen Raspi mit Netzteil, USB-SSD-Adapter und externer SSD mit einem Bruchteil der Performance als viel zu viel.
Daher kann ich die Aussage von Andreas Spiess bestätigen, wenn man etwas mehr machen will: "Besser als ein Raspi 5 ..."
Lasse den NUC als zweiten Node laufen und mache einen Cluster draus. So hast du eine einfache Redundanz. Für den Fall, dass der Spieltrieb stärker wird, nutze den RPi für ein QDevice und mache das ganze zu einer HA-Umgebung.
Ich habe meinen RPi mit QDevice jetzt aktuell ersetzt durch einen HP EliteDesk G2 800 i7 6700T und habe für ein paar Watt mehr nun einen "echten" dritten Node.
2.24843406677246 Sekunden.
Zitat von: Ralli am 04 November 2023, 15:33:56Lasse den NUC als zweiten Node laufen und mache einen Cluster draus. So hast du eine einfache Redundanz. Für den Fall, dass der Spieltrieb stärker wird, nutze den RPi für ein QDevice und mache das ganze zu einer HA-Umgebung.
Ich habe meinen RPi mit QDevice jetzt aktuell ersetzt durch einen HP EliteDesk G2 800 i7 6700T und habe für ein paar Watt mehr nun einen "echten" dritten Node.
2.24843406677246 Sekunden.
ja, das war auch meine Idee. Die Clusterkonfiguration muss ich mir noch anschauen, bisher hatte ich nur einen Node ;)
Gleichzeitig läuft ja auf dem NUC ja der Proxmox Backupserver als VM, somit habe ich schon mal eine physikalische Trennung der VMs und der Backups.
Jetzt muss ich nur noch, wie im Rechenzentrum, den Backupserver drei Etagen tiefer im Haus aufstellen, um eine räumliche Trennung zu haben :)
Was würde man zuhause nur ohne Home-Lab machen? :)
Update
Tja, was man inzwischen alles zuhause für kleines Geld als home lab laufen lassen kann.
Ich habe inzwischen auf einem Mini PC mit 14 Kernen sechs VMs laufen (FHEM, Windows, Home Assistant, Zigbee2Mqtt, Proxmox Backupsystem, Nextcloud, OMV).
48GB RAM, 6TB SSDs und 3TB HDD für Backups.
Braucht alles zusammen 18 Watt.
Auch die Performance kann sich sehen lassen:
perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
1.2419741153717
Ich warte noch auf den Tag, wo der erste unter eine Sekunde kommt ;D
Das ist eine interessante Zusammenfassung der Leistung die mich neugierig macht, könntest Du weitere Details (CPU, Speichertyp und bei der Ausstattung eine Zahl für kleines 'kleines Geld' angeben. Wie ist die Auslastung der VM, bei der angegebenen Leistung.
Es handelt sich um den NAB7 14/20 Kerne von Minis Forum (339 Euro als Barebone, Speicher, Platten usw. konnte ich übernehmen). Eigentlich ist es schon zu viel des Guten. Zuvor lief das System auf einem alten NUC 4/8 Kerne. In den VMs passiert nicht viel, daher pendelt die Auslastung des Systems um 1%. Die Schwuppdizität insb. bei Windows-VM per RDP ist etwas besser als zuvor, allerdings wird sie mit 18 Watt gegenüber 10 Watt bei 1% Last schon teuer als Dauerläufer erkauft. Der NUC hat auch nicht viel mehr als 1% Gesamtlast gehabt. Er war eigentlich gut genug, es war viel mehr der Reiz sich zu steigern und etwas neues auszuprobieren. Sollte allerdings das neue System richtig gefordert werden, würde sich der kleine auch 100 Watt gönnen, das passiert bei mir aber selten.
Wichtig war mir neben der nvme-Schnittstelle auch SATA für meine 4TB SSD, zwei Netzwerkkarten mit 2.5 GBit und die Nutzung von DDR4-Speicher, den ich übernehmen konnte.
Es ist inzwischen schon der vierte Mini, den ich besitze. Im Grunde habe ich das gesamte System mit allen VMs auf allen vier Minis bereits zufriedenstellend ausprobiert - das Umstecken der SSD mit allen VMs reichte schon - das System lief einfach weiter, egal ob Intel- oder AMD-Plattform. Einen Beelink mit dem N100-Prozessor nutze ich jetzt als zusätzlichen Backupserver, den ich automatisiert in den Standby schicke und für ein Backup wecke.
Meine beiden Raspis habe ich inzwischen in Rente geschickt. Wenn man einmal die Vorzüge der Virtualisierung kennengelernt hat, möchte man nicht mehr zurück.
Zitat von: Damian am 24 Juni 2024, 00:40:28Meine beiden Raspis habe ich inzwischen in Rente geschickt. Wenn man einmal die Vorzüge der Virtualisierung kennengelernt hat, möchte man nicht mehr zurück.
Dem kann ich nur beipflichten. Früher hatte ich nur einen Raspi auf dem FHEM lief und wenn ich was Neues testen wollte, hab ich extra vorher die SD-Karte gesichert.
Mit Proxomx erstellt man einfach einen neuen Container, testet darin - und man trennt HTTP-Server, FHEM usw einfach auf, statt alles auf einem System laufen zu lassen.
Rasperrys sind für mich nicht mehr interessant. Ich habe nur einen im Vergleich schwachen Mini-PC "Asus VivoPC / Mini-PC VC60-B013M". Ich habe ihn bisher nur mit Zoneminder und Gesichtserkennung in die Knie gezwungen - sonst keine Probleme. Im Screenshot meine Auslastung der letzten Woche (durchschnitt). BTW: auf dem Hostsystem läuft nicht nur Proxmox sondern auch Kodi.
Für mich kommt ein Raspi nicht mehr in Frage. Raspi höchstens wenn es wirklich nur FHEM können soll, sonst nix.
Ansonsten meiner Meinung nach immer einen Mini-PC, Virtuallisierung (Proxmox).
Ist jetzt fast Offtopic, aber vielleicht an dieser Stelle doch für den einen oder anderen interessant.
Nachdem ich meinen Server aufgerüstet habe und von dem Overkill-Server (14C/20T) begeistert war (besser haben als brauchen), hat mich der angestiegene Stromverbrauch (in der Grundlast von ca. 10 Watt auf 18 Watt) doch etwas enttäuscht. Daraufhin habe ich meine 24/7 Stromverbraucher noch mal genauer nachgemessen. Was gar nicht passte, war die Tatsache, dass meine Fritzbox 7590 AX sich 16 Watt gönnte, fast so viel wie der neue Server.
Heute wurde sie gegen eine 7530 AX ausgetauscht. Sie hat vergleichbare Features wie die 7590 AX, ist mit OS 7.81 genauso aktuell, hat Wireguard, hat sogar einen schnelleren Prozessor, was sich sofort bei der Bedienung der Fritzbox bemerkbar macht und kostet nur die Hälfe. WLAN ist genauso stabil (die theoretischen Übertragungsraten der 7590 AX wurden ohnehin nie erreicht) und jetzt kommts, sie braucht nicht mehr als 6 Watt, also 10 Watt weniger.
Nun stimmt wieder meine Gesamt-Strombilanz und das mit einem Höllen-Server ;D
Vielleicht könnt Ihr eine Kaufempfehlung abgeben. Ich würde gerne mit meinen Containern und VMs von der Synology auf einen Proxmox-Server umziehen. Bisher laufen in der Umgebung FHEM, Zigbee2MQTT, DeConz, Mosquitto usw. völlig problemlos und auch ausreichend performant. Falls aber mal eine Festplatte auf der DS ausfällt, dürfte das Wiederherstellen der Systeme recht aufwändig sein. Ich verspreche mir durch die Migration von Serverdiensten auf einen Proxmox-Server eine höhere Ausfallsicherheit und eine schnellere Wiederherstellung, falls es mal zu Problemen kommt.
Welchen Intel NUC würdet Ihr mir Stand heute empfehlen? Die schiere Menge an unterschiedlichen Konfigurationen erschlägt mich förmlich. Auf dem Gerät soll wie gesagt ausschließlich PVE laufen und dort dann virtualisiert FHEM, Zigbee, MQTT und alles, was zukünftig noch so an Services anfallen könnte. Gerne auch eine Windows-VM, die jedoch nur bei Bedarf laufen soll.
Mir wäre ein guter Kompromiss aus Leistung und Leistungsaufnahme wichtig. Gibt es Prozessoren, die sich besonders für Virtualisierungen anbieten?
Über ein, zwei Tipps würde ich mich sehr freuen.
LG
Oli
Wie man dem Thread hier entnehmen kann, experimentiere ich seit Oktober mit Proxmox. FHEM unter Proxmox ist bei mir seit über einem halben Jahr produktiv.
Ich habe Proxmox auf vier verschiedenen Mini PC getestet, hier eine kleine Zusammenfassung meiner Erfahrungen. Die vier Rechner sortiert nach CPU-Leistung und gleichzeitig nach Stromverbrauch:
-Ein Mini PC mit N100-CPU (4C/4T) (ca. 10 Watt Grundlast mit 7 VMs) (ca. 200 Euro 16GB/512GB) wird bei mir inzwischen als zweiter Proxmox-Backup-Server genutzt, hat zwei 2,5 Gbit Netzwerkkarten
-Ein alter NUC 8i5beh (4C/8T) (ca. 10 Watt Grundlast mit 7 VMs) (nur noch gebraucht zu kaufen) war mein vorletzter Produktiv-Rechner unter Proxmox, hat gut funktioniert
-Ein Mini PC mit AMD-5560U (6C/12T) (ca. 10 Watt Grundlast mit 7 VMs) (ca. 280 Euro 16GB/512GB) mein Preis/Leistung-Sieger, hat aber keinen 2,5 Gbit Netzwerkanschluss, wird z. Zt. als Schreibtischrechner unter Windows genutzt
-Ein Mini PC mit Intel 12700H (14C/20T) (ca. 500 Euro 32GB/1TB) (ca. 18 Watt Grundlast mit 7 VMs), hat entsprechend mehr Power und große Leistungsreserven, ist mein aktueller Produktiv-Rechner, hat zwei 2,5 Gbit Netzwerkanschlüsse, ist eigentlich schon ein Overkill für die 7 VMs
Performancevergleich der vier Rechner-CPUs:
https://www.cpubenchmark.net/compare/5157vs3299vs4883vs4721/Intel-N100-vs-Intel-i5-8259U-vs-AMD-Ryzen-5-5560U-vs-Intel-i7-12700H
Es laufen folgende VMs: FHEM, Nextcloud, Zigbee2mqtt, OMV, Proxmox-Backup-Server als VM, Windows 11, Home Assistent
Die Auslastung des Proxmox-Servers liegt im Normalbetrieb bei dem schnellsten Rechner (12700H) bei ca. 0,5%, beim langsamsten (N100) bei ca. 2%, die anderen liegen dazwischen.
Ich würde heute darauf achten, dass man den Server auf mindestens 32GB erweitern kann (am besten gleich mit 32GB kaufen), zwei interne Festplatten einbauen kann, und der Server einen 2,5 Gbit Netzwerkanschluss hat.
Alle Rechner haben für meinen Einsatzzweck (siehe VMs oben) genug Power gehabt, die "Schwuppdizität" ist beim stärksten natürlich am besten, wegen der starken Single-Core-Performance, sie wird aber teuer mit doppeltem Stromverbrauch erkauft. Die Leistungsreserven sind natürlich beim schwächsten N100 mit 4 Thread am geringsten, beim stärksten mit 20 Threads am größten.
Die Intel 12er-CPU-Reihe mit Performance- und Effizienz-Kernen läuft bei mir ohne jegliche Zwischenfälle (es gab anfangs Probleme unter Proxmox).
Original-NUCs sind aus der heutigen Sicht viel zu teuer, wenn man für die Hälfte gut funktionierende China Mini-PCs bekommt, die genauso sparsam sind und gleiche Performance bieten.
ZitatOriginal-NUCs sind aus der heutigen Sicht viel zu teuer ...
Und meines Wissens auch nicht mehr von Intel.
Noch ein Hinweis: Wenn Du Dich im 10W Bereich bewegst und der Server in einem normalen Raum sich befindet, würde ich auf Passive Kühlung achten.
Mein aktueller Rechner ist ein Zotac 340CI (gibt es nicht mehr), offiziell bis 8GByte Hauptspeicher, läuft hier aber mit 16GByte. Habe auch nur 1 SSD drin, mehr bedeutet mehr Stromverbrauch. Natürlich ist der Rechner "weg", wenn die SSD "weg" ist, aber dafür habe ich Backup (hoffentlich ;o) ). Habe zwar kein Proxmox, sondern Docker-Container am laufen, dafür läuft er mit 7W super. Würde bis heute in der Kategorie bleiben, eventuell wie m ein Vorredner schrieb, auf 32GByte wegen Zukunftssicherheit achten.
Hey, Ihr beiden!
Lieben Dank für die sehr ausführlichen Antworten.
Ich war jetzt kurz davor, mir auf Kleinanzeigen einen gebrauchten NUC i5/i7 für 200 - 250 Euro zu kaufen, bin dann aber aufgrund Damiens Hinweisen auf einen Beelink Mini S12 Pro mit N100, 16GB RAM und 512GB M2 SSD gestoßen. Den gab es bei Amazon für 189 Euro. Der hat zwar nur 1GB-LAN, aber ich denke, dass das für meine Anwendungen auch ausreichen wird. Ich plane nicht, große Datenmengen auf das Ding zu schieben. Das Gute ist, dass man bei den Preisen auch mal ein bisschen rumprobieren kann. Wenn ich dann feststelle, dass es irgendwo einen Flaschenhals gibt, dann probiere ich was anderes und habe nicht viel Geld in den Sand gesetzt.
Ich werde meine Synology als PVE-Backup Server einrichten. Eine M2 SSD habe ich auch noch ungenutzt im Schrank liegen. Falls die SSD im Proxmox-Server mal abrauchen sollte, sollte der Server mit neuer SSD und den Backups recht schnell wieder laufen.
Der PC kommt noch heute und freu mich schon darauf, FHEM, Zigbee, MQTT, Homebridge zu migrieren.
Ich werde später mal ein Feedback geben, wie es gelaufen ist.
LG
Oli
So, seit zwei Tagen läuft mein ganzes Geraffel (FHEM, MQTT, Devons, Z2M, Homebridge) stabil und flüssig auf dem kleinen Kästchen mit Proxmox. Es gab zwar den einen oder anderen Stolperstein, wie beispielsweise die ganzen Abhängigkeiten der Systeme untereinander wieder gerade zu ziehen, aber mittlerweile bin ich sehr zufrieden.
Obwohl meine Diskstation jetzt auch nicht sonderlich schwach auf der Brust ist, fühlt sich FHEM nun auch deutlich leichtfüßiger an. Auf der DS läuft jetzt nur noch eine VM mit einem PVE-Backup-Server. Einen kompletten Restore aller LXC und VM habe ich auch schon erfolgreich absolviert. Das Ganze hat inklusive Neuinstallation von PVE auf einer neuen SSD keine halbe Stunde in Anspruch genommen.
Was ich mich noch frage, ist, wieviel CPU-Kerne ich der FHEM-VM am besten zuweisen soll. Ich meine mal gelesen zu haben, dass FHEM nur einen Kern nutzen kann. Oder macht es aus irgendwelchen anderen Gründen Sinn, der VM mehr als einen Kern zuzuweisen?
LG
Oli
Hallo
Wieviel Watt gönnt sich der S12 Pro mit N100 denn so? Musstest du Feintuning am BIOS betreiben um den Verbrauch zu optimieren?
Gruß Ralf
Den Verbrauch habe ich ehrlich gesagt noch gar nicht gemessen. Werde ich aber am Wochenende mal machen.
Ich bin zwar einmal vor der Installation von PVE kurz durchs BIOS, hab mich aber im Einzelnen noch nicht mit Details beschäftigt.
LG
Oli
ZitatWas ich mich noch frage, ist, wieviel CPU-Kerne ich der FHEM-VM am besten zuweisen soll. Ich meine mal gelesen zu haben, dass FHEM nur einen Kern nutzen kann.
FHEM verwendet normalerweise einen Kern, es gibt aber Ausnahmen:
- manche Module laufen in einem separaten Prozess (Stichwort Blocking).
- um die SVGs zu berechnen startet FHEM auf Mehrkern-Rechnern weitere Prozesse. Die Anzahl der Prozesse haengt von Anzahl der Browser-Anfragen ab, typisch ist bis zu 5 weitere Prozesse.
Ich wuerde FHEM 6 Kerne zuweisen, und sie nicht exklusiv fuer FHEM reservieren.
Danke, Rudi.
Ich hab FHEM jetzt 4 Cores zugewiesen. Mit 6 startete FHEM nicht. PVE sagt "MAX 4 vcpus allowed".
Die Leistungsaufnahme schwankt in dieser Konfiguration zwischen 9 und 11 Watt.
LG
Oli
EDIT: Ja, kein Wunder! Die CPU hat ja auch nur 4 Kerne...
ZitatIch hab FHEM jetzt 4 Cores zugewiesen. Mit 6 startete FHEM nicht. PVE sagt "MAX 4 vcpus allowed".
Liegt vmtl daran, dass der N100 nur 4 Kerne hat.
>:(
Zitat von: rudolfkoenig am 04 August 2024, 08:16:34ZitatIch hab FHEM jetzt 4 Cores zugewiesen. Mit 6 startete FHEM nicht. PVE sagt "MAX 4 vcpus allowed".
Liegt vmtl daran, dass der N100 nur 4 Kerne hat.
Ich habe bei mir 2 Kerne für FHEM zugewiesen - das reicht bei mir alle Male aus. Ich nutze allerdings keine SVG-Plots.
Zitat von: RalfRog am 02 August 2024, 22:28:06Hallo
Wieviel Watt gönnt sich der S12 Pro mit N100 denn so? Musstest du Feintuning am BIOS betreiben um den Verbrauch zu optimieren?
Gruß Ralf
Ich nutze einen Beelink SER5PRO mit AMD Ryzen7 8C/16T, mit 1TB-NVME, 8TB-SATASSD, 4 USB-Dongles (1wire,ZWave,Homematic,CUL) zieht er sich im Idle 7w.
Über den Tag im Schnitt 0,22 kWh.
Es läuft 24/7:
FHEM LXC 2 Cores
DietPi-VM 4Cores
pihole LXC 1core
heimdalldashboard LXC 1core
nginxproxymanager LXC 1core.
BIOS oder ProxmoxHost noch ohne Poweroptimization
Hallo Ihr FHEM Profis,
darf ich hier bitte mal quer einsteigen.
Da ich drei produktive Raspberrys am laufen habe, überlege ich auch immer wieder, ob es nicht Sinn machen würde,
alles auf einen leistungsfähigen Mini-PC umzubauen.
Mein Grund warum ich es bisher nicht umgestalten kann, sind immer noch die GPIO-Ports. Für die onewire Temperatursensoren gibts dank den Shelly Addons ja mittlerweile gute Lösungen.
Ich habe aber immer noch mehrere 8 Kanal Relaisplatinen die auch 230 Volt Lastrelais steuern.
Ebenso sind auch noch mehrere potenialfreie 230 Volt Relais (auf GPIO Eingänge) zum erfassen von 230 Volt Außen- Bewegungsmelder in meinem Netz vorhanden.
Kennt jemand auch dafür Lösungen, um auf die empfindlichen GPIO Kanäle zu verzichten?
Hoffentlich "passt" meine Frage einigermaßen in diesen Thread.
Vielen Dank für Euer Profiwissen - das mir in den ca. 8 Jahren FHEM auch ohne eine Informatiker Ausbildung
immer wieder super Möglichkeiten eröffnet hat.
Viele Grüße und einen guten gesunden Start ins neue Jahr.
P.S. Überrascht bin ich, dass ein Mini-PC mit so wenig Stromverbrauch auskommen kann.
Ich würde dir Tasmota mit einem esp empfehlen. Damit kannst du 1-wire Temperaturen, Impulszähler, Stromzähler auslesen usw. oder Relais schalten. Kommunizieren kannst du per MQTT. Das funktioniert recht zuverlässig, ist preisgünstig, blockiert dein System nicht und lässt sich entfernt vom Server betreiben.
Zitat von: Damian am 29 Dezember 2024, 21:46:50Ich würde dir Tasmota mit einem esp empfehlen. Damit kannst du 1-wire Temperaturen, Impulszähler, Stromzähler auslesen usw. oder Relais schalten. Kommunizieren kannst du per MQTT. Das funktioniert recht zuverlässig, ist preisgünstig, blockiert dein System nicht und lässt sich entfernt vom Server betreiben.
Ergänzung dazu: Es gibt ESP32, die gleich ein LAN-Modul verbaut haben - dann allerdings weniger PINs direkt zur Verfügung stellen. Die könnte man aber auch mit i2c-Bausteinen aufrüsten (v.a. zum Schalten von Relays etc.). Relativ günstig und neuerdings mit eigenem Treiber für Tasmota z.B.: https://tasmota.github.io/docs/MCP230xx/
(Tasmota könnte dann z.B. einen Teil der Relays auch direkt als Rollladenaktor verwenden...)
Oder du wechselst das Pferd und setzt (für die Outputs) sowas ein (würde immer die ZigBee-Version nehmen!): https://de.aliexpress.com/item/1005007273195157.html?spm=a2g0o.productlist.main.47.6e232c95AdhT0A&algo_pvid=611c0bd8-4ae7-490b-8169-2e867d1d5646&algo_exp_id=611c0bd8-4ae7-490b-8169-2e867d1d5646-23&pdp_npi=4%40dis%21EUR%2194.29%2146.19%21%21%21701.04%21343.45%21%40211b615317355389557706519ef317%2112000040023983551%21sea%21DE%212808040319%21X&curPageLogUid=AVawet3JGeQ2&utparam-url=scene%3Asearch%7Cquery_from%3A (Tuya 24 Kanal Smart Wifi/ZigBee Wireless Relais Switch Modul App RF Fernbedienung Smart Home Automation Modul 12V, https://zigbee.blakadder.com/Tuya_TY16-V7030.html)
Zitat von: Damian am 26 Juli 2024, 12:51:25Wie man dem Thread hier entnehmen kann, experimentiere ich seit Oktober mit Proxmox. FHEM unter Proxmox ist bei mir seit über einem halben Jahr produktiv.
Ich habe Proxmox auf vier verschiedenen Mini PC getestet, hier eine kleine Zusammenfassung meiner Erfahrungen. Die vier Rechner sortiert nach CPU-Leistung und gleichzeitig nach Stromverbrauch:
-Ein Mini PC mit Intel 12700H (14C/20T) (ca. 500 Euro 32GB/1TB) (ca. 18 Watt Grundlast mit 7 VMs), hat entsprechend mehr Power und große Leistungsreserven, ist mein aktueller Produktiv-Rechner, hat zwei 2,5 Gbit Netzwerkanschlüsse, ist eigentlich schon ein Overkill für die 7 VMs
Es laufen folgende VMs: FHEM, Nextcloud, Zigbee2mqtt, OMV, Proxmox-Backup-Server als VM, Windows 11, Home Assistent
Die Auslastung des Proxmox-Servers liegt im Normalbetrieb bei dem schnellsten Rechner (12700H) bei ca. 0,5%, beim langsamsten (N100) bei ca. 2%, die anderen liegen dazwischen.
Ich würde heute darauf achten, dass man den Server auf mindestens 32GB erweitern kann (am besten gleich mit 32GB kaufen), zwei interne Festplatten einbauen kann, und der Server einen 2,5 Gbit Netzwerkanschluss hat.
Die Intel 12er-CPU-Reihe mit Performance- und Effizienz-Kernen läuft bei mir ohne jegliche Zwischenfälle (es gab anfangs Probleme unter Proxmox).
Servus,
ich bin gerade mal wieder in UpgradeLaune. Liegt wohl auch daran, das FHEM@Proxmox langweilig stabil läuft. Da ich den ProxmoxServer auch als temporären Mediaserver nutze, brauche ich mehr jetzt Platz, und mein Ryzen7 ist da ausgereizt.
Da würde sich anbieten, meinen Alltagsrechner (MinisForum NAD9 mit Intel i9-12900H und M2-NVME + 2x SATA) als ProxmoxServer umzubauen.
Jedoch bin ich vom Stromverbrauch meines AMD Ryzen mit 7w Idle sehr verwöhnt.
Du schreibst von Deinem i7-12700H mit einem Idle von 18W. Allerdings hast Du auch eine Win-VM darauf laufen. Wenn ich die bei meinem Ryzen starte, ist auch nichts mehr mit 7w. Hast Du mal den Verbrauch ohne die Win11-VM gemessen ? Dann könnte ich prima vergleichen, und einem MinisForum UM880plus als Desktoprechner (Video+Photobearbeitung) steht nichts mehr im Wege....
Zitat von: Bartimaus am 05 August 2025, 14:31:48Zitat von: Damian am 26 Juli 2024, 12:51:25Wie man dem Thread hier entnehmen kann, experimentiere ich seit Oktober mit Proxmox. FHEM unter Proxmox ist bei mir seit über einem halben Jahr produktiv.
Ich habe Proxmox auf vier verschiedenen Mini PC getestet, hier eine kleine Zusammenfassung meiner Erfahrungen. Die vier Rechner sortiert nach CPU-Leistung und gleichzeitig nach Stromverbrauch:
-Ein Mini PC mit Intel 12700H (14C/20T) (ca. 500 Euro 32GB/1TB) (ca. 18 Watt Grundlast mit 7 VMs), hat entsprechend mehr Power und große Leistungsreserven, ist mein aktueller Produktiv-Rechner, hat zwei 2,5 Gbit Netzwerkanschlüsse, ist eigentlich schon ein Overkill für die 7 VMs
Es laufen folgende VMs: FHEM, Nextcloud, Zigbee2mqtt, OMV, Proxmox-Backup-Server als VM, Windows 11, Home Assistent
Die Auslastung des Proxmox-Servers liegt im Normalbetrieb bei dem schnellsten Rechner (12700H) bei ca. 0,5%, beim langsamsten (N100) bei ca. 2%, die anderen liegen dazwischen.
Ich würde heute darauf achten, dass man den Server auf mindestens 32GB erweitern kann (am besten gleich mit 32GB kaufen), zwei interne Festplatten einbauen kann, und der Server einen 2,5 Gbit Netzwerkanschluss hat. Und wer seine Server-Ressourcen nicht nur für FHEM, Nextcloud & Co. nutzen möchte, kann ja mal testen, wie stabil Proxmox eine VM mit einem Browser und rioace-de (https://rioace-de.com/) im Dauerbetrieb hält – quasi als ,,Performance-Stresstest" für CPU, RAM und vielleicht auch die eigene Geduld.
Die Intel 12er-CPU-Reihe mit Performance- und Effizienz-Kernen läuft bei mir ohne jegliche Zwischenfälle (es gab anfangs Probleme unter Proxmox).
Servus,
ich bin gerade mal wieder in UpgradeLaune. Liegt wohl auch daran, das FHEM@Proxmox langweilig stabil läuft. Da ich den ProxmoxServer auch als temporären Mediaserver nutze, brauche ich mehr jetzt Platz, und mein Ryzen7 ist da ausgereizt.
Da würde sich anbieten, meinen Alltagsrechner (MinisForum NAD9 mit Intel i9-12900H und M2-NVME + 2x SATA) als ProxmoxServer umzubauen.
Jedoch bin ich vom Stromverbrauch meines AMD Ryzen mit 7w Idle sehr verwöhnt.
Du schreibst von Deinem i7-12700H mit einem Idle von 18W. Allerdings hast Du auch eine Win-VM darauf laufen. Wenn ich die bei meinem Ryzen starte, ist auch nichts mehr mit 7w. Hast Du mal den Verbrauch ohne die Win11-VM gemessen ? Dann könnte ich prima vergleichen, und einem MinisForum UM880plus als Desktoprechner (Video+Photobearbeitung) steht nichts mehr im Wege....
7 Watt im Leerlauf sind für Ryzen überraschend gut. Ich habe einen Ryzen 5 5600 und unter 12 Watt sinkt er im VM-Host nicht.
@Max123476
Was läuft denn alles auf Deinem Host ?
Stromsparmechanismen im Bios + Proxmox aktiviert ?
Zitat von: Bartimaus am 05 August 2025, 14:31:48Du schreibst von Deinem i7-12700H mit einem Idle von 18W. Allerdings hast Du auch eine Win-VM darauf laufen. Wenn ich die bei meinem Ryzen starte, ist auch nichts mehr mit 7w. Hast Du mal den Verbrauch ohne die Win11-VM gemessen ? Dann könnte ich prima vergleichen, und einem MinisForum UM880plus als Desktoprechner (Video+Photobearbeitung) steht nichts mehr im Wege....
Ich starte Win-VM nur noch nach Bedarf, weil der Verbraucht dann immer wieder unmotiviert auf über 20 Watt schnellt. Die Win-VM kann sich mit sich selbst beschäftigen (Updates). Mit FHEM, Nextcloud, OMV (NAS), zigbee2mqtt und Proxmox-Backup-Server braucht das System 16 Watt, wenn nichts besonderes läuft. Im Schnitt kommen pro VM 1-2 Watt dazu - für Windows oft das doppelte und mehr. Die stärkeren Systeme mit stärkeren CPUs können bei Last natürlich viel mehr aus der Steckdose ziehen, da sind die schwächeren CPUs etwas genügsamer. Ich habe inzwischen eine Benachrichtigung eingerichtet, wenn der Verbrauch unerwartet in die Höhe schnellt.
Danke Dir, ich glaube ich kaufe mir mal ne kleine NVME-SSD und installiere das mal auf dem Intel und gucke mal ob das nicht doch Overkill wäre, wenn ja, kann ich einfach wieder zurück....
Sodele, habe mal eine vorhandene NVME in den Intel-i9 gehangen, Proxmox installiert und Backups eingespielt. Bin immer wieder geflasht wie einfach das geht.
Im Idle ohne FHEM hat der Intel 16w gezogen. Mit 1xNVME + 2x SATA-SSD.
Starte ich FHEM, sinds mit den USB-Dongles (1wire/Zwave etc.) 20w.
Der bisherige AMD der ohne FHEM dann lief, ging auf 4w runter.
Fazit: 20w sind mir dann doch irgendwie Overkill, zwar Blödsinn, aber wenn das die ganze Zeit im Hinterkopf schwelt... nee.
Ich habe mein Gewissen beruhigt, weil ich zuvor durch den Tausch einer Fritzbox 7590 AX durch 7530 AX den Verbrauch um 10 Watt! senken konnte. Die Gesamtbilanz des Strombedarfs hat sich bei mir also nicht geändert, dafür wird der Energieverbrauch viel sinnvoller genutzt. Die Nutzung der eigenen Cloud hat bei mir inzwischen den gleichen Stellenwert wie die Hausautomatisierung.
Ja, dann passt das natürlich, aber sowas kann ich nicht vorweisen.
Mein "Luxus"Problem ist, das ich meinen ProxmoxServer auch als Mediaserver nutze. Da geht ihm langsam der Platz aus. Mein Intel-i9 bietet Platz für eine NVME sowie 2xSata, mein AMD nur 1x Sata.
Auch wollte ich im Proxmox eine 2,5GBit-Schnittstelle haben.
Mein Kompromiss sieht jetzt so aus, das ich einen weiteren AMD bestellt habe, mit 2,5GBit, zwar nur 1xSata, aber ich werde einfach eine 2. SATA per USB anhängen, ist zwar "unschön", aber funktioniert. Alternativ habe ich gesehen, das die WLAN-Karten im AMD+Intel auch PCIE sind, da könnte ich erstmal eine 2230er-NVME einhängen, aber ich nutze jetzt meine schon vorhandene 4TB-SATA, die kaum genutzt wurde bisher.
Den Strom hierfür egalisiere ich durch deaktivieren der WLAN-Schnittstelle. Glaube mit dieser Lösung kann ich erstmal zufrieden sein.
Den neuen ProxmoxHOST (AMD) bringt gleich der freundliche AmazonMann.
Ich konnte den Verbrauch meines Proxmox i7-Servers weiter senken. Dazu habe ich ihn mit echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor vom Performance-Modus in den Powersave-Modus gestellt (Dauerhaft über crontab einstellbar)
Die Schwuppdizität des System hat sich nicht merklich geändert, der Turbo-Modus wird weiterhin genutzt, die Perlschleife wird immer noch in ca. 1,25 Sekunden durchlaufen.
root@fhem:~# perl -e 'use Time::HiRes qw(time);my $t=time();for(my $i;$i<100000000;$i++){};print(time()-$t)'
1.25408411026001
Der minimale Verbrauch ist aber im Idle von ca. 18 Watt auf 14 Watt gesunken. Eine längere Messung des Stromverbrauchs steht noch aus, eine Ersparnis von 3 bis 4 Watt könnte ich mir dauerhaft vorstellen, da das System meistens Däumchen dreht.
Wenn es also nicht auf die Höchstperformance eines Overkill-Rechners ankommt, ist es eine durchaus interessante Option.
Screenshot 2025-08-16 171813.png
Sehr gut, die Einstellung habe ich auch aktiviert, nachdem ich diese in einer Scriptsammlung (https://community-scripts.github.io/ProxmoxVE/scripts?id=scaling-governor) gefunden hatte.
Ich hatte zwischenzeitlich einen N100 (https://amzn.eu/d/71I04xG) hier, und darauf meine Backups eingespielt und die LXCs gestartet. Aber auch mit optimierten BIOS-Einstellungen kam ich mit diesem System nicht unter 11w Idle. Also System wieder zurückgesetzt und an den Händler zurückgeschickt. Das Ding war mit Win11 mit 138€ echt günstig, aber ich hatte echt keine weitere Verwendung dafür.
Meinen neuen Beelink-SER5pro (https://amzn.eu/d/90D5hUA) mit Ryzen7-5825U-8/16-CPU und jetzt mit 2,5GBit-Schnittstelle habe ich weiter optimiert. Angeschlossen sind alle 4 CULs, sowie 2 SATA-SSDs mit 8TB/4TB-Speicher. Natürlich auch die 1TB-NVME.
Ich habe allerdings die PCMI-WLAN-Karte deaktiviert und ausgebaut da nicht genutzt. Das System geht jetzt auch bis auf 7w Idle runter. Dies entspricht meinem vorherigen System, dafür mit 2 statt 1 SATA-SSDs, aber mit deaktiviertem WLAN. Der gestrige Verbauch lag bei 0,244kWh.
Das geht für mich echt in Ordnung. Frage mich jetzt, ob die ganz neuen AMDs mit 4 statt 7nm-CPUS noch sparsamer sein könnten.
Wie hast du da 2 SATA-Platten angeschlossen?
ZitatDas geht für mich echt in Ordnung. Frage mich jetzt, ob die ganz neuen AMDs mit 4 statt 7nm-CPUS noch sparsamer sein könnten.
Ich gehe nicht davon aus. Du bekommst mehr Power, aber der Grundverbrauch wird nicht unter 7 Watt fallen.
Zitat von: Damian am 16 August 2025, 19:22:54Wie hast du da 2 SATA-Platten angeschlossen?
Eine Platte intern (der SER5 bietet dafür nen Anschluss), die 2. Platte extern mittels USB3->SATA Adapter. Unschön aber der Zweck heiligt die Mittel
Zitat von: Bartimaus am 16 August 2025, 21:23:37Zitat von: Damian am 16 August 2025, 19:22:54Wie hast du da 2 SATA-Platten angeschlossen?
Eine Platte intern (der SER5 bietet dafür nen Anschluss), die 2. Platte extern mittels USB3->SATA Adapter. Unschön aber der Zweck heiligt die Mittel
ok, ich hatte mich schon gewundert ;)
Zitat von: Bartimaus am 16 August 2025, 21:23:37Unschön
Bei SSDs gar nicht so tragisch, die ziehen ja nicht so viel Strom. Und meiner Erfahrung nach sind diese USB -> SATA-Dongles auch ganz zuverlässig. Habe das ein paar Jahre lang problemlos genutzt, um beim Pi die SD-Karte nicht als rootfs nutzen zu müssen.
Zitat von: passibe am 16 August 2025, 22:23:20Habe das ein paar Jahre lang problemlos genutzt, um beim Pi die SD-Karte nicht als rootfs nutzen zu müssen.
Genau aus diesem Grund hatte ich diesen Adapter noch übrig.....
Ich hatte zwischendurch vier HDDs über einen USB-Hub ohne Probleme genutzt. Inzwischen habe ich meine Konfiguration geändert. Meine Backup-Platte ist eine 4 TB SSD als SATA-Platte eingehängt, das Proxmox läuft auf einer 2 TB NVME. Dadurch werden inkrementelle Backups nachts sehr schnell durchgeführt (spart auch Strom) danach wird ein zweiter Backupserver nachts geweckt und ein Synchronisationslauf beider Backup-Server durchgeführt, selbst das dauert nicht lange, da die Quell-Backups auf der SSD liegen und der entfernte Backupserver über 2.5 GB/s angebunden ist.
Ich finde, noch nie war (FHEM)Backup&Restore so einfach wie unter Proxmox.
Ich sichere nachts das u.a. das FHEM(LXC)-Backup auf die externe SATA. Montags laufen komplette LXC-Backups auf meine beiden QNAPS.
Über ein selbst erstelltes Script werden nachts die Konfigfiles des PVE auf die externe SATA gesichert.
Hat jemand schon sein PVE auf 9.nn aktualisiert ?
Zitat von: Bartimaus am 17 August 2025, 11:37:03Hat jemand schon sein PVE auf 9.nn aktualisiert ?
Ne, lieber noch nicht. Auch die Debian VMs laufen noch auf Bookworm.
Viele Grüße Gisbert
Ich mache Proxmox-Updates sehr behutsam. Seitdem mein Proxmox nach einem Update nicht mehr bootete, bin ich sehr vorsichtig. Ich wette, dass viele kein Backup des Proxmox-Betriebssystems selbst haben (nicht Backups der VMs) und dann ist guter Rat teuer - vor allem aber dauert es etwas länger bis das System nach einem Crash wieder lauffähig ist.
Backups vom Host werden m.E. überbewertet. Viel einfacher ist das Neu-Aufsetzen und Integrieren in den Cluster. Fertig.
Wichtig ist, dass das Verzeichnis /etc/pve regelmäßig gesichert wird.
ZitatHat jemand schon sein PVE auf 9.nn aktualisiert ?
Ja, drei Hosts erfolgreich und ohne jegliche Auffälligkeiten hochgezogen.
Zitat von: Damian am 17 August 2025, 19:37:47Ich wette, dass viele kein Backup des Proxmox-Betriebssystems selbst haben (nicht Backups der VMs) und dann ist guter Rat teuer - vor allem aber dauert es etwas länger bis das System nach einem Crash wieder lauffähig ist.
Stimmt, ich hab das nicht, aber immerhin eine Doku über alles, was ich gemacht hab. Chatgpt liefert eine gute Anleitung, die ich aber ohne Unterstützung alleine noch nicht umsetzen kann. Etwas "Fertiges" scheint es ohnehin nicht zu geben.
Viele Grüße Gisbert
Zitat von: Ralli am 17 August 2025, 19:54:44Viel einfacher ist das Neu-Aufsetzen und Integrieren in den Cluster. Fertig.
Genau, deswegen sichere ich "nur" die Konfigfiles des HOSTs und habe ne Doku was ich wie installiert habe.
Mir ist das Upgrade von 7 auf 8 auch um die Ohren geflogen...
Ich denke, die meisten User werden zuhause kein Cluster betreiben :)
Wenn eine saubere Trennung zwischen Proxmox-System-Platte und VM-Platte gegeben ist, ist das halb so schlimm. Allerdings nutzen viele Homelab-User günstige Rechner, die meistens nur eine Nvme unterstützen. Dann muss man seine VMs auf eine langsame SATA-Platte auslagern oder man installiert die VMs auf der Proxmox-Platte, die bei einem Crash erst mal weg sind und mühsam vom Backup zurückgeholt werden müssen, da reicht /etc/pve-Backup auch nichts mehr.
Proxmox sieht leider nicht vor, das Betriebssystem auf einer eigenen Partition zu installieren (BS und VMs sind auf der selben dritten Partition). Ich habe mir die Mühe mal gemacht Proxmox-Partition zu verkleinern und habe eine vierte Partition für VMs definiert.
Nun kann ich mit Clonezilla in einer Minute ein BS-Backup erstellen (sind ja nur 100 GB) und im Falle eines Falls nach Bedarf zurückspielen, ohne dass die VMs alle vom Backup zurückgespielt werden müssen.
ZitatProxmox sieht leider nicht vor, das Betriebssystem auf einer eigenen Partition zu installieren (BS und VMs sind auf der selben dritten Partition). Ich habe mir die Mühe mal gemacht Proxmox-Partition zu verkleinern und habe eine vierte Partition für VMs definiert.
Charmante Idee.
Ich tue mich mit dem LVM irgendwie schwer und finde es sperriger als ne normale Partition mit Filesystem, das sich einfach wieder mounten lässt.
Eine per LVM eingerichtete Platte an einem "Fremdsystem" lesbar einzurichten (für root oder den thin pool) würde mir arge Kopfschmerzen bereiten.
Oder z.B. auf dem vorhanden ROOT-LV Proxmox neu zu installieren.
Gruß Ralf
Kann man so machen.
Ich habe einen Cluster mit drei Nodes laufen und alle Disks aller Container und VMs werden in verschiedenen Abständen automatisch und regelmäßig zwischen allen Nodes repliziert. Darüber hinaus werden natürlich auch regelmäßig Backups auf ein NAS durchgeführt.
Insofern ist es hier bei mir tatsächlich so, dass es mir relativ egal ist, ob/wenn ein Node platzt. Zunächst sollte durch HA alles automatisiert von den anderen Nodes übernommen werden (ist auch so, bereits getestet) und im zweiten Schritt kann ich den defekten Node aus dem Cluster löschen und einen neuen aufsetzen und ohne viel manuelle Anpassungen integrieren. Hab' ich im Endeffekt bereits getestet, als ich von zwei Nodes auf drei Nodes erweitert hatte.
Zitat von: RalfRog am 17 August 2025, 21:11:01ZitatProxmox sieht leider nicht vor, das Betriebssystem auf einer eigenen Partition zu installieren (BS und VMs sind auf der selben dritten Partition). Ich habe mir die Mühe mal gemacht Proxmox-Partition zu verkleinern und habe eine vierte Partition für VMs definiert.
Charmante Idee.
Ich tue mich mit dem LVM irgendwie schwer und finde es sperriger als ne normale Partition mit Filesystem, das sich einfach wieder mounten lässt.
Eine per LVM eingerichtete Platte an einem "Fremdsystem" lesbar einzurichten (für root oder den thin pool) würde mir arge Kopfschmerzen bereiten.
Oder z.B. auf dem vorhanden ROOT-LV Proxmox neu zu installieren.
Gruß Ralf
Die LVM-Platte auf der vierten Partition habe ich einfach über Proxmox-UI ohne Spezialwissen eingerichtet. Es ist sogar eine Thin-LVM mit dem Vorteil, dass sie nur den belegten Platz der VMs verbraucht - wie bei einer Originalinstallation übrigens auch.
Die Installation eines neuen Proxmox über ISO-Stick funktioniert damit natürlich nicht, da wie schon gesagt, Proxmox bei einer Neuinstallation die ganze Platte für sich beansprucht und damit alle Partitionen einer Platte vernichtet. Es ging mir in erster Linie darum im Crash-Fall mein aktuelles System ohne großen Aufwand in wenigen Minuten wieder ans Laufen zu bekommen.
In meinem aktuellen System läuft Proxmox auf einer internen 1TB-NVME-SSD. Dabei ist der Thin-Pool unter local-lvm für meine Zwecke mit 850GB oder so unnötig gross. Damit ich diesen auch anderweitig für Daten nutzen konnte, habe ich die darauf liegenden Daten erstmal temporär verschoben, dann diesen Thin-Pool (resize/reduce hat hier nicht funktioniert) gelöscht, und mit kleinerer Grösse neu angelegt. Den freigewordenen Platz habe ich dann als neues logisches Laufwerk in Proxmox angelegt, formatiert und gemountet. Danach dann die ursprünglichen Daten auf den Thin-Pool zurückverschoben.
Bis auf das Anlegen der separaten Partition, die vollständig ein Thin-LVM darstellt, konnte ich über die Definition der VMs und in den jeweiligen VMs selbst innerhalb der Thin-LVM-Platte bleiben. Irgendwelche systemnahen manuellen mount-Vorgänge über die Shell waren dazu nicht erforderlich. Das war mir auch wichtig, sonst wird das gesamte System nicht wartbar. Im schlimmsten Fall möchte ich ein Backup einer VM zurückspielen, ohne irgendwelche Kunststücke händisch vorzunehmen.
So sieht bei mir die Aufteilung der NVMe-Platte aus:
root@pve:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 1.8T 0 disk
├─nvme0n1p1 259:1 0 1007K 0 part
├─nvme0n1p2 259:2 0 1G 0 part /boot/efi
├─nvme0n1p3 259:3 0 99G 0 part
│ ├─pve-swap 252:0 0 8G 0 lvm [SWAP]
│ └─pve-root 252:1 0 91G 0 lvm /
└─nvme0n1p4 259:4 0 1.7T 0 part
├─local--vm-local--vm_tmeta 252:2 0 15.9G 0 lvm
│ └─local--vm-local--vm-tpool 252:4 0 1.7T 0 lvm
│ ├─local--vm-local--vm 252:5 0 1.7T 1 lvm
│ ├─local--vm-vm--100--disk--0 252:6 0 4M 0 lvm
│ ├─local--vm-vm--100--disk--1 252:7 0 200G 0 lvm
│ ├─local--vm-vm--100--disk--2 252:8 0 4M 0 lvm
│ ├─local--vm-vm--102--disk--0 252:9 0 10G 0 lvm
│ ├─local--vm-vm--102--disk--1 252:10 0 1000G 0 lvm
│ ├─local--vm-vm--105--disk--0 252:11 0 32G 0 lvm
│ ├─local--vm-vm--106--disk--0 252:12 0 4M 0 lvm
│ ├─local--vm-vm--106--disk--1 252:13 0 32G 0 lvm
│ ├─local--vm-vm--110--disk--0 252:14 0 32G 0 lvm
│ ├─local--vm-vm--110--disk--1 252:15 0 2T 0 lvm
│ ├─local--vm-vm--114--disk--0 252:16 0 32G 0 lvm
│ ├─local--vm-vm--113--disk--0 252:17 0 32G 0 lvm
│ ├─local--vm-vm--120--disk--0 252:18 0 32G 0 lvm
│ ├─local--vm-vm--101--disk--0 252:19 0 32G 0 lvm
│ └─local--vm-vm--107--disk--1 252:20 0 30G 0 lvm
└─local--vm-local--vm_tdata 252:3 0 1.7T 0 lvm
└─local--vm-local--vm-tpool 252:4 0 1.7T 0 lvm
├─local--vm-local--vm 252:5 0 1.7T 1 lvm
├─local--vm-vm--100--disk--0 252:6 0 4M 0 lvm
├─local--vm-vm--100--disk--1 252:7 0 200G 0 lvm
├─local--vm-vm--100--disk--2 252:8 0 4M 0 lvm
├─local--vm-vm--102--disk--0 252:9 0 10G 0 lvm
├─local--vm-vm--102--disk--1 252:10 0 1000G 0 lvm
├─local--vm-vm--105--disk--0 252:11 0 32G 0 lvm
├─local--vm-vm--106--disk--0 252:12 0 4M 0 lvm
├─local--vm-vm--106--disk--1 252:13 0 32G 0 lvm
├─local--vm-vm--110--disk--0 252:14 0 32G 0 lvm
├─local--vm-vm--110--disk--1 252:15 0 2T 0 lvm
├─local--vm-vm--114--disk--0 252:16 0 32G 0 lvm
├─local--vm-vm--113--disk--0 252:17 0 32G 0 lvm
├─local--vm-vm--120--disk--0 252:18 0 32G 0 lvm
├─local--vm-vm--101--disk--0 252:19 0 32G 0 lvm
└─local--vm-vm--107--disk--1 252:20 0 30G 0 lvm
Hier noch mal eine Übersicht von Thin LVM, da offenbar viele alte Unix-Hasen da noch Berührungsängste haben (ich hatte auch mal vor über 30 Jahren beruflich Software unter Unix entwickelt und da gab es viele moderne Dinge noch nicht ;))
ZitatThin LVM (Thin Provisioning mit LVM) bietet einige Vorteile gegenüber klassischem LVM. Hier die wichtigsten Punkte:
✅ Vorteile von Thin LVM
- Effiziente Speichernutzung (Over-Provisioning)
- Virtuelle Volumes (LVs) können größer angelegt werden, als physisch Speicher vorhanden ist.
- Speicher wird erst dann wirklich verbraucht, wenn Daten geschrieben werden.
- Snapshots (schnell & platzsparend)
- Snapshots in Thin LVM sind wesentlich effizienter als klassische LVM-Snapshots, da sie Copy-on-Write auf Blockebene nutzen.
- Sie sind schneller anzulegen, brauchen anfänglich kaum Speicherplatz und wachsen nur mit Änderungen.
- Flexible Volumengrößen
- Volumes können bei Bedarf einfach nachträglich vergrößert werden.
- Nutzer/VMs können ,,virtuell" große Disks haben, ohne sofort physischen Speicher zu belegen.
- Geringere Fragmentierung / bessere Performance
- Im Vergleich zu alten LVM-Snapshots bleibt die Performance länger stabil, auch bei vielen Snapshots.
- Kombination mit anderen LVM-Features
- Thin Pools können mit RAID, Verschlüsselung oder LVM-Caching kombiniert werden.
- Einfachere Verwaltung in Virtualisierungs- und Container-Umgebungen
- Besonders nützlich in Cloud-, VM- und Docker-Umgebungen, wo Speicherplatz flexibel und effizient verwaltet werden m
uss.
⚠️ Nachteile / Einschränkungen (der Vollständigkeit halber):
- Komplexer als klassisches LVM, benötigt mehr Monitoring.
- Risiko: Bei Over-Provisioning kann der Speicher ,,überbucht" werden – wenn der Pool voll ist, schlagen Schreibvorgänge fehl.
- Verwaltung benötigt aktuelle Tools und Kernel-Support.
👉 Kurz gesagt: Thin LVM lohnt sich, wenn du flexible, platzsparende Volumes und viele Snapshots brauchst, besonders in Virtualisierung/Cloud-Setups.
Zitat von: Damian am 17 August 2025, 20:20:09Allerdings nutzen viele Homelab-User günstige Rechner, die meistens nur eine Nvme unterstützen. Dann muss man seine VMs auf eine langsame SATA-Platte auslagern oder man installiert die VMs auf der Proxmox-Platte, die bei einem Crash erst mal weg sind
Dazu: Spräche eigentlich – bis auf die SATA-bedingten Geschwindigkeitseinbußen – irgendetwas dagegen bei so einer Hardware die NVMe-Platte und die SATA-Platte gleich groß zu wählen und in ein RAIDz1 zu packen?
Benutze aktuell kein Proxmox aber spiele mit dem Gedanken ein System, das aktuell noch auf einem Pi läuft, auf so eine N100 oder N150 Box mit Proxmox und RAIDz1 umzuziehen.
(Natürlich ist das RAIDz1 kein Backup, aber so würde mich wenigstens davor schützen, dass wegen einem Festplattenausfall gar nichts mehr geht.)
Ich würde mir eher Gedanken um ein gescheites Backup machen.
Eine SD-Karte im Raspi ist deutlich schneller abgeraucht als ne gute NVWM-SSD im Proxmox
Zitat von: Bartimaus am 18 August 2025, 18:56:09Ich würde mir eher Gedanken um ein gescheites Backup machen.
Eine SD-Karte im Raspi ist deutlich schneller abgeraucht als ne gute NVWM-SSD im Proxmox
Würde ich auch so sehen. Wir reden hier von einem Homelab und nicht einem Hochverfügbarkeit-Server. Die Wahrscheinlichkeit sich sein System durch ein Update, eine Fehlkonfiguration oder allgemein durch einen Bedienfehler zu zerschießen, dürfte wesentlich höher liegen, als dass dir eine Marken-NVMe abraucht.
Es könnte durchaus Sinn machen, Proxmox auf einer kleinen SATA zu installieren und eine große NVMe nur für VMs und eine größere USB-HDD oder USB-SSD für Backups zu nehmen
Dann hast du folgende Vorteile:
Wenn sich das Proxmox durch ein Update oder sonst etwas verabschiedet, dann installierst du es einfach neu und spielst deine gesicherten /etc/pve-Konfigurationsdateien ein und schon läuft die Sache.
Wenn die VMs auf einer schnellen NVMe statt auf einer SATA liegen, dann laufen inkrementelle Backups wesentlich schneller durch, weil Proxmox ein mal durch die VM-Disks muss. Die Menge der täglich zu sichernden Differenzdaten ist dagegen gering, so dass eine relativ langsame USB-Platte nicht so schlimm ist.
Da ich bereits eine große 4TB SATA-SSD und eine 2TB NVMe hatte, war diese Konstellation bei mir nicht sinnvoll, daher der Kunstgriff mit den getrennten Partitionen auf der NVMe.
Bei mir läuft z. B. ein nächtliches Backup einer Nextcloud mit 2 TB-VM-Disk auf der NVMe, bei der ca. 600 GB Nutzdaten vorhanden sind, in ca. 16 Minuten durch - mach das mal mit einer SATA Platte (ich habe da bereits meine Erfahrungen gemacht).
2025-08-18 02:00:34 INFO: Starting backup: ct/110/2025-08-18T00:00:31Z
2025-08-18 02:00:34 INFO: Client name: pve
2025-08-18 02:00:34 INFO: Starting backup protocol: Mon Aug 18 02:00:34 2025
2025-08-18 02:00:34 INFO: Downloading previous manifest (Sun Aug 17 02:00:30 2025)
2025-08-18 02:00:34 INFO: Upload config file '/var/tmp/vzdumptmp2010125_110/etc/vzdump/pct.conf' to 'root@pam@192.168.178.84:8007:EVO_4TB' as pct.conf.blob
2025-08-18 02:00:34 INFO: Upload directory '/mnt/vzsnap0' to 'root@pam@192.168.178.84:8007:EVO_4TB' as root.pxar.didx
2025-08-18 02:01:34 INFO: processed 44.862 GiB in 1m, uploaded 6.282 MiB
2025-08-18 02:02:34 INFO: processed 85.301 GiB in 2m, uploaded 6.282 MiB
2025-08-18 02:03:34 INFO: processed 132.865 GiB in 3m, uploaded 6.282 MiB
2025-08-18 02:04:34 INFO: processed 177.44 GiB in 4m, uploaded 6.282 MiB
2025-08-18 02:05:34 INFO: processed 221.746 GiB in 5m, uploaded 6.282 MiB
2025-08-18 02:06:34 INFO: processed 258.676 GiB in 6m, uploaded 6.282 MiB
2025-08-18 02:07:34 INFO: processed 305.959 GiB in 7m, uploaded 6.282 MiB
2025-08-18 02:08:34 INFO: processed 351.354 GiB in 8m, uploaded 6.282 MiB
2025-08-18 02:09:34 INFO: processed 395.946 GiB in 9m, uploaded 6.282 MiB
2025-08-18 02:10:34 INFO: processed 436.241 GiB in 10m, uploaded 53.586 MiB
2025-08-18 02:11:34 INFO: processed 481.747 GiB in 11m, uploaded 72.223 MiB
2025-08-18 02:12:34 INFO: processed 520.627 GiB in 12m, uploaded 99.835 MiB
2025-08-18 02:13:34 INFO: processed 548.742 GiB in 13m, uploaded 184.621 MiB
2025-08-18 02:14:34 INFO: processed 577.249 GiB in 14m, uploaded 251.4 MiB
2025-08-18 02:15:34 INFO: processed 597.698 GiB in 15m, uploaded 1.498 GiB
2025-08-18 02:15:35 INFO: root.pxar: had to backup 1.503 GiB of 597.923 GiB (compressed 522.523 MiB) in 900.99 s (average 1.709 MiB/s)
2025-08-18 02:15:35 INFO: root.pxar: backup was done incrementally, reused 596.42 GiB (99.7%)
2025-08-18 02:15:35 INFO: Uploaded backup catalog (17.919 MiB)
2025-08-18 02:16:22 INFO: Duration: 947.98s
2025-08-18 02:16:22 INFO: End Time: Mon Aug 18 02:16:22 2025
2025-08-18 02:16:22 INFO: adding notes to backup
2025-08-18 02:16:22 INFO: prune older backups with retention: keep-last=30, keep-monthly=13, keep-yearly=10
2025-08-18 02:16:22 INFO: running 'proxmox-backup-client prune' for 'ct/110'
2025-08-18 02:16:23 INFO: pruned 232 backup(s) not covered by keep-retention policy
2025-08-18 02:16:29 INFO: restarting vm
2025-08-18 02:16:30 INFO: guest is online again after 959 seconds
2025-08-18 02:16:30 INFO: Finished Backup of VM 110 (00:15:59)
Aktuell existiert natürlich ein gescheites Backup bzw. das gäbe es dann auch für Proxmox (würde per NFS aufs NAS gebackupt werden und dann weiter off-site).
Das Problem ist eher, dass das System a) remote ist und b) dort semi-wichtige Dinge laufen. Deshalb wäre es nervig, wenn die Festplatte abraucht und man nicht einigermaßen schnell da ist, um ein Backup einzuspielen.
Wie wahrscheinlich das ist, dass irgendeine Platte abraucht, steht natürlich auf einem völlig anderen Blatt. Und natürlich ist der PC selbst oder dessen Netzteil oder whatever auch ein SPOF.
Mein Gedanke war eher: Wenn das Ding schon Platz für zwei Festplatten bietet und SATA-SSDs billig sind, wieso dann nicht eine gleich große SATA-SSD rein schmeißen und zusammen mit der NVMe als RAIDz1 nutzen.
Das mit der Geschwindigkeit der inkrementellen Backups ist natürlich ein valider Punkt, danke! Solche Hinweise hatte ich mir von der Frage erhofft. Bin mir nur noch nicht ganz sicher, wie relevant das für meinen Anwendungsfall wird, denn da wird es nicht wirklich um große Datenmengen gehen (schätze unter 100GB, wenn überhaupt). Vielleicht probiere ich es auch einfach mal aus und berichte dann bei Interesse. Wird aber sicherlich noch ein paar Monate dauern.
Zitat von: passibe am 18 August 2025, 20:27:35Wird aber sicherlich noch ein paar Monate dauern.
In einigen Monaten holst du dir 'nen Rechner mit 2 NVMes :)
Hallo Damian
Zitat von: Damian am 17 August 2025, 20:20:09Proxmox sieht leider nicht vor, das Betriebssystem auf einer eigenen Partition zu installieren (BS und VMs sind auf der selben dritten Partition). Ich habe mir die Mühe mal gemacht Proxmox-Partition zu verkleinern und habe eine vierte Partition für VMs definiert.
Könnte das nicht gleich bei der Installation erreicht werden, indem die Parameter hdsize, swapsize, maxroot, maxvz so gesetzt werden, dass kein Thin-Pool für Data entsteht und man ihn im Nachgang manuell anlegt?
https://pve.proxmox.com/pve-docs/chapter-pve-installation.html#advanced_lvm_options
Es stellt sich allerdings die Frage was es bedeutet dass (maxvz=0): "If set to 0, no data volume will be created and
the storage configuration will be adapted accordingly".
Wo laso dann VMs landen...
Gruß Ralf
Gruß ralf
Zitat von: RalfRog am 26 August 2025, 18:18:14Hallo Damian
Zitat von: Damian am 17 August 2025, 20:20:09Proxmox sieht leider nicht vor, das Betriebssystem auf einer eigenen Partition zu installieren (BS und VMs sind auf der selben dritten Partition). Ich habe mir die Mühe mal gemacht Proxmox-Partition zu verkleinern und habe eine vierte Partition für VMs definiert.
Könnte das nicht gleich bei der Installation erreicht werden, indem die Parameter hdsize, swapsize, maxroot, maxvz so gesetzt werden, dass kein Thin-Pool für Data entsteht und man ihn im Nachgang manuell anlegt?
https://pve.proxmox.com/pve-docs/chapter-pve-installation.html#advanced_lvm_options
Es stellt sich allerdings die Frage was es bedeutet dass (maxvz=0): "If set to 0, no data volume will be created and the storage configuration will be adapted accordingly".
Wo laso dann VMs landen...
Gruß Ralf
Gruß ralf
Ich meine es probiert zu haben - ohne Erfolg. Viel schlimmer ist aber die Tatsache, dass durch eine Installation die vierte Partition nicht erhalten bleibt. Somit bleibt nur ein selbstgemachtes Backup der ersten drei Partitionen, die man dann zurückspielen kann. Irgendwie hat der Proxomox-Hersteller nicht an die Homelab-Community mit begrenzten Plattenslots gedacht :(
Dann mach doch mal einen Bug/Issue bzw. einen FeatureRequest auf.
https://bugzilla.proxmox.com/
Ich denke, es ist ein vorübergehendes Problem, denn die neuen Minis haben schon zwei NVMe-Plätze (je 4 TB) und da kann man ruhig das OS von den VMs trennen, was durchaus sinnvoll ist. Dann nimmt man eine kleine NVMe für das OS und eine große (4 TB) für die VMs.
Mein Mini hat zusätzlich eine SATA-Schnittstelle. Obwohl angeblich nur eine 2TB-SATA funktionieren würde, läuft aktuell eine 8TB ohne Probleme. Von daher glaube ich auch das über NVME mehr als nur 4TB je Slot gehen würde
Zitat von: Bartimaus am 26 August 2025, 21:40:45Mein Mini hat zusätzlich eine SATA-Schnittstelle. Obwohl angeblich nur eine 2TB-SATA funktionieren würde, läuft aktuell eine 8TB ohne Probleme. Von daher glaube ich auch das über NVME mehr als nur 4TB je Slot gehen würde
Vermutlich, bei mir läuft eine 4TB SATA und eine 2TB NVMe, ich könnte mir vorstellen, dass bei der NVMe auch mehr geht, obwohl der Hersteller max. 2 TB vorsieht.
Also hast Du jetzt einen 3,8GB ThinPool auf der NVME ?
Zitat von: Bartimaus am 26 August 2025, 22:13:38Also hast Du jetzt einen 3,8GB ThinPool auf der NVME ?
Nein 1,9TB (100 GB ist Proxmox-OS) - ich habe ja nur 2TB bei der NVME. Die 4TB-SATA wird z. Zt. komplett für Backups genutzt
Ok, und zu wieviel % nutzt Du den ThinPool ?
Zitat von: Bartimaus am 26 August 2025, 22:30:26Ok, und zu wieviel % nutzt Du den ThinPool ?
z. Zt. ca. 60 % also ca. 1TB, obwohl Nextcloud eine 2TB-VM-Disk hat und OMV eine 1TB-VM-Disk, geht natürlich nur mit Thin-LVM.
Ok. Bei mir war es nur zu 10% genutzt, also habe ich den Pool mit Bordmitteln verkleinert und den Speicher anderweitig zur Verfügung gestellt.
Zitat von: Bartimaus am 26 August 2025, 22:45:52Ok. Bei mir war es nur zu 10% genutzt, also habe ich den Pool mit Bordmitteln verkleinert und den Speicher anderweitig zur Verfügung gestellt.
Für was denn?
Als zentraler Speicher für meine LXCs.
Habe also ein logisches Laufwerk definiert und per BindMountpoint vom HOST an die LXCs durchgereicht
Zitat von: Bartimaus am 26 August 2025, 22:52:59Als zentraler Speicher für meine LXCs.
Habe also ein logisches Laufwerk definiert und per BindMountpoint vom HOST an die LXCs durchgereicht
Und wie machst du das Backup von diesem Speicher?
Wenn ich wollte, könnte ich die Daten z.B. per Rsync auf mein NAS sichern. Da es aber nur temporäre Daten sind, ist das für mich nicht wichtig
Zitat von: Bartimaus am 27 August 2025, 05:44:52Wenn ich wollte, könnte ich die Daten z.B. per Rsync auf mein NAS sichern. Da es aber nur temporäre Daten sind, ist das für mich nicht wichtig
ja, ich bevorzuge dagegen die Variante, alles über die Proxomox-Mechanismen abzudecken, insb. die Nutzung von VM-Disks, um ebenfalls über Proxmox sauber inkrementelle Backups der VMs mit ihren definierten VM-Disks zu machen und im Zweifelsfalle ein Restore (von VM und Daten) ohne zusätzliche manuelle Eingriffe vorzunehmen.
Sollte der Datenhunger weiter anwachsen, dann werde ich die 2TB NVME gegen eine 4TB NVME (die herbstlichen "Black-Tage" kommen noch) tauschen, dann logischerweise mit 3,9TB Thin-LVM. Die 100 GB OS mit den ersten drei Partitionen sind in wenigen Minuten draufgespielt, der Rest kommt dann vom Proxmox-Backup.
Ich habe am WE auf meinem Testserver mal eine offizielle Migration von PVE8to9 (https://pve.proxmox.com/wiki/Upgrade_from_8_to_9) versucht. Obwohl das Prüftool keine Fehler angezeigt hat, ist das Update auf PVE9 fehlgeschlagen. Der Rechner bootetet nicht mehr.
Dann mal komplett PVE9-Host neu installiert, Backups eingespielt, LXCs erfolgreich von Bookworm auf Trixie migriert, keine Probleme. Noch sehe ich allerdings keinen Bedarf mein ProduktivSystem auf PVE9 zu migrieren.
Zitat von: Damian am 27 August 2025, 09:56:40Sollte der Datenhunger weiter anwachsen, dann werde ich die 2TB NVME gegen eine 4TB NVME (die herbstlichen "Black-Tage" kommen noch) tauschen
Das habe ich auch auf dem Schirm, aber dank meiner 4TB-SATA-SSD ist der Focus jetzt etwas in den Hintergrund gerückt.
Nutz Du das WLAN an Deinem MiniPC ? Wenn nein, mal dran gedacht die WLAN-Karte auszubauen ? Spart auch noch etwas Strom
Zitat von: Bartimaus am 27 August 2025, 12:08:37Nutz Du das WLAN an Deinem MiniPC ? Wenn nein, mal dran gedacht die WLAN-Karte auszubauen ? Spart auch noch etwas Strom
Nein, ich habe sie als Erstes ausgebaut.
Für Proxmox VE 9 sehe bei mir z. Zt. keinen Bedarf. Interessant könnten evtl. "Snapshots auf LVM" sein. Da ich Snapshots auf ZFS speichere, ist es für mich zunächst uninteressant. Wenn sich aber PVE 9 in einem halben Jahr etabliert hat, dann wird sich der Umstieg sicherlich anbieten. Vielleicht installiere ich es direkt beim Festplattenwechsel.
In dem freigewordenen PCI-Slot müsste man doch eine 2230erNVME betreiben können, oder ? Gibts ja auch in 2TB
Zitat von: Bartimaus am 27 August 2025, 14:08:54In dem freigewordenen PCI-Slot müsste man doch eine 2230erNVME betreiben können, oder ? Gibts ja auch in 2TB
Es ist zwar ein PCI-Slot passt aber mechanisch nicht und wäre mit einer Lane auch zu langsam.