Speichererweiterung für Mini-PC mit Proxmox

[wahli]

Du hast keinen NUC. Ein NUC ist nur von Intel und heißt Next Unit of Computing.
Du hast einen Mini-PC.

 

[Salamimander]

Bei 16 oder gar 8GB ist ZFS (Stripe oder Mirror) definitiv keine gute Idee. Da kannst du begrenzen wie du magst, die Performance ist dann kacke.

 

[Banned]

Das ist m.E. einfach Quatsch. Wenn du keine Deduplication und Verschlüsselung verwendest, sind vor allem 16GB völlig ausreichend, wenn du nicht gerade deutlich über 50TB Gesamtkapazität hast.
Hast du den Link von mir überhaupt gelesen? Glaubst du, es einfach besser zu wissen als die Leute dort?
Selbst die vielfach verwendete Faustregel von mind. 8GB und dann 1GB RAM pro TB Gesamtkapazität über 8TB deckt sich nicht mit dem, was du schreibst.

Btw. betreibe ich ein RAIDZ2 mit sechs HDDs. Ich habe absolut keine Performance-Probleme. Keine Ahnung, was du dir da zusammenreimst...
Wir reden hier schließlich von Heimnutzung, wo ein, vielleicht zwei oder drei Nutzer zugreifen.

Oder mal anders: Zeig mir eine seriöse Quelle, wo generell angeben wird, dass alles unter 32GB nicht performant liefe. Ich kann dir Dutzende geben, wo das Gegenteil steht (wie gesagt, unter der Prämisse: keine Deduplication oder Verschlüsselung; VMs/Jails etc. ist noch mal ne andere Geschichte).

 

[Salamimander]

1.) Nimm mal eine Valium
2.) Bezog ich mich bei den RAM Angaben auf sein Komplettsystem. Wenn er nur 8GB RAM verbauen würde, wäre ZFS eine Katastrophe. Bei 16GB wird’s grad so gehen. (Von den 16 GB bleiben mit ZFS effektiv vielleicht 10GB über mit brauchbarer Performance. Mehr ARC = Mehr IOPS)
3.) Proxmox auf ZFS ist hier das Zauberwort. ARC wird immer genutzt. Da brauchst du nicht mal dedup. Mein Setup steht eine Seite eher. IO Performance ist stellenweise eher bescheiden. Deshalb laufen einige VMs bereits SSD only. Ich habe mich VIEL mit ZFS beschäftigt. Raidz2 + Proxmox ist einfach ein Mega Performance impact. Full-Flash wird’s besser aber das Problem bleibt.
https://www.reddit.com/r/Proxmox/comments/147azct/zfs_comparison_raid10_vs_raidz_vs_raidz2/

Also bevor du hier basierend auf DEINEM Setup irgendwelche „ich merke nichts“ Kommentare schreibst, einfach mal etwas einlesen. Auch ich habe ein home setup. Anzahl der User sind hier nicht das Problem, aber die permante load durch die DB(s), Backups von und nach Proxmox usw. Klar wenn du deine 25GB blobs kopierst, wirst du dann wenig bemerken. Dafür brauchst du aber auch keine IOPS…

Die meisten, offenbar du auch, kennen nicht den Unterschied zwischen Sequenziell und Random. Sequenziell wird, zumindest bis 2,5GBit und SSDs als Quelle/Ziel, eher das Netzwerk limitieren. Aber mache dir mal den Spaß und kopiere lauter winzige files von A nach B (TimeMachine Backups, LXC Snapshots)

 

[sandreas]

Ich finde beim RAM muss man auch beachten, dass 16GB für das Gesamtsystem allein schon deshalb knapp werden, weil man ja mehrere Applikationen / VMs UND noch ZFS als Host-Dateisystem verwendet.

Was mich an den NUCs / MiniPCs nervt ist die eingeschränkte Menge an Schnittstellen. Ich experimentiere gerade mit einer Intel Quad NIC (i350-T4) rum, um meinen OpenWRT Router komplett zu virtualisieren. Da braucht man mindestens eine freie PCIe. Und 1 bis 2 RAM-Slots ohne ECC sind für einen Proxmox Server auch nicht optimal. Daher habe ich mich für ein Fujitsu D3417-B12 Board entschieden. Das krieg ich inkl. NVMe und 64GB ECC RAM auf 9.3 Watt Idle. Mit laufenden VMs ohne größere Last sind es 11-12W. Halte ich für vertretbar. Die Spar-Version gibts dann auch mit der Fujitsu Celsius W550 Workstation. Hat zwar ein Proprietäres 16Pin Netzteil, aber kostet gebraucht zwischen 70 und 140 Euro. Die W570 oder W580 sind noch interessanter, kosten aber auch deutlich mehr.

