• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Bitte um kleine Beratung zu RAM

holgerw

Well-Known Member
Themenstarter #1
Hallo,

wie ich gerade getestet habe, funktioniert inxi auch sehr schön unter FreeBSD.

Weniger schön ist allerdings die Ausgabe zum RAM auf meinem Desktop-PC:
Code:
inxi -m
Memory:    RAM: total: 11.89 GiB used: 10.79 GiB (90.7%)
           Array-1: capacity: 32 GiB slots: 4 EC: None
           Device-1: ChannelA-DIMM0 size: No Module Installed
           Device-2: ChannelA-DIMM1 size: 4 GiB speed: 1600 MT/s
           Device-3: ChannelB-DIMM0 size: 4 GiB speed: 1333 MT/s
           Device-4: ChannelB-DIMM1 size: 4 GiB speed: 1600 MT/s
Ähm, da habe ich mit dem Spendieren eines zusätzlichen 4 GB DDR3-1333er RAM-Riegel wohl ein wenig daneben gegriffen.

Meine Fragen:
Bremst der 1333er RAM den restlichen Ram aus?

Mein Board kann mit bis zu 32 GB Ram bestückt werden. Ich würde dann doch gerne die zwei DDR3-1600er Riegel behalten und noch zwei 8 GB-Riegel dazu stecken, dann hätte ich immerhin 24 GB Ram statt meiner jetzigen 12 GB.
Kann ich zu den zwei Modulen mit 4GB einfach zwei Module mit 8GB dazu packen? Sind die Angaben zur Datenrate (DDR3-1600 PC3-12800) hinreichend. Es steht da noch was von Latenzzeit: CL11, muss ich da mit den schon vorhandenen Riegeln irgendwas gegenprüfen?

Danke im Voraus und viele Grüße
Holger
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#2
Es kommt drauf an. Auf Intel-Systemen ab etwa 2009 kann man Speicher im Großen und Ganzen so kombinieren, wie man lustig ist. Solange man den RAM nicht übertakten will, wird es in den allermeisten Fällen einfach funktionieren. Bei AMD ist es wesentlich komplizierter, dort müssen mindestens die Ranks und Taktraten auf einem Kanal gleich sein. Also nur Single Rank Module oder Dual Rank Module miteinander kombinieren, aber nicht durcheinander. Und den Takt auf die Taktrate des schwächsten Moduls einstellen.

Generell verlierst du bei asymetrischer Belegung (also unterschiedliche Modulgrößen, Taktraten und Latenzen) aber den Dual-Channel Betrieb, zumindest für Teile des RAMs. Das bedeutet, dass sich die mögliche Bandbreite halbiert, was schon merklich auf die CPU-Leistung schlagen kann. Wenn du eine in die CPU integrierte GPU hast, wird auch die 3D-Leistung sehr leiden. Genauso Latenzen, innerhalb eines Kanals werden die Latenzen des langsamsten Moduls für den ganzen Kanal übernommen. Die Auswirkungen längerer Latenzen sind nicht ganz so klar. Es gibt Anwendungen, den macht es gar nichts aus. Aber auch Anwendungen, die sehr leiden.

Ich sag mal so: Letztendlich ist das eine finanzielle Frage. Wenn es läuft und dir die 12GB reichen, lass es laufen. Wenn du aufrüsten willst, hast du die Wahl. Die beiden 1600MHz behalten und auf einen Kanal stecken, dazu zwei 8GB Module auf dem anderen Kanal. Würde knapp 50€ kosten. Oder gleich vier 8GB Module für dann 100€. Dafür hast du dann gleich 32GB insgesamt und vollen Dual-Channel Betrieb, was du je nach Anwendungen merkst oder nicht merkst.
 

holgerw

Well-Known Member
Themenstarter #3
Hallo Yamagi,

danke für Deine detailreiche Antwort.

Es ist ein MSI-Intel Board, zur CPU wird mir folgendes gezeigt:
Code:
inxi -C
CPU:       Topology: Quad Core model: Intel Core i5-4690 bits: 64 type: MCP L2 cache: N/A
           Speed: 3500 MHz min/max: 800/3501 MHz Core speeds (MHz): No speed data found for 4 cores
Dann werde ich wohl zwei 8 GB 1600er Module zu den zwei 4 GB 1600er Modulen packen und den 1333er Riegel entfernen.
 

Vril

Well-Known Member
#6
Ich würde aber jetzt ( bei typischen Anwendungen im privaten Umfeld ) zwischen 12GB asymmetrisch und 24GB Dual Channel unter FreeBSD keine
irren Performance Zuwächse erwarten.
 

holgerw

Well-Known Member
Themenstarter #7
Ich würde aber jetzt ( bei typischen Anwendungen im privaten Umfeld ) zwischen 12GB asymmetrisch und 24GB Dual Channel unter FreeBSD keine
irren Performance Zuwächse erwarten.
Hallo Walter,

nun ja, aber der RAM läuft doch schon rasch voll. ZFS als Dateisystem, Bauen von Repos mit poudriere, parallel mit Audacity mehrstündige Konzerte bearbeiten (das sind manchmal über 2GB große Wav-Dateien), und dann noch ein paar andere Anwendungen offen haben, und ein htop zeigt, dass die 12 GB Ram doch immer weiter zulaufen.

Und da sind doch 24 GB 1600er Ram deutlich besser als 12 GB 1333er und 1600er gemischt.
 

Esjott

Kellerkind
#8
Naja, ram ist dafür da, genutzt zu werden. Swappt das system denn in einer tour? Wenn nicht, würde ich mir erstmal keine Gedanken um mehr ram machen..
 

holgerw

Well-Known Member
Themenstarter #9
Naja, ram ist dafür da, genutzt zu werden. Swappt das system denn in einer tour? Wenn nicht, würde ich mir erstmal keine Gedanken um mehr ram machen..
Hallo Esjott,

der Swap läuft während poudriere zu Gange ist, manchmal schon über 2 GB zu.

Generell verlierst du bei asymetrischer Belegung (also unterschiedliche Modulgrößen, Taktraten und Latenzen) aber den Dual-Channel Betrieb, zumindest für Teile des RAMs. Das bedeutet, dass sich die mögliche Bandbreite halbiert, was schon merklich auf die CPU-Leistung schlagen kann.
Vielleicht verkürzen sich die Bauzeiten mit poudriere doch deutlich, wenn ich nur 1600er RAM verbaue.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#11
Vielleicht verkürzen sich die Bauzeiten mit poudriere doch deutlich, wenn ich nur 1600er RAM verbaue.
Erwarte da keine Wunder. Takt bringt in erster Linie Bandbreite, Dual Channel verdoppelt die Bandbreite. Takt hat aber nur wenig, Dual Channel sogar keine Auswirkungen auf Latenzen. Compiler übertragen aber kaum Daten, sie brauchen ihre Daten vor allem schnell. Sie sind also eher latenz- als bandbreitenlimitiert.
 

serie300

Well-Known Member
#12
Hallo Yamagi

welche Latenzen meinst du? Die vom Massenspeicherpfad? Dann würde ja eine Ramdisk was bringen, in die vorab alle benötigten Dateien geschrieben werden.

Serie300
 

pit234a

Well-Known Member
#16
der Swap läuft während poudriere zu Gange ist, manchmal schon über 2 GB zu.
FreeBSD belegt einfach allen Speicher. Wenn dein System lange genug Up ist, ist irgendwann der RAM voll und das System geht in den SWAP. Wir hatten die Diskussion gelegentlich schon und ich akzeptiere die Antworten von besser wissenden Leuten durchaus, aber meine persönliche Erfahrung sagt mir eben auch, dass ich bei ausreichend RAM keinen SWAP brauche und damit sogar besser fahre.
Derzeit nutze ich SWAP mal wieder und gerate da auch nach einigen Tagen Uptime hinein, ohne dass es wirklich einen Sinn macht. Also rein praktisch betrachtet. Wenn ich 30G mittels rsync irgendwo hin sichere, ist es ja vielleicht wirklich sinnvoll, diese auch im RAM zu puffern, damit der nächste rsync dann vielleicht viel schneller geht. Keine Ahnung. Wenn ich aber VirtualBox und einige Maschinen starte, wird dieser RAM sofort wieder frei geräumt. Man kann also nicht sagen, dass Speicher verschwendet wird. Wenn er vorhanden ist, wird er halt genutzt. Nur eben leider auch der SWAP, wenn er denn vorhanden ist.
Versuch doch mal ein swapoff, falls dich das interessiert.
 

medV2

Well-Known Member
#17
Dein System swappt ja im besten Fall nur Sachen, die du wärend den paar Tagen Uptime nicht gebraucht hast - und so wahrscheinlich auch nicht brauchen wirst. Es hat keinen Zweck das im RAM zu halten.
Wir hatten mal einen p-Server, der hatte auch nach ein paar Wochen mehrere GB im Swap. Da das Ding mehr als genug RAM hatte, haben wir uns das genau angesehen und überwacht. Auch über Monate Uptime hinweg hat der nie was aus dem Swap zurück geholt, nur manchmal was verworfen und dann wieder bisschen was rein. Wir haben das dankend so angenommen und der DB mehr RAM zugeteilt :D
Dein Swap bremst dich also nur, wenn du dann, wenn du ein langsames System wahrnimmst, ein swapin läuft. Das kannst du überprüfen.

Dazu kommt für Benutzer von ZFS, zumindest früher konnte es vorkommen, dass das System so schnell RAM anfordert, dass der ARC nicht nachkommt mit dem freimachen. Ohne Swap läuft man dann in eine OOM Situation. Ob das bei aktuellem FreeBSD 11.x /12.x noch so ist weiß ich nicht.
 

mr44er

Well-Known Member
#18
Ohne Swap läuft man dann in eine OOM Situation. Ob das bei aktuellem FreeBSD 11.x /12.x noch so ist weiß ich nicht
Ich bin noch nie ohne swap gefahren (die paar GB tun nicht weh), aber geknallt hatte es nach drei Tagen, als ich einen zfs-pool kopierte (trotz 32GB Ram). Seitdem limitiere ich den ARC.
Müsste ein 11.2-RELEASE gewesen sein. Freiwillige vor für die 12er. :p

@holgerw
Wenn deine Brieftasche es hergibt, bestücke alle Bänke mit den jeweils größten und schnellsten Riegeln, die das Board akzeptiert. Dann hast du alles abgedeckt, aber dein System hat am meisten von der Größe. Ich bevorzuge lieber mehr Hubraum als Geschwindigkeit. ;)
 

holgerw

Well-Known Member
Themenstarter #19
Hallo,

erstmal danke für die weiteren Ratschläge und Informationen.

Vielleicht hätte ich zu Beginn des Threads noch von dem unschönen Nebeneffekt auf meinem PC beim Bau eines Repos mit poudriere erwähnen sollen, dass manchmal ein parallel gestrateter Firefox oder ein Libreoffice so um die 30 Sekunden brauchen, bis sie gestartet sind und dann ist eine Bedienung zäh wie Kaugummi.

Auch wenn der PC schon einige Jahre alt ist: Ich möchte, dass neben dem Repo-Bau für meine anderen Arbeiten der Rechner kontinuierlich ordentlich benutzbar bleibt. Und das sollte bei der Intel Core i5-4690 CPU, einer flotten SSD und vernünftiger RAM-Bestückung doch drin sein.
 

foxit

Moderator
Mitarbeiter
#20
Auch wenn der PC schon einige Jahre alt ist: Ich möchte, dass neben dem Repo-Bau für meine anderen Arbeiten der Rechner kontinuierlich ordentlich benutzbar bleibt.
Code:
man poudriere
Code:
155 # By default poudriere uses hw.ncpu to determine the number of builders.
156 # You can override this default by changing PARALLEL_JOBS here, or
157 # by specifying the -J flag to bulk/testport.
158 #
159 # Example to define PARALLEL_JOBS to one single job
160 # PARALLEL_JOBS=1
161
162 # How many jobs should be used for preparing the build? These tend to
163 # be more IO bound and may be worth tweaking. Default: PARALLEL_JOBS * 1.25
164 # PREPARE_PARALLEL_JOBS=1
Das sollte ja jetzt wirklich kein Problem sein. Schon mal versucht mit der Einstellung "PARALLEL_JOBS=3"?

edit: Und jetzt sind wir wieder völlig ab vom Thema!
 

Vril

Well-Known Member
#21
Una
...
Derzeit nutze ich SWAP mal wieder und gerate da auch nach einigen Tagen Uptime hinein, ohne dass es wirklich einen Sinn macht. Also rein praktisch betrachtet. Wenn ich 30G mittels rsync irgendwo hin sichere, ist es ja vielleicht wirklich sinnvoll, diese auch im RAM zu puffern, damit der nächste rsync dann vielleicht viel schneller geht. Keine Ahnung. Wenn ich aber VirtualBox und einige Maschinen starte, wird dieser RAM sofort wieder frei geräumt. Man kann also nicht sagen, dass Speicher verschwendet wird. Wenn er vorhanden ist, wird er halt genutzt. Nur eben leider auch der SWAP, wenn er denn vorhanden ist.
Versuch doch mal ein swapoff, falls dich das interessiert.
Hmm .. mag alles sein -
Aber hier geht es ja um einen Rechner auf dem poudriere endlos compiliert und linkt,
dann ist swapoff IMHO keine gute Idee.
ganz unabhängig davon wie gut oder schlecht das System für poudriere konfiguriert ist.
Ob und wie ccache, tempfs etc. eingerichtet sind, wissen wir nicht.
Wenn das Teil für eine Instanz von ff 30s braucht, wenn poudriere läuft-wird der Ram-Ausbau
von 12 GB auf 32GB vielleicht zur Folge haben, dass firefox dann 20s statt 30s braucht.

Grundsätzlich gilt natürlich, dass man nie genug RAM haben kann - aber hier würde ich zusätzlich noch
mal schauen, worauf z.B. @foxit hinweisst - aber auch generell nachhschauen, wie und was poudriere
so tut und was es eingentlich nutzt.
 

holgerw

Well-Known Member
Themenstarter #22
Hallo,

danke für die Hinweise aber ich kenne die Möglichkeiten der parallelen Vorverarbeitung und Verarbeitung, die in der poudriere.conf festgelegt werden und ja, wir weichen vom eigentlichen Thema ab.:)
Gelernt habe ich, dass es günstiger ist, die gleichen Ram-Riegel zu haben und es Situationen geben kann, wo das größere Auswirkungen gibt und solche, wo es kaum Auswirkungen gibt.
Und da mich zwei 8 GB RAM Speicher nun auch nicht um einen dreistelligen Euro-Betrag erleichtern werden, werde ich sie besorgen.
Zur poudriere-Optimierung mache ich dann bei Bedarf einen neuen Thread auf.
 

holgerw

Well-Known Member
Themenstarter #24
Hallo Holger,

inxi interessiert mich auch. Aber woher hast Du es? In den Ports ist es nicht.

Grüße

Ralph
Hallo Ralph,

schau mal hier:
https://github.com/smxi/inxi

Einfach per wget herunterladen, als Root ausführbar machen und nach /usr/local/bin kopieren.

Wenn es nicht startet und ein fehlendes Perl anmäkelt, einfach noch perl5-5.28.2 nachinstallieren.