QNAP HS-453D einen SO-DIMM mit 8Gbyte RAM, laut QNAP ist dies auch der max. Speicherausbau
Und laut Intel ebenfalls das Maximum, das vom Prozessor unterstützt würde.
habe die NAS-HS453 DX erfolgreich aus 16Gbyte RAM aufgerüstet.
Und warum kann ich dann weder im 1.Thread diesen Forums noch in diesem Thread lesen, welchen Speicher Du verbaut hast? Wenn Du von erfolgreich schreibst, hast Du auch die tatsächliche Speicherverwendung beobachtet, einschließlich der Feststellung, dass nicht nur vorübergehend mehr als 8 GB auch tatsächlich belegt und verwendet wurden, mit Nebenwirkungen oder ohne?
Da Intel nicht für den Celeron eine eigene Architektur erstellt, sondern die bestehenden in einer abgeschwächten Version einsetzt, ist das Speicherlimit eher was aus Richtung Marketing. Hier wurden schon J3445er mit 32GB Ram betrieben und werden das vermutlich heute noch.
Und der ist voll adressierbar und auch ansprechbar gewesen.
Meine 16GB laufen mit dem jedenfalls seit fast 1,5 Jahren ohen Probleme.
Was aber hilfreich ist, den RAM und das Modell in den entsprechenden Thread ein zu tragen.
Da Intel nicht für den Celeron eine eigene Architektur erstellt, sondern die bestehenden in einer abgeschwächten Version einsetzt, ist das Speicherlimit eher was aus Richtung Marketing.
Es ist schon länger her, dass ich mich mit Prozessorarchitekturen intensiver beschäftigt habe. Demnach brauchen Begrenzungen nicht immer aus der Architektur stammen, sondern können andere Ursachen haben, die z.B. im Mapping von Architektur zu Produktfamilie abgebildet werden. Das Verzeichnis ark.intel.com benennt i.d.R. nicht die Quellen für benannte Begrenzungen, leider. Ich würde mir hier mehr Transparenz wünschen.
Wenn man einen entsprechenden Prozessor in Betrieb hat, kann man z.B. auch mit entsprechenden Werkzeugen Features auslesen, wie viele Adressbits physikalisch und virtuell adressierbar sind. Für physikalische Speicherlimits ist die Angabe physikalischer Adressbits interessant. Diese Angabe finde ich i.d.R. nicht unter ark.intel.com, die es mir erlauben würde, diese Information vor Kauf und Inbetriebnahme zu berücksichtigen. Soweit ich verstanden habe, ist aber in den meisten Universalprozessoren dennoch nie der gesamte physikalisch addressierbare Adressraum verfügbar, da Treiber Teile ihrer Adressbereiche ebenfalls in diesen physikalischen Addressbereich abbilden müssen. Für diese Zwecke kann bestimmte Peripherie (z.B. integrierte oder dezidierte GPUs, NICs) entsprechende Reservierungen im Adressraum für solche Abbildungen einrichten. Von daher ist i.d.R. nie zu erwarten, dass der gesamte physikalisch addressierbare Addressraum auch ausschließlich als Hauptspeicher zur Verfügung steht.
Weitere Quellen für Einschränkungen des physikalischen Adressraumes liegen im Chipsatz und haben damit keinen direkten sondern lediglich indirekten Bezug zum Prozessor.
Es ist bekannt, dass Intel die Datenbasis für ark.intel.com meist nicht aktualisiert für bestehende Prozessoren, die bereits auf dem Markt sind. Wenn also größere Speicher oder dichtere Speicherlayouts erst nach Einführung eines Prozessors verfügbar werden, aktualisiert Intel weder Messungen nach Grunddaten für dieses Verzeichnis ark.intel.com, sondern berücksichtigt diese erst bei künftigen Prozessoren. Das verstehe ich unter Marketingpolitik als Ursache für solche Grenzen, wenn diese nicht physikalisch im Prozessor begründet liegen.
der ist voll adressierbar und auch ansprechbar gewesen.
Willst Du damit sagen, dass dieses Reservierungen von Adressraum durch Peripherie und Treiber immer außerhalb des physikalischen Speichers in den Adressraum eingeblendet werden bei den Celeron Prozessoren aller Prozessorgenerationen (bzw. wenigstens der jüngeren Prozessorgenerationen)?
Hier wurden schon J3445er mit 32GB Ram betrieben und werden das vermutlich heute noch.
Ja, ich habe solch einen Prozessor in einem QNAP NAS mit 32 GB RAM im Betrieb. Ich kann aber weder bestätigen noch dementieren, dass die vollen 32 GB auch als RAM angesprochen werden. Die vollen 32 GB werden ordnungsgemäß erkannt und angezeigt. Tatsächlich beobachtet habe ich, dass annähernd 16 GB RAM genutzt werden, ohne erkennbare Nebenwirkungen. Entsprechende Beobachtungen für eine Nutzung von mehr als 16 GB und bis zu 32 GB RAM konnte ich bei meinen Stichproben noch nicht beobachten. Dieses NAS stürzt gelegentlich ab und nennt meist andere Ursachen.
Was ich bislang nicht gemacht habe, ist dieses NAS neu aufzusetzen mit diesem großen Speicherausbau. Wenn wieder einmal Zeit zum Experimentieren bleibt, ist dies ein sinnvoller Versuch, weil ich erwarte, dass QTS sich dann etwas anders konfiguriert. QTS scheint u.a. eine Überwachung eingebaut zu haben, in welchem Umfang virtueller Speicher genutzt wird, und sicherheitshalber ein unsauberen Reboot durchführt, wenn ein beachtlicher Teil des virtuellen Speichers über längere Zeit genutzt wird. Was dabei unter beachtlicher Teil zu verstehen ist, habe ich genauso wenig heraus gefunden wie das Verständnis von längere Zeit, noch ob diese beiden Faktoren unabhängig oder nur in Kombination bewertet werden. Wenn solch eine Warnung zum virtuellen Speicher kommt, und dies tatsächlich zu einem unsauberen Reboot führt, dann war die Nutzung des virtuellen Speichers mindestens eine Minute ununterbrochen. Leider sind mir tiefere Details zu dieser Überwachung, Anpassbarkeit, Politik und Konfiguration bislang nicht bekannt. Gerne würde ich dessen Schwellwerte anpassen, ebenso wie das Verhalten bei Überschreiten. Und wenn schon ein Reboot durchgeführt wird, leuchtet es mir nicht ein, warum dieser unsauber durchgeführt wird. Es klingt nach einem alten Design dieser Überwachung, als noch keine Drosselung der CPU verfügbar war, und wegen kritischer Temperaturen eine schnelle Reaktion für das Gesamtsystem die einzige Option war. Lieber wäre mir eine temporäre Drosselung der CPU bei gleichzeitiger Reduktion der Systemressourcen, z.B. der Threads für Samba oder Apache.
Was aber hilfreich ist, den RAM und das Modell in den entsprechenden Thread ein zu tragen.
Dem kann ich nur beipflichten. Dies war mein Anliegen mit meinem vorherigen Beitrag. Der 1.Thread enthält weder dieses NAS-Modell noch diesen J4105-Prozessor, soweit ich sehen konnte, Stand gestern Nachmittag. Von daher sind Details zu Erfahrungen jenseits der Herstellerangaben willkommen und hilfreich, ebenso wie Anmerkungen, ob diese Angaben lediglich erste Erfahrungen darstellen, oder auch schon tiefere Tests erfolgten. Ob Nebenwirkungen gelegentlich oder gar nicht oder regelmäßig auftreten, gehört dann in das Feld Anmerkungen, um die Aussagekraft anzudeuten.
Soweit ich verstanden habe, ist aber in den meisten Universalprozessoren dennoch nie der gesamte physikalisch addressierbare Adressraum verfügbar, da Treiber Teile ihrer Adressbereiche ebenfalls in diesen physikalischen Addressbereich abbilden müssen.
Als ich das NAS kaufte, hatte ich da mal im Detail gesucht, war nicht so einfach aber irgendwann bin ich drüber gestolpert.
Meine ein 40Bit sind rein für die RAM Adressierung bei der Architektur vorgesehen und das in Hardware.
Das sind dann 1TB Ram, macht ja auch Sinn, denn wenn ich eine Architektur erfinde, dann baue ich die so, dass ich einige Zeit mit aus kommen und diese nur noch im Detail verbessern muss und nicht nach 5 Jahren schon wieder alles neu machen muss, weil der Ram nicht mehr Adressierbar ist.
Wobei wir für Server ja langsam an dem Limit kratzen, jendenfalls pro Blech.
Ja, ich habe solch einen Prozessor in einem QNAP NAS mit 32 GB RAM im Betrieb. Ich kann aber weder bestätigen noch dementieren, dass die vollen 32 GB auch als RAM angesprochen werden.
Bei meinem werden die 16GB voll verwendet und wenn nur als Cache oder Buffer:
Dieses NAS stürzt gelegentlich ab und nennt meist andere Ursachen.
In dem Fall würde ich den RAM am PC mal 4h mit Prime95 testen, wenn er sich da nicht verrechnet ist CPU und RAM ok.
Denn ein kippenden Bit im RAM kann solche Auswirkungen aufgrund von Fehlerfortpflanzung haben.
Da wir bei einem NAS mit RAID aber auf Datensicherheit aus sind, ist diese an der Stelle gefährdet. Im Grund bräuchten wir Reg ECC Ram, aber für @home gehts auch so.
QTS scheint u.a. eine Überwachung eingebaut zu haben, in welchem Umfang virtueller Speicher genutzt wird, und sicherheitshalber ein unsauberen Reboot durchführt, wenn ein beachtlicher Teil des virtuellen Speichers über längere Zeit genutzt wird.
Ich habe hier bisher nur die Warnung bekommen, die aber wieder ausgeblendet.
Wenn mann über QBoost den RAM aufräumen lässt, wird der SWAP reduziert.
Bei mir war HBS3 bisher für eine entsprechende Warnung verantwortlich, bei einem Job mit 300k Dateien aufwärts wird die Mappingtabelle wohl recht groß. An dem Tag als die Warnung auf meinem Be kam, hatte ich aber gerade den first Job fürs Backup NAS mit allem fertig und dann wurde die bisherige BU Strategie auf 3 HDs vollständig umgeschmissen.
Da musste die Kiste ein paar mal alle Dateien Mappen.
Das war wohl ein wenig viel.
Hast du HBS3 bei dir im Einsatz und kannst das ggf. mit deinen Problemen in Verbindung bringen?
Kurzer stoppen der App und dann wieder starten sollte auch helfen.
Wobei wir für Server ja langsam an dem Limit kratzen, jendenfalls pro Blech.
Was heißt hier pro Blech?
Wenn ich mir Server Prozessoren von Intel (Xeon Silver und höher) anschaue, unterstützen diese schon seit Jahren 1,5 TB pro CPU. Seit letztem Jahr gibt es auch Xeons, die auf knapp 2 TB oder mehr als 3 TB RAM kommen sollen.
Hast du HBS3 bei dir im Einsatz und kannst das ggf. mit deinen Problemen in Verbindung bringen?
Nein, bislang noch nicht.
Kurzer stoppen der App und dann wieder starten sollte auch helfen.
I.d.R ist bei mir die Ursache, wenn zu viele Dienste gleichzeitig laufen. Habe schon viele deaktiviert, damit ich Zusatzdienste nur nach Bedarf starte. Leider sind nicht alle Dienste als App in die GUI eingebunden, so dass dieses Option über die GUI nur eingeschränkt zur Verfügung steht. Und auf der Kommandozeile habe ich mir noch nicht die Mühe gemacht, auszuprobieren, bestimmte Dienste zu deaktivieren und andere bestimmte Dienste in ihrem Ressourcenverbrauch einzuschränken, so dass solche Konfigurationen auch Reboots überdauern. Bin aber nicht immer auf dem NAS angemeldet, wenn so etwas passiert. Bislang muss es zweimal passiert sein, ohne dass ich am NAS angemeldet war. Alle anderen Male war ich am Gerät und konnte daher meist die Situation mal schneller mal langsamer wieder unter Kontrolle bringen.
Da ich aber schon seit mehr als 2 Jahrzehnten mit Linux arbeite, hätte ich gerne diese Überwachung umkonfiguriert. Habe bislang noch nichts näheres dazu gefunden, lediglich Namenskonventionen zu einer Gruppe von Überwachungen im internationalen Forum. Meiner Beobachtung nach wäre ein Reboot i.d.R. nicht notwendig. Und selbst wenn ein Reboot notwendig werden sollte, braucht er nicht unsauber zu sein, sondern sollte die Zeit reichen für einen sauberen Reboot.
Bin Netzwerker, mit Blechen habe ich weniger zu tun, da ist mein Wissen über die neuen Xeons wohl ein wenig angestaubt.