Ich habe es bei mir so eingerichtet, dass ich nur einen LXC für meine Docker-Container laufen lasse. LXCs für die Einzeldienste verwende ich praktisch gar nicht - stattdessen diesen einen Docker-LXC, darin dann alle Dienste. Z.B. Portainer als Verwaltungstool, Watchtower um die Container zu aktualisieren, NginX Proxy Manager als Platform. Es gibt sogar einen Samba-Server container für docker, der einfach per yml konfiguriert werden kann.

Die Container / Stacks laufen dann über einen LXC gemappten Benutzer mit der ID 1000, damit die Schreibrechte auf den Volumes passen. So habe ich dann am Ende neben den VMs nur ein Verzeichnis "docker-data", was ich sichern muss + die Configs aus /etc. Ne Neuinstallation von Proxmox geht dann recht simpel.

Sehr gute Erfahrungen habe ich auch mit zfs send via SSH gemacht, somit man das gesamte Dateisystem über SSH an einen anderen Rechner oder auf eine externe Festplatte schicken kann. Das geht sogar inkrementell... hatte ich hier mal grob aufgeschrieben.

 

[Banned]

@Salamimander

Du hattest zuvor einfach sehr pauschale Aussagen getätigt wie z.B. "ZFS in ein RAM Killer". Und dann eben:

Bei 16 oder gar 8GB ist ZFS (Stripe oder Mirror) definitiv keine gute Idee. Da kannst du begrenzen wie du magst, die Performance ist dann kacke

Ist auch pauschal.

Ich hatte stets darauf hingewiesen, dass das unter bestimmten Bedingungen anders aussehen kann.

2.) Bezog ich mich bei den RAM Angaben auf sein Komplettsystem.

Gut, dann habe ich dich da missverstanden. Wobei es auch in diesem Fall trotzdem schwer ist, eine Empfehlung zu geben, ohne dass der TE überhaupt angibt, wie viel Speicherplatz er insgesamt einplant. Denn es ist eben schon relevant für ZFS, wie viel Speicher es insgesamt sein soll, und hier kann man sich dann schon an offiziellen Vorgaben orientieren.
Wie viel RAM seine VMs benötigen, sollte der TE am besten mal einfach ausprobieren. Das kann man aus der Ferne schwer beurteilen @Monokel .

Da es hier ja wahrscheinlich eh darauf hinauslaufen wird, dass ein NAS an den MiniPC angeschlossen wird, da USB-Lösungen eben nicht optimal sind, kann man doch einfach schauen, ob die 16GB reichen oder nicht. Wo ist jetzt das Problem?
Mehr RAM kaufen, als man nachher braucht (und ZFS macht eben so oder so nahezu alles voll - das ist kein Indikator), ist eben auch irgendwie schwachsinnig - und besonders, wenn es über die offiziell zulässige Menge kommt, kann das u.U. auch problematisch sein.

Ob der RAM reicht oder nicht, kann man an der Größe der SWAP-Datei (also was auf Datenträger ausgelagert werden muss) sehen. Die Anzeige der Gesamt-Belegung ist bei ZFS wie gesagt kaum aussagekräftig.

 

[Salamimander]

Ob du genug ARC hast, sagt dir einzig und allein arc_summary. Alles andere ist raten.

 

[Banned]

Alles andere ist raten.

Nicht wirklich. Wenn man sieht, dass etwas auf die Datenträger ausgelagert wurde, hat das nichts mit Raten zu tun. Das passiert, wenn im RAM gar nichts mehr freigegeben werden konnte, also sich nur noch Dinge im RAM befinden, die auch tatsächlich benötigt werden. Denn im RAM befinden sich häufig logischerweise auch Dinge, die nicht zwangsweise notwendig für einen stabilen, performanten Betrieb sind. Wenn ich unter Windows drei Filme gucke, sind die auch erst mal im RAM; braucht das System mehr RAM, wird der Speicher wieder freigeben. Erst wenn ich nur Dinge im RAM habe, die essentiell für den aktuellen Betrieb sind, und der RAM ist voll, wird zwangsläufig ausgelagert und man kann definitiv davon sprechen, dass der RAM nicht reicht.

Aber ja, arc_summary gibt schon eine gute Übersicht. Wenn dort der Status throttled ist, dann zeigt das, dass nicht genug RAM vorhanden ist. Aber dann wird trotzdem auch schon ausgelagert worden sein; denn das hängt schließlich zusammen.

 

[Bohnenhans]

Ich habe einen meiner Server auch eine Zeit lang mit 8 Gbyte betrieben das ging problemlos zfs inkl crypt und 10 Gbit ZFS Volume ca 100 Tbyte nutzbar als Raidz2. Ca 140 dann Brutto

Ich bin auch der Meinung von Banned das sich ZFS so verhält. Bei 5 10 oder 50 gleichzeitigen Nutzern da macht RAM viel aus bei weniger Nutzern ist alles ab 8 ok - OHNE DeDup

Ich konnte keinen Unterschied feststellen zwischen dem 8 und 32 gbyte RAM System - beide sonst 100% identisch - das 10 GBit Netzwerk hat beide gleich limitiert

Für Docker VMs "Apps"etc da ist RAM sicher sinnvoll

Wenn RAM günstig ist stopf ich trotzdem rein - denn haben ist besser als brauchen :-)

 

[Salamimander]

Workload halt. Blobs sind kein Thema. Aber ich kann mich ja unendlich wiederholen. Wenn ich Proxmox und basteln höre, dann höre ich auch DBs und IOPS. Habe hier eine average load von 5 bei 2 menschlichen Usern. (5700x als CPU). Arc stats sagen hier: 18GB MFU und 30GB MRU. Das wird bei einfachen „Samba Share“ alles keine Rolle spielen nur danach klingt es einfach nicht im
anforderungsprofil.

 

[Bohnenhans]

Prinzipiell untertsützt die CPU wohl 32 Gbyte

https://www.speicher.de/arbeitsspei...gb-bni3-n305-rev-10-ram-so-dimm-sp476982.html

Bei mehr RAM als offiziell nehme ich immer Ram Module mit viel Chips = möglichst wenig MBit pro Chip

 

[oicfar]

Die CPU kann DDR4 und DDR5. Der Mini-PC hat nur ein RAM Slot. Oder?

Ergänzung (31. Januar 2024)

Wenn man es für die SSD (Systemlaufwerk) deaktiviert (was ich auch habe), dann wird es im Notfall trotzdem auf die/einen sonstigen Datenträger ausgelagert. Auch wenn du Swappiness auf 0 setzt, wird im Notfall trotzdem ein Swap auf einem Datenträger erzeugt.
Ein System, was dies in keinem Fall tun würde - das wäre dann wirklich der absolute Supergau.

Wenn ich kein SWAP erstelle, dann spielt der Swappiness Wert keine Role. Ohne SWAP wird nix geswappt. Linux legt da kein SWAP an.

Ergänzung (31. Januar 2024)

Ich konnte keinen Unterschied feststellen zwischen dem 8 und 32 gbyte RAM System - beide sonst 100% identisch - das 10 GBit Netzwerk hat beide gleich limitiert

Es gibt ein gewaltiges Unterschied zwischen 8 und 32GB -> buff/cache.

$ free -m
               total        used        free      shared  buff/cache   available
Mem:           31704        5055         571         713       26077       25738
Swap:           6143        1686        4457

Mein NUC (24/7) läuft mit 32GB RAM flüssiger. Nach 2-3 Wochen wird auch geswappt. Was nicht schlimm ist.

 

[Banned]

Es gibt ein gewaltiges Unterschied zwischen 8 und 32GB -> buff/cache.

Es wird halt vieles bei dir in den RAM gelegt, was bei Bedarf schnell wieder freigegeben werden kann, das sagt doch buff/cache aus. Das sind aber keine Inhalte, die für die aktuell laufenden Prozesse relevant sind. Diese sind unter used verzeichnet.
Hättest du noch mehr RAM verbaut würde der Wert bei buff/cache mit der Zeit natürlich noch weiter ansteigen, bis der RAM ebenfalls irgendwann nahezu voll ist.

Ich verstehe deshalb nicht ganz, was du damit aussagen willst, außer dass eine bestimmte Datei - welche aber nicht für die laufenden Prozesse verwendet wird - schneller geladen/bearbeitet werden kann als über I/O des jeweiligen Datenträgers.
Vielleicht verstehe ich dich auch nicht. Könntest du das evtl. noch mal etwas ausformulieren?

Wenn ich kein SWAP erstelle, dann spielt der Swappiness Wert keine Role. Ohne SWAP wird nix geswappt. Linux legt da kein SWAP an.

Danke für die Info.
Bei TrueNAS wird standardmäßig, wenn der RAM knapp wird, ein SWAP über die Datenträger verteilt (alternativ kann man einen auf dem Systemlaufwerk erstellen). Aber ich nutze auch Core, was auf FreeBSD basiert, evtl. ist es dort generell anders oder es liegt an TrueNAS - weiß ich nicht.

 

[Bohnenhans]

Meine Server lesen mit > 1500 Mbyte / Sec und Schreiben mit > 1400 - mein Netzwerk dagegen hat halt nur 10 GBit

Bei 25 GBit hätte der Cache sicher wieder Einfluss

Bei 2.5 GBit reichen 300 Mbyte / Sec

Und meistens ist bei Servern der Netzwerktraffic doch das worauf es ankommt - weil man die Geschwindigkeit merkt

Ich würde 16 nehmen wenn ich mir ein Budget "sinvoll" gemacht hätte und 32 wenn ich sage Geld ist eigentlich egal bei den Summen

 

[oicfar]

Es wird halt vieles bei dir in den RAM gelegt, was bei Bedarf schnell wieder freigegeben werden kann, das sagt doch buff/cache aus. Das sind aber keine Inhalte, die für die aktuell laufenden Prozesse relevant sind. Diese sind unter used verzeichnet.

Ich weiß. Aber dadurch, dass der buff/cache so groß ist, läuft mein System insgesamt flüssiger.

Ich verstehe deshalb nicht ganz, was du damit aussagen willst. Vielleicht verstehe ich dich auch nicht. Könntest du das evtl. noch mal etwas ausformulieren?

Ich will damit sagen, dass man schon in einem Linux Server prinzipiell mehr RAM verbauen sollte.

 

[Banned]

Ich weiß. Aber dadurch, dass der buff/cache so groß ist, läuft mein System insgesamt flüssiger.

Wenn man danach geht, kann man quasi unendlich viel RAM verbauen.
Bei RAM heißt es oft, man könne nie genug haben, und RAM-Disk im PC ist sicher auch was Feines. In welcher Relation Kosten und Nutzen stehen, ist dann immer die Frage.

Bei großen Serversystemen ist viel RAM sicherlich sehr sinnvoll, weil so Dateien, die von einem Nutzer angefragt wurden, bei Anfrage weiterer Nutzer nicht erneut in den RAM geladen werden müssen.
Für das private Umfeld ist das mMn sehr zu relativieren - hier sind die Workloads idR schließlich auch ganz andere.

In arc_summary kann man sehen, wie viel RAM für regelmäßig genutze Daten und wieviel für solche reserviert ist, die nur kürzlich genutzt werden. Wenn jetzt der Anteil an frequently used hoch ist, dann macht mehr RAM absolut Sinn. Ist ein großer Teil aber nur recently used, ist mehr RAM eher Luxus als wirklich nötig aus meiner Sicht.

 

[andy_m4]

Nur mal so als kleine Ergänzungen.

Aber ich nutze auch Core, was auf FreeBSD basiert

FreeBSD tendiert generell nicht (mehr) zum swappen bzw. macht das eher wirklich nur dann, wenn es notwendig ist. Es gibt auch, anders als bei Linux, kein swappiness sysctl, womit man die Swap-Freudigkeit pauschal beeinflussen kann.
Wenn man Swap-Space anlegt, sollte man den nicht zu groß machen, da damit auch der Verwaltungsoverhead fürs System steigt. Generell ist es nicht verkehrt, Swap eher als Notausgang zu sehen, falls dem System mal zwischen durch temporär der RAM ausgeht.

Aufpassen sollte man, wenn man sein Swapspace auf ZFS legt. ZFS benötigt für jede Operation RAM. Wenn das System also ne RAM-Anforderung kriegt und die nicht befriedigen kann und daraufhin Memory-Pages auf ZFS auslagern möchte und ZFS fordert dafür RAM an, dann ist das ne potentielle deadlock-Situation.
Idealerweise hat man ne native freebsd-swap Partition dafür. Wenn man es doch auf einen zpool legen will, sollte man ein eigenes zvol dafür anlegen.
Die openzfs-Doku gibts auch Hinweise dazu:
https://openzfs.github.io/openzfs-docs/Project and Community/FAQ.html#using-a-zvol-for-a-swap-device-on-linux

Keine Ahnung, wie TrueNAS dazu verfährt, sollte man aber vielleicht im Auge behalten.

 

[Bohnenhans]

ZFS macht ja so weit ich weiss auch einen intelligenten PreAhead Cache also liest nicht nur Dateien im voraus ein - sondern auch innerhlab Dateien nach einem bisher genutztedn Muster (was dann auch DB Caching optimiert)

Aber der Vorteil ist halt vor allem im Heavy User Szenario wichtig - alles unter 10 gleichzeitig aktiven Usern sehe ich hier eher als "Kindergarten/Grundschule" für ZFS

Ich würde mein RAM als Minimum auslegen nach 6-8 Gbyte "sicher" für ZFS und dann das wass die Apps brauchen die laufen wie VMs, DBs, sonstiger Krimskrams

Bei Proxmox und Virtualisierung würde ich dann schon eher wenn es geht auf 32 Gbyte gehen, meisten nutzen Leute die viel mit VMs machen da auch evtl 2 oder 3 parallel.

 

[oicfar]

Wenn man danach geht, kann man quasi unendlich viel RAM verbauen.

Natürlich gibt's Grenzen. Aber meine Beobachtung sagt mir, dass oft zu wenig im den Servern verbaut wird.