Re: Linux Resourcenverwaltung

[Werner Holtfreter <Holtfreter@xxxxxx>]

Am Sonntag, den 28.10.2012, 17:39 +0100 schrieb Alexander Holler:
> Am 28.10.2012 14:50, schrieb Werner Holtfreter:
> > Am Sonntag, den 28.10.2012, 13:36 +0100 schrieb Alexander Holler:
> >
> >>> 2.) Starte ich LibreOffice wiederholt mit der gleichen Datei nur zum
> >>> lesen, geht das ab dem zweiten Mal natuerlich wesentlich schneller. Aber
> >>> es gibt sowohl beim Oeffnen wie bei Schliessen immer noch
> >>> Festplattenaktivitaet. Warum?
> >>
> >> Libraries sind noch im RAM geladen.
> >
> > Diese Antwort verstehe ich nicht. Gerade wenn die Libraries noch im RAM
> > geladen sind, sollte keine Festplattenaktivitaet noetig sein.
> 
> Alleine von den Libraries lebt Libreoffice nicht, sonst haettest du z.B. 
> keine Rechtschreibpruefung. Da gibt es noch jede Menge andere Dateien die 
> beim Start gelesen werden.

Ja, aber wenn alle diese Dateien im RAM Platz finden und sogar noch
reichlich RAM frei ist, wozu dann Festplattenzugriffe? Man kann doch
erwarten, dass die Dateien dann im RAM gehalten werden. top sagt:

  Ausgangssituation:
Mem:   2958648k total,  1044384k used,  1914264k free,    21348k buffers
Swap:  2061308k total,        0k used,  2061308k free,   332108k cached
  LibreOffice gestartet:
Mem:   2958648k total,  1227108k used,  1731540k free,    23904k buffers
Swap:  2061308k total,        0k used,  2061308k free,   447536k cached
  LibreOffice beendet:
Mem:   2958648k total,  1187424k used,  1771224k free,    24784k buffers
Swap:  2061308k total,        0k used,  2061308k free,   448104k cached
  LibreOffice gestartet:
Mem:   2958648k total,  1238920k used,  1719728k free,    26100k buffers
Swap:  2061308k total,        0k used,  2061308k free,   448288k cached

> >>> 3.) Ich spiegele oefters eine Festplatte mit *niedrigster* Priorisierung:
> >>>         nice -n 19 ionice -c 3 dd if=$historyint of=$historyext bs=1M
> >>> Dabei wurde die normale Rechnernutzung mit alter Bestueckung 2 GByte
> >>> stark ausgebremst (Reaktionszeiten mindestens verdoppelt) und es kam
> >>> manchmal zum voelligen Einfrieren der grafischen Benutzeroberflaeche, die
> >>> sich nur beheben liess, in dem ich die zu beschreibende Festplatte
> >>> entnommen habe.
> >>> Mit 3 GByte ist die Beeintraechtigung nicht mehr deutlich wahrnehmbar, es
> >>> faellt aber auf, dass waehrend dd laeuft, die belegten buffers von top mit
> >>> ca. 1,5 GByte angezeigt wird. Wahrscheinlich ist der Schreibvorgang
> >>> langsamer als der Lesevorgang - aber muss es sein, dass dadurch sinnlos
> >>> der RAM gefuellt wird? Mit cp auf das device statt dd gibt es das gleiche
> >>> Ergebnis.
> >>
> >> Linux nutzt soviel freien RAM als Fesptlattencache wie moeglich, das sind
> >> diese "buffers". Wenn du noch 4GB mehr reinstecken wuerdest, wuerde es
> >> auch diese voll machen. Der spuerbare Unterschied zwischen den 2 GB und 3
> >> GB liegt sehr wahrscheinlich daran, dass mit den 2 GB nicht mehr viel RAM
> >> zum Cachen frei war, es evtl. sogar mal Swappen musste.
> >
> > Da laeuft also der RAM mit Daten eines Kopierprozesses niedrigster
> > Prioritaet voll, ohne dass dieser davon einen Vorteil hat, waehrend
> > gleichzeitig die Lauffaehigkeit der hoeher priorisierten Programme
> > beeintraechtigt wird. Das ist nicht sehr geschickt geloest, um es
> > vorsichtig auszudruecken.
> 
> Du hattest vorher zu wenig RAM der volllaufen konnte, sonst haettest du 
> keine Verbesserung bemerkt. Langsam war das, da das System sehr 
> wahrscheinlich swappen musste. D.h. wenn der Task rsync lief holte es 
> sich dessen Daten von der Platte und wenn der Task LibreOffice lief, 
> wurde diese gespeichert und die Daten des LibreOffice von der Platte geholt.

Als Kopierbefehl lief cp, also noch anspruchsloseres als rsync. Das
grafische System ist (noch mit 2 GB) mehrmals eingefroren, als ich in
Evolution einen Link ins Internet angeklickt habe, wodurch zusaetzlich
Firefox arbeiten musste. Das System stand dann mit leuchtender
Festplatten-LED und lief erst wieder, sobald ich die Festplatte gezogen
habe.

Ohne das kleine, niedrig priorisierte cp hatte ich nie Probleme, selbst
wenn das System swappen musste. Da stimmt doch was nicht.
-- 
Viele Gruesse
Werner Holtfreter

-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/