Re: Fehler von Swappartition

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Fri, 27 May 2005 12:09:06 +0200 (CEST)

Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> On Wed, May 25, 2005 at 05:40:22PM +0200, Oliver Fromme wrote:
> > Übrigens 20 Sekunden, wie ich gerade im Source nachgeschla-
> > gen habe (src/sys/vm/swap_pager.c). Das ist eigentlich
> > schon eine ziemlich lange Zeit.
>
> Ja - das ist lange, aber ein Spin-Up einer Platte kann durchaus
> länger dauern

Ich hatte mal eine Monsterfestplatte (Quantum Bigfoot),
die für den Spin-up etwa eine halbe Minute brauchte, dabei
wie ein startender Düsenjet klang und 30 Watt Strom von der
12V-Schiene gezogen hat. Das ist aber wohl eher die Aus-
nahme; heutige »normale« Festplatten brauchen eher deutlich
unter 10 Sekunden

Der Beschreibung nach ist hier nicht der Spin-up das Pro-
blem. (Mal davon abgesehen, daß man bei einem Server kein
Spin-down aktivieren sollte, insbesondere wenn auf der
Festplatte eine Swap-Partition liegt.)

> vom reboot eines NFS Servers mal abgesehen.

Da hast Du recht (obgleich ein Rechner, der als NFS-Server
für Diskless-clients fungiert und auch deren Swap beher-
bergt, hochverfügbar ausgelegt sein sollte).

In diesem Fall ist aber kein NFS im Spiel.

> > > Wäre mal eine Überprüfung wert, macht aber wenig Sinn mit hoher
> > > Prio zu arbeiten, falls man vorsorglich auslagert.
> >
> > Es geht hier um Lesezugriffe. Bei denen ergibt es Sinn.
>
> Das macht auch beim Schreiben nicht mehr oder weniger Sinn, da beim
> Schreiben schließlich Mechanismen warten müssen, die dafür sorgen, dass
> das System genügen Luft hat.

Ich habe nicht geschrieben, daß es beim Schreiben generell
keinen Sinn ergibt. Beim vorsorglichen Auslagern aller-
dings muß es nicht unbedingt sein, denn dieses soll ja das
System nicht mehr als nötig belasten.

> Dann stellt sich aber auch die Frage, warum bei swap_pager und nicht
> beim vnode_pager - oder ob man beim vnode_pager zufällig an NFS gedacht
> hat?

Es gibt im Source ein paar Stellen mit Spezialbehandlung
für NFS, aber im großen und ganzen ist der Code unabhängig
vom darunterliegenden Medium.

> > Der Swap-Pager (swap_pager.c) weiß gar nichts von Prozes-
> > sen. Die Pages können ja auch gar nicht eindeutig irgend-
> > welchen Prozessen zugeordnet werden.
> >
> > Das Handling von Prozessen übernimmt der »Page-out Daemon«
> > (vm_pageout.c). Der weiß wiederum nichts von Swap-Areas
> > und wo sie liegen (lokale Partitionen, NFS oder sonstwas).
>
> Irgendwie kann ich dir nicht ganz folgen.
> Natürlich muss der über die Lage nichts wissen - eben dafür hat er
> ja einen zugeordneten Pager, wie z.B. den swap_pager.

Genau.

> Außerdem hast du ja bereits selber geschrieben, dass es ums lesen
> geht - aufs lesen sollte der Page-out Daemon IMHO niemals warten müssen.

Richtig, muß er auch nicht.

> Gelesen wird normalerweise nach einem Page-Fault oder vergleichbarem -
> und der Thread, der den Fault ausgelöst hat muss logischerweise auf
> den zuständigen Pager warten.

Richtig. Wobei natürlich auch mehrere Threads/Prozesse auf
dieselben Pages warten können (d.h. die Zuordnung ist nicht
unbedingt eindeutig). Wenn ich den Code richtig interpre-
tiere, versucht der Pager auch, zusammenhängende Pages mög-
lichst am Stück wieder hereinzulesen, d.h. auch Pages, die
keinen Page-fault ausgelöst haben und die nicht benötigt
werden (und deren Fehlen zur Zeit keinen Thread oder Prozeß
blockieren würde) -- wohl als Optimierung unter der Annahme,
daß diese Pages demnächst auch benötigt werden könnten.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"Python is an experiment in how much freedom programmers need.
Too much freedom and nobody can read another's code; too little
and expressiveness is endangered."
        -- Guido van Rossum
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 27 May 2005 - 12:10:11 CEST

search this site