Manjaro XFCE Speicherfresser?

cbtestarossa schrieb:
Und wie schon gesagt, selbst die Updates die downgeloaden werden und auf Platte landen sollten schreiben sich in den Cache.
Eine Frage, ich möchte hinter deinen Gedankengang kommen. Du weißt, dass die Daten grundsätzlich einmal im Ram abgelegt werden müßen?
 
  • Gefällt mir
Reaktionen: Deinorius, fixedwater und Tanzmusikus
Jep, das ist auch eine sehr gute Methode:
  • Daten werden durch den Update-Befehl angefordert
  • Daten werden aus dem I-Net in den Arbeitsspeicher geladen bzw. auf dem Datenträger im Cache-Bereich (z.B. swap) abgelegt, wenn zu groß für den RAM
  • Daten werden aus dem RAM installiert (weil das der schnellste Weg ist, besonders bei HDD/USB-Stick)
  • Daten werden durch die Installation auf dem Datenträger persistent abgelegt & ersetzen alte Versionen
  • Nach Installation werden die Daten aus dem Cache (swap, RAM) ggf. aktiv gelöscht
  • Wenn nicht, geschieht dies durch die Routinen des Systemkernels beim Herunterfahren des Systems
Dies mal grob als Orientierung, wie man sich das vorstellen könnte.

600MB RAM und weniger schaffen meine Linux-System hier alle nicht, da ich relativ viele Startprozesse am Laufen habe. Weder am PC mit Pop!_OS (Gnome) oder EndeavourOS (Xfce) als auch auf dem Notebook.
 
  • Gefällt mir
Reaktionen: Linuxfreakgraz und fixedwater
LochinSocke schrieb:
Eine Frage, ich möchte hinter deinen Gedankengang kommen. Du weißt, dass die Daten grundsätzlich einmal im Ram abgelegt werden müßen?
Müssen sie nicht. Wenn man eine Datei downloaded schreibt sich die Datei auf Platte und fertig.

@Tanzmusikus
Ja jetzt ist das so, noch vor kurzem hatte man 600 MB Verbrauch und der Rest war frei.
 
Du hast in Beitrag #17 doch selber gezeigt, dass dein System weiterhin nur 600MiB benutzt :) Den Rest bitte einfach ignorieren. Mein Gentoo hat nach dem Start auch ca. 800MiB im Cache. Diese Daten wurden einfach zum Starten des Systems von den Datenträgern geladen und befinden sich somit im RAM.

Heutzutage fällt das mit SSDs und NVMEs gar nicht mehr so auf, aber erinnere dich mal an alte Rechner zurück mit herkömmlichen HDDs. Beim ersten Start eines Programms war die Festplatte am rödeln und es dauerte ewig, der zweite Start hingegen war sehr schnell und ohne Lärm. Genau das ist dieser Puffer/Cache und nichts anderes. Da war jeder froh, dass es sowas gibt. Für dich ist das gerade ein riesen Problem :) Am besten ist der Cache so groß wie der RAM, dann geht alles schneller ;)
 
  • Gefällt mir
Reaktionen: Deinorius, Tanzmusikus und fixedwater
cbtestarossa schrieb:
Müssen sie nicht. Wenn man eine Datei downloaded schreibt sich die Datei auf Platte und fertig.
Nope, erst in den Arbeitsspeicher.

Würde ich jetzt etwas trollen, könnte ich dir zumindest hier zustimmen:
cbtestarossa schrieb:
 
  • Gefällt mir
Reaktionen: rarp und fixedwater
cbtestarossa schrieb:
Ja jetzt ist das so, noch vor kurzem hatte man 600 MB Verbrauch und der Rest war frei.
Von wann ist denn der Screenshot in Beitrag #17 ?
Wie ist der Verbrauch jetzt?
Hat sich in der Zwischenzeit etwas verändert (z.B. Updates, Upgrades, neue Dienste/Programme)?

aki schrieb:
Du hast in Beitrag #17 doch selber gezeigt, dass dein System weiterhin nur 600MiB benutzt :) Den Rest bitte einfach ignorieren.
Jep, @cbtestarossa und schau nur auf den benutzten sowie verfügbaren RAM.

Der Cache kann Dir im Grunde egal sein, da dieser nur genutzt wird, wenn noch RAM frei verfügbar ist.
Je mehr dieser verwendet wird, desto schneller läuft Deine Kiste trotz alter Hardware und wenig RAM.

Ich hoffe, Du findest wieder Freude an deinem Manjaro Xfce (Arch). :vernaschen:
 
LochinSocke schrieb:
Nope, erst in den Arbeitsspeicher.
Wenn dem so wäre könntest du keine Datei größer als dein RAM downloaden.
Oder wie hast du dann unter Win98 oder XP mit 500MB-2GB RAM denn eine 8GB Datei downloaden können?
Jaja Ahnung und so.
 
cbtestarossa schrieb:
Wenn dem so wäre könntest du keine Datei größer als dein RAM downloaden.
Solch große Dateien werden ja nicht in einem Stück übertragen, sondern in kleinen Paketen.
https://de.wikipedia.org/wiki/IP-Paket
https://de.wikipedia.org/wiki/Maximum_Transmission_Unit
https://de.wikipedia.org/wiki/Jumbo_Frames

MTU von 1500 ist z.B. der Standard für Ethernet.
Im Falle der Nutzung der Standard-MTU würden alle Daten per Netzwerkverbindung in Pakete von 1500 bit zerteilt und dann über das Internet verschickt werden. (Mit Jumbo-Frames sind sogar bis 9000 bit möglich.)

1500 bit = 187,5 Byte = 0,1875 kB = 0,0001875 MB

Übertragungstechnik

Ethernet transportiert Daten paketweise ohne festes Zugriffsraster. Damit unterscheidet sich Ethernet von anderen paketorientierten Systemen, die mit einem festen Zeitraster jedem Teilnehmer eine Mindestbandbreite garantieren können. Deshalb bereitet Ethernet Probleme bei allen Arten von zeitkritischen Anwendungen. Bei Ethernet gibt es keine Garantie, dass die Daten innerhalb einer bestimmten Zeit den Empfänger erreichen. Das bedeutet, der Erfolg einer Übertragung ist nicht sicher. Er unterliegt nur einer gewissen Wahrscheinlichkeit. So verwerfen Ethernet-Komponenten Datenpakete, wenn nicht genug Bandbreite zur Verfügung steht.
Wegen der unzuverlässigen Übertragungstechnik ist Ethernet auf Fehlerbehandlung höherer Protokolle angewiesen. Das ist auch ein Grund, warum in bestimmten Bereichen heute noch andere Vernetzungstechniken bevorzugt werden. Im Vergleich dazu ist Ethernet eine einfach zu implementierende Vernetzungstechnik, die sich über Jahrzehnte hinweg in lokalen Netzwerken bewährt und durchgesetzt hat.
Quelle: https://www.elektronik-kompendium.de/sites/net/0603201.htm



Diese Datenpakete werden dann über den LAN-Adapter in den RAM geleitet (zwischengespeichert) und von zur CPU an den Datenträger geschickt. Der Arbeitsspeicher fungiert dabei eigtl. immer als Cache.

Ausnahmen (z.B. Direct-Storage) bestätigen die Regel.
 
  • Gefällt mir
Reaktionen: Linuxfreakgraz, Deinorius, ufopizza und eine weitere Person
@Tanzmusikus
Das weiß ich alles.

Seiner Logik nach müsste aber erst mal alles (auch Updates) ins RAM geschrieben werden.
Nein, muss es nicht. Auch nicht beim kopieren von Dateien.
Und früher wurde bei Linux auch nicht soviel Cache verbraten denn das System steht schon im RAM.
Die einzige Frage zum neuen Verhalten ist jetzt, was zum Henker wird in den Cache verfrachtet wenn man das System neu startet.
600-1000 MB ist ja kein Klax.
Vielleicht ist es auch Prefetch/Preload oder sonst was.
Ich mag so ein Verhalten eben nicht und eventuell kann man das Verhalten auch mittels Schalter beeinflussen.
Nicht umsonst spuckt Google einiges aus.
Selbst Logs sollen da drinnen stehen.
 
Zuletzt bearbeitet:
cbtestarossa schrieb:
Seiner Logik nach müsste aber erst mal alles (auch Updates) ins RAM geschrieben werden.
Dann weißt sicherlich auch, dass bei kompakter Schreibweise die Sachverhalte vereinfacht beschrieben werden.

cbtestarossa schrieb:
Nein, muss es nicht. Auch nicht beim kopieren von Dateien.
Jein. Wenn ein Lese-/Schreib-Cache vorhanden ist, dann basiert dieser Cache zu allermeist auf dem RAM.
Bestimmte Tools (z.B. TeraCopy) reservieren sich diesen Cache, auch wenn das OS das so nicht vorgesehen hat.
Unter Linux gibt es sicherlich auch einige mit solchem Feature.

Schönes Wochenende noch!
 
  • Gefällt mir
Reaktionen: Deinorius und cbtestarossa
cbtestarossa schrieb:
zum neuen Verhalten
Ich habe jetzt mal spaßeshalber Ubuntu 6.06.1 mit Kernel 2.6.15 installiert. Das System ist 16 Jahre alt.

Direkt nach dem Starten benutzt es 234MB, 5MB buffers und 139MB cached. Ich würde nochmals vorschlagen diese Werte einfach zu ignorieren, solange alles läuft. Sobald Swap benutzt wird kann man dann mal nachschauen was passiert ist.
 
  • Gefällt mir
Reaktionen: Deinorius, cbtestarossa, ufopizza und eine weitere Person
@Tanzmusikus
Klar nutzen solche Tools auch einen kleinen Cache und selbst HDD/SSD haben meist noch kleinen H/W Cache.


@aki
Ich habe ja eh nix gegen caching. Macht ja Windows auch.
Die Frage ist halt wieviel, was und wann und ob es negative Effekte gibt.
VMware war da zB. sehr heikel.
Ja mal beobachten.
 
cbtestarossa schrieb:
und ob es negative Effekte gibt.
In der Regel ist Caching generell sehr positiv effektiv in Richtung Durchführungsprozessgeschwindigkeit.
Die negativen Begleiterscheinungen macht es nahezu immer wett (Speed, Komplexität, Verbrauch, Preis).

Recherchiere doch dazu bitte mal die Unterschiede in der Übetragungsgeschwindigkeit zwischen SATA-HDD, SATA-SSD, NVMe-SSD auf der einen und DRAM (DDR2/3/4/5) auf der anderen Seite.

Also quasi ein genereller Vergleich zwischen Fest-/Flash- (non-volatile) und Flüchtig- (volatile) Speicher.



cbtestarossa schrieb:
VMware war da zB. sehr heikel.
VMware ist generell eher für Windows-Clients geeignet - Virtualbox eher für UNIX-Clients.

Eine virtuelle Machine benötigt immer mehr Ressourcen vom Host als es die Clients allein benötigen.
 
Hier mal die Angabe des belegten RAMs nach dem Start von EndeavourOS (frisch installiert auf'm Notebook):

Code:
free -h
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:       13Gi       666Mi        12Gi       2,0Mi       403Mi        12Gi
Swap:             0B          0B          0B

Nicht wundern über den Gesamtspeicher. Sind eigtl. 16GiB, aber die iGPU reserviert da wohl mind. 2GiB RAM.



Bei Pop!_OS hatte ich (glaube) eine RAM-Belegung von ~1.2GiB oder 1.6GiB (benutzt) nach dem Systemstart.
Denke, das liegt an den vielen vorinstallierten Programmen, Diensten und zusätzlichen Extensions ggü. Vanilla.

Manjaro stelle ich mir ähnlich vor (bitte korrigiert mich, wenn das nicht stimmen sollte), dass auch dort viele zusätzliche grafische Finessen und Zusatzeinstellungen das Vanilla Arch ergänzen.

Wer also unbedingt RAM sparen muss/möchte, sollte tendenziell ein Vanilla-Linux mit nur wenigen wichtigen Hintergrund-Diensten und schlichter grafischer Oberfläche betreiben.

Grüße
 
cbtestarossa schrieb:
Müssen sie nicht. Wenn man eine Datei downloaded schreibt sich die Datei auf Platte und fertig.
Updates werden in der Regel als komprimiertes Archiv gezogen, die Prüfsummen gebildet und geprüft, entpackt, die entpackten Installanweisungen interpretiert und darauf folgend werden die zu aktualisierenden Dateien aufs Dateisystem gebannt.
Lustigerweise ist dieses Vorgehen bei den Linuxpaketmanagern, Linux Paketformaten (flatpack, snap, ..) Windows Update, Windows AppStore, NuGet, winget[1], Android AppStore, Apple AppStore sehr ähnlich[1].

Wenn zwischen dem Download und dem Berechnen der Prüfsumme das gepackte Archiv noch in Teilen oder noch besser vollständig im Ram liegt, spart sich das Betriebssystem sehr viel Warterei auf den lesenden I/O-Zugriff. Wenn es ums Entpacken geht, ist es auch praktisch, wenn das Archiv noch im Ram liegt. Wenn nach dem Entpacken die entpackten Daten komplett im Ram hat, ist das auch extrem praktisch.

Was jedoch problematisch wäre ist, dass wenn das OS Dateien immer voll in den Ram laden müsste um irgendwas mit Daten zu machen. Das erkennst du ja selbst:

cbtestarossa schrieb:
Wenn dem so wäre könntest du keine Datei größer als dein RAM downloaden.
Oder wie hast du dann unter Win98 oder XP mit 500MB-2GB RAM denn eine 8GB Datei downloaden können?
Jaja Ahnung und so.

Das Betriebssystem läd Dateien nur Blockweise und hält sie im Ram vor. Das aber nicht als statisch reservierten Speicher sondern als "best effort" im Cache. Wenn irgend ein Programm Speicherbereiche einer Datei will und einen Treffer auf dem Cache landet, ist das viel gesparte Zeit. Musste der Cache invalidiert werden, weil der Speicher anderweitig benötigt wurde ist das Pech. Sowas lässt sich vergleichsweise simpel implementieren und verringert iowaits EXTREM. Die Mechanismen sind so wirksam und simpel, dass sowas seit den Uhrzeiten der Betriebssysteme so implementiert wurde und schon zu Win95 Zeiten etabliert war[1]:
http://www.putergeek.com/vcache/

Wenn du jetzt irgendwelche Diskrepanzen bei "früher habe ich das so nicht festgestellt" hast, liegt das wahrscheinlich am ehesten dran, dass die Software nicht genau kommuniziert, was sie eigentlich anzeigt. Wird bei "free" der noch nie genutzte Speicher angezeigt? Der unbelegte Speicher + freigebare Caches/Buffer? Oder gar nur ein Schätzwert, weil im Hintergrund noch Speicherkompression läuft?

Irgendwelche Tricks und Optimierungstools, die einen Cacheflush erzwingen sind gefühlt genauso alt, wie das Caching an sich. Das Einzige was noch (viel) älter ist, sind Leute die irgendwas tun ohne zu verstehen was oder wieso und mit Überzeugung ihre "Lösung" unters Volk bringen.


[1]fast so, als wäre das ein grundlegend gut Idee das so zu machen..
 
  • Gefällt mir
Reaktionen: Linuxfreakgraz, Tanzmusikus und fixedwater
Ja, könnte sein dass die GUI Tools zumindest früher bei OpenSuse/Kubuntu irgendwie nicht das selbe anzeigte
wie jetzt bei XFCE oder FREE.
Es gibt da scheinbar auch nicht groß ne Möglichkeit da etwas manuell zu beeinflussen.
Ergo ist mir der Zeitaufwand auch zu groß um damit herum zu testen.

Was ich aber beobachte ist dass das OS scheinbar echt viel Updates zieht wenn man es nur 1 mal im Monat nutzt.
Jedes mal ca. 1,6 GB ist ja nicht gerade wenig.
Zumindest bis jetzt liefen die Updates ohne Fehler oder Abhängigkeits-Shit durch.
 
Zuletzt bearbeitet:
cbtestarossa schrieb:
Jedes mal ca. 1,6 GB ist ja nicht gerade wenig.
Erscheint mir völlig normal. Es wird ja ein großer Teil des Systems aktualisiert.

cbtestarossa schrieb:
Zumindest bis jetzt liefen die Updates ohne Fehler oder Abhängigkeits-Shit durch.
Das ist doch das Wichtigste. 😊
 
Zurück
Oben