Re: Linux Resourcenverwaltung

[Markus Demleitner <msdemlei@xxxxxxxxxxxxxxxxxxxxx>]

Hallo allerseits,

On Sun, Oct 28, 2012 at 06:34:29PM +0100, Werner Holtfreter wrote:
> 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:
> > >> 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

Werners Frage ist durchaus berechtigt.  Im Prinzip sollte eigentlich
der ganze Krempel in irgendwelchen Buffern sein und in der Tat aus
dem RAM kommen koennen.

Ich *vermute* (verifizieren liesse sich das ggf. mit tools wie iostat,
ggf. in Verbindung mit strace), dass die meiste tatsaechliche
I/O-Aktivitaet hier Schreibzugriffe sind -- logfiles,
Einstellungs-Dateien, weiss der Geier, was so Office-Krempel alles
tut.  Gerade bei solchen Dingen gehen Programme (manchmal
berechtigterweise) recht liberal mit fsync(2) zur Sache -- das sorgt,
grob gesprochen, dafuer, dass alles, was zu einer Datei noch im Cache
zum Schreiben liegt, auf die Platte kommt.

> > >>> 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.
[...]
> 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.

Auch hier lautet die Antwort vermutlich fsync.  Firefox nutzt intern
recht eifrig sqlite, das wiederum zur Gewaehrleistung von
Integritaetsgarantien, die man von Datenbanken gerne haette, 
freizuegig mit fsync umgeht.  

Das waere an sich nicht so schlimm, wenn nicht jedenfalls ext3 in der
Defaulteinstellung (data=ordered) haeufig (disclaimer: Die Details
habe ich nicht mehr im Kopf) den kompletten Schreibcache auf die
Platte braten wuerde, wenn eine Datei gesynct werden muss. Wenn beim
Kopieren 2 GB RAM fast vollstaendig mit zu schreibenden Daten gefuellt
sind, bleibt ein Prozess, der fsync auf irgendeine Datei macht,
einfach stehen, bis all die Gigabytes geschrieben sind, und das kann
bei so einem Speicherausbau und maessig schnellen Platten schon mal
dauern.

Die Prozesse ausser Firefox sollten davon allerdings nicht betroffen
sein (d.h., ich glaube nicht recht an "Desktop eingefroren").  Auch
glaube ich nicht, dass ein Speicherausbau dieses Problem entschaerfen
sollte, eher im Gegenteil, weil potenziell noch mehr Krempel zum
Schreiben da ist...

Um das zu reparieren, gibts verschiedene Ansaetze; eine Moeglichkeit
ist, die Integritaetsanforderungen an das Dateisystem zu lockern
(mount(8), nach "data=" suchen), eine andere, firefox zu einem
entspannteren Verhaeltnis zu deiner History zu verhelfen
(about:config, toolkit.storage.synchronous=0 -- so hiess das
jedenfalls mal).

Gruesse,

           Demi

-- 
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/