Google Groups unterstützt keine neuen Usenet-Beiträge oder ‑Abos mehr. Bisherige Inhalte sind weiterhin sichtbar.

Wie gross macht man die Swap-Area ? (war Re: System V Kernelgurus

1 Aufruf
Direkt zur ersten ungelesenen Nachricht

Peter Funk

ungelesen,
19.07.1990, 06:23:1319.07.90
an
Wo wir gerade bei der optimalen Konfiguration von UNIX-Systemen sind :

Bislang haben wir unsere Systeme immer unabhaengig von der tatsaechlich
installierten Platte nach der durch nichts begruendeten Faustregel
konfiguriert, dass die Swap-Area >= dem physikalischen Hauptspeicher
sein sollte. Bei dem juengst von uns fuer einen Kunden konfigurierten
Nixdorf-486 mit 20 MB RAM fuehrt das natuerlich zu einer 20 MB Swap-Area.

Das sich das Manual (sys.admin.guide) des von uns verwendeten SCO XENIX
zu dieser Geschichte sehr einsilbig verhaelt, wuerde mich mal interessieren,
ob ein beliebiges Vergroessern der Swap-Area auch Nachteile mit sich bringt.
(Ausser, das natuerlich in dem oben genannten Fall knapp 2 % der
Plattenkapazitaet fuer Swap reserviert werden ;-)

Auf jeden Fall scheint es so zu sein, dass eine Swap-Area, die kleiner als
der Hauptspeicher ist, leicht zu einem 'Out of swap'-Panic fuehrt.
Das ist leider bei einem unsere guten alten 80386er mit 8 MB Ram und
nur 4 MB Swap-Area leider oefter mal aufgetreten.

Besonders interessant ist die Frage deshalb, weil das Neueinrichten der
Platte natuerlich eine sehr laestige Sache ist, die man nicht jedesmal
machen will, wenn der Hauptspeicher aufgeruestet wird. (Die ersten
Boards mit Sockeln fuer 64 MB Ram auf dem Main-Board sind ja schon im
Anrollen ;-) ).

Gruss, Peter
-->
Peter Funk \\ ArtCom GmbH, Schwachhauser Heerstr. 78, D-2800 Bremen 1
Work at home: Oldenburger Str.86, D-2875 Ganderkesee 1 /+49 4222 6018 (8am-6pm)

Thomas Omerzu

ungelesen,
20.07.1990, 06:16:3420.07.90
an

In Artikel <22...@artcom0.artcom.north.de>
schreibt p...@artcom0.artcom.north.de (Peter Funk):

>Bislang haben wir unsere Systeme immer unabhaengig von der tatsaechlich
>installierten Platte nach der durch nichts begruendeten Faustregel
>konfiguriert, dass die Swap-Area >= dem physikalischen Hauptspeicher
>sein sollte.

Diese Regel ist durchaus _nicht_ unbegruendet.
Viele Unix-Systeme haben die Angewohnheit,
nach einem Panik-Crash einen System-Coredump zu machen
(kann man ihnen normalerweise aber durch Modifikation von
/etc/rc... abgewoehnen)

Dieser Systemcore wird zunaechst in den Swap-Space (!!!) gedumpt,
spaeter dann (normalerweise) nach /usr/crash gesichert.

Es ist natuerlich klar, dass die Swap-Partition >= dem Hauptspeicher
sein muss, da dies die maximale Groesse des Coredumps ist.
Im Zweifelsfall kann dir sonst der Dump deine /usr-Partition
(oder was immer nach der swap-Partition auf der Platte folgt
einfach `plaetten'.

>zu dieser Geschichte sehr einsilbig verhaelt, wuerde mich mal interessieren,
>ob ein beliebiges Vergroessern der Swap-Area auch Nachteile mit sich bringt.
>(Ausser, das natuerlich in dem oben genannten Fall knapp 2 % der
>Plattenkapazitaet fuer Swap reserviert werden ;-)

Jedenfalls keine, die mir bekannt waeren.

Gruss,
Thomas


--
*-----------------------------------------------------------------------------*
Thomas Omerzu UUCP: ...!unido!quando!omerzu / ome...@quando.uucp
Quantum GmbH, Bitnet: UNIDO!quando!omerzu / omerzu%quando@UNIDO(.bitnet)
Dortmund, Germany Internet: ome...@quando.quantum.de

Frank Simon

ungelesen,
20.07.1990, 10:35:1120.07.90
an
Hi !

p...@artcom0.artcom.north.de (Peter Funk) writes:
>Auf jeden Fall scheint es so zu sein, dass eine Swap-Area, die kleiner als
>der Hauptspeicher ist, leicht zu einem 'Out of swap'-Panic fuehrt.

Wenn es nur das waere ....
Direkt hinter dem Swap-Area liegt der User Area ... und wenn nun der
kernel das wahnsinnige Gefuehl bekommt, coren zu muessen ....
dann wird nur der ANFANG des Swap-Areas festgestellt und geschrieben...
ade Userarea.

Terra
--
----------------------------------------------------------------
! Nickname: Terra UUCP: te...@sol.north.de !
! Realname: Frank Simon Geo: mbk1: chaos-team !
! Tel. : +441 76206 EARN: 151133@DOLUNI1 !
! SysOps unterscheiden sich von den Usern dadurch, !
! dass sie dreist sind, viele dazu auch noch dumm (Kluengel)!
----------------------------------------------------------------

Heiko Blume

ungelesen,
20.07.1990, 21:12:2020.07.90
an
ich wuerde dazu neigen ganz locker den swap space doppelt so gross wie das
RAM zu machen. insbesondere wenn die user dazu neigen GNU emacs oder gcc
(moeglich mit -finline-functions) zu benutzen. im hinblick auf moegliche
zukuenftige speichererweiterungen gleich noch ein paar MB mehr.
Noch lustiger wirds mit X Windows + TCP/IP, interactive empfiehlt da 12 MB
swap space wobei die wohl von 8 MB RAM ausgehen.
im zeitalter der grossen festplatten sollte man nicht mit den MBs knausern :-)

bei xenix ist es (soweit ich weiss) ziemlich haesslich, wenn der swap space
zu klein ist, d.h. man kommt um eine reorganisation der divisions nich rum.
(d.h. dass es nicht moeglich ist zur laufzeit {nach dem mounten der root
division und des 'anhaengen' des swap spaces der root platte} weiteren swap
space auf einer anderen platte zu 'adden'.

bei interactive geht das, was auch fuer die performance sehr gut ist, pages
werden dann gleichmaessig auf beide swap files (<- man beachte, swap FILES)
verteilt.
weiss jemand obs bei SCO UNIX /etc/swap gibt ? (das ist das programm mit dem
man swap file zum swap space adden, oder wieder wechnehmen und usage listen
kann).
--
Heiko Blume c/o Diakite bl...@scuzzy.mbx.sub.org FAX (+49 30) 882 50 65
Kottbusser Damm 28 bl...@netmbx.UUCP VOICE (+49 30) 691 88 93
D-1000 Berlin 61 bl...@netmbx.de TELEX 184174 intro d
"Have you bugged your source today?"

Joerg Lehners

ungelesen,
22.07.1990, 01:52:5622.07.90
an
Moin !

In <22...@artcom0.artcom.north.de> p...@artcom0.artcom.north.de (Peter Funk) writes:
>Wo wir gerade bei der optimalen Konfiguration von UNIX-Systemen sind :

>[Swap Konfiguration fuer System V]

Hier 'mal ein paar Random Thougths meinerseits zu diesem Thema.

Swap Space dient ja bekanntermassen als Hintergrundspeicher, wenn
es im Hauptspeicher aus irgendeinem Grunde eng wird.
Aber grad bei System V wird auch Swap-Platz alloziert, oder besser
als von einem Prozess als belegt markiert, obwohl ueberhaupt kein
physikalisches Paging/Swapping auftritt.

Das tritt vor allem bei Unix Versionen auf, die COW (Copy on Write)
oder anderen Techniken zur Veringerung des physikalischen Pagings
besitzen. Die sind die Mechanismen, die BSS-Segment Seiten erst dann
physikalisch allozieren und mit 0 fuellen, wenn sie das erste Mal
beschrieben werden (Zero-Fill on Demand); oder die Text oder Data-Segment
Seiten erst dann aus dem Executable in den Hauptspeicher laden, wenn
diese das erste Mal referenziert werden (Fill-From-File On Demand)

Durch diese Techniken wird oft erfolgreich vermieden, dass physikalisch
Paging gemacht wird (kein Schreib/Lese-Zugriffe auf die Swap-Partition,
auch feststellbar mit sar -w). Aber trotzdem muss fuer alle im
System Laufenden Prozesse gelten (grob):

Summe der Groessen Segmente aller Prozesse < Hauptspeicher + Swapspeicher

Grob, weil gleiche Text-Segmente i.a. geshared werden (also nur
einmal Platz belegen) und die globalen Resourcen (Shared Memory etc)
nicht mit einbezogen sind. Auch 'Hauptspeicher' oben ist nicht der
physikalisch Hauptspeicher, sondern der fuer User-Prozesse (auch root
ist in einer Unix-Maschine ein User) zur Verfuegung stehende Speicher
(also physikalischer Speicher minus des vom Kernel permanent belegten
Speichers, was leicht 1 bis 1.5 MB sein kann).

Wenn ein neuer Prozess kreiert werden soll (durch fork()) muss die
oben angegebene Bedingung eingehalten sein. Wenn sie nicht eingehalten
wuerde (durch den neuen Prozess), so lehnt der Kernel das Prozess-
Kreieren ab.
Obwohl grade beim fork() durch den COW (Copy on Write) Mechanismus
vermieden wird, dass der zu duplizierende Prozess physikalisch
dupliziert wird, muessen die Speicheranforderungen des neuen Prozesses
voll eingerechnet werden: es kann ja sein, dass der Prozess oder auch
der Vater-Prozess seine Seiten schreibend benutzen wird und so der
Kernel echte Duplikate der Seiten machen muss. Wenn dann nicht genug
physikalische Speicherplatz zur Verfuegung stehen wuerde, waere es fuer
den Kernel haarig werden (siehe auch Diskussion in comp.arch der letzten
paar Wochen).
Ein exec() kann aus aehnlichen Gruenden abgelehnt werden, da ein Prozess
durch ein exec() durchaus groesser werden kann. Auch hier wird durch
die Mechanismen Zero-Fill on Demand und Fill-from-File on-Demand zwar
erreicht, dass der Prozess am Anfang seinen Lebens zwar wenig physikalische
Speicherseiten belegt, aber im Laufe seines Lebens kann es durchaus sein,
dass er alle virtuell angemeldeten Speicherresourcen physikalisch belegt.

Aber zurueck zum Thema (wieviel Swap ist gut oder noetig fuer meine Kiste)
Die Groesse des Swapsspace ist ziemlich stark davon abhaengig, welche
Art von Applikationen man auf dem Rechner laufen laesst und wie stark
man die Maschine belastet.
Applikationen wie z.B. Lisp oder Prolog benoetigen oft riesige
virtuelle Address-Raeume, die bei kleinen Problemstellungen aber
oft nicht gebraucht werden (also wegen der o.g. Mechanismen auch nicht
physikalisch alloziert werden). Trotzdem muss aber genuegend Swap
konfigueriert sein, da der Kernel Worst Case rechnet (Worst Case
waere, wenn der Prozess alle angemeldeten Speicherresourcen benutzt).
Auch bei regelmaessiger hoher Auslastung des Rechners sollte man nicht
mit Spap geizen: viele Programme und Utlities melden naemlich erstmal
pauschal einiges an Speicher an, benutzen aber recht wenig physikalisch.

Beispiel: der Newsreader 'nn'. Auf unseren Maschinen belegt er
folgende Speicherresourcen:
Text: 40 Pages (shared)
Shared-Lib Text: 7 Pages (shared)
Data: 70 Pages (private)
Shared-Lib Data: 1 Page (private)
Stack: 3 Pages (private)
Das sind also 74 Pages (=296 KB, 4 KB per Page) privater Speicher
und 47 Pages (=188 KB) shared (von anderen nn's mitbenutzter) Speicher.

Die /bin/sh braucht dagegen nur:
Text: 12 Pages (shared)
Data: 4 Pages (private)
Stack: 3 Pages (private)
Das sind mickrige 7 Pages (= 28 KB) privater Speicher.

Ein anderes und in diesem Zusammenhang besseres Beispiel ist eine aeltere
Version von C-Scheme (Lisp-Dialekt).
Der vom Prozess angemeldete Speicherbedarf ist:
Text: 56 Pages (shared)
Data: 913 Pages (private)
Stack: 3 Pages (private)
Vom Daten-Segement waren nach Aufruf des Scheme und Auswerten von (fak 20)
nur etwa 150 Pages (etwa 600 KB) der angemeldeten 913 Pages (= 3652 KB)
ueberhaupt physikalisch belegt.
Trotzdem muss fuer die unbenutzen 763 Pages auch physikalischer Speicher
allozierbar sein.
(Diese 'Verschwendung' von virtuellem Addressraum war auch der Grund,
warum ich zwei Server-Rechner auf 85 MB Swap konfigurieren musste,
obwohl im unguenstigsten bisher beobachteten Fall nur maximal 30 MB
des Swap-Spaces ueberhaupt benutzt wurden [davon abgesehen krochen
die Maschinen eh nur noch]).
'Lustig' anzusehen ist uebrigens, wenn solch ein Lisp-Prozess fork()t
(z.B. fuer eine Subshell). Der Kernel guckt erstmal nach, ob fuer das
Duplikat genuegend physikalischer Speicher vorhanden ist (das Worst-Case
Verhalten des Kernels). Falls genuegend Platz vorhanden werden
alle Seiten des Vater und Kind-Prozesses Copy on Write eingerichtet.
Danach fuehrt der Kind-Prozess noch ein paar Befehle aus, was bei
Variablen-Zugriffen eventuell zum echten Kopieren von ein paar Seiten fuehrt
und macht ein exec() auf /bin/sh. Dabei schrumpft der Prozess auf die
/bin/sh Groesse zusammen (das Weiterrechner des Vaterprozesses nebenher
fuehrt uebrigens auch zum echten Kopieren veraenderter Speicherseiten).
Obwohl zwischen Erzeugung des Kind-Prozesses und exec auf /bin/sh
nur ein paar wenige Seiten physikalisch alloziert wurden, musste kurzeitig
fuer zwei solcher Riesenprozesse physikalischer Speicherplatz vorhanden
sein.

Grad dies' letzte Beispiel zeigt, dass man sich bei Swap-Geiz gewisse
Applikationen verbaut.

Meine Faustregel deswegen:
Applikationsmischmasch und relativ wenig Benutzer:
Pagespeicher >= 2 * physikalischer Hauptspeicher
Aber auch Maschinen mit nur 2 MB Hauptspeicher wuerde ich mehr als 6 MB
Pagespeicher geben.
Und pro aktivem Benutzer wuerde ich nochmal mindestens 1 bis 2 MB
dazupacken.
Fuer Spezialanwendungen (KI-Sprachen, Lisp, Prolog, Datenbanken, etc.)
kann es durchaus notwendig sein, ueber 30 MB Pagespeicher fuer einen
einzigen Benutzer zu haben.

Wenn man sich mit den Systemkommandos (/etc/swap oder sar) die
aktuell Pagesspeicherbelegung ansieht, wird man aber oft feststellen,
das nicht sehr viel Pagespeicher aktuell benutzt wird, dank
Copy On Write, Zero-Fill on Demand und Fill-From-File on Demand.

Diese Ausfuehrungen gelten im wesentlichen nur fuer das Memory-
management, wie man es bei System V Derivaten findet.
BSD Derivate und einiger andere Unix-Versioenen haben teilweise
andere Memorymanagement Mechanismen.
Ebenfalls andere Memorymanagement Mechanismen haben Swapping-Unix
Versionen. Meist Unixe die auf '286er laufen oder 68000ern.
Die Mechanismen CoW, ZFoD, FfFoD setzen naemlich eine MMU und
die Restartfaehigkeit von durch Page-Faults unterbrochenen
Maschinenbefehlen voraus.
SunOS 4.x zum Bespiel *muss* mindestens soviel Swapspace besitzen
wie phsyikalischer Speicher, da temporaer durchaus der gesammte
physikalische Hauptspeicher als Buffer Cache verwendet werden kann.
Saemltliche Prozesse werden dann ausgepaged.
Auch kann bei SunOS aus diesem Grunde die Summe aller Prozessgroessen
nur so gross sein, wie der Pagespeicher.

Hoffe geholfen zu haben und Bis denn
Joerg Lehners
--
/ UUCP: lehners@uniol | Joerg Lehners \
| ...!uunet!unido!uniol!lehners | Fachbereich 10 Informatik ARBI |
| BITNET: 066065 AT DOLUNI1 | Universitaet Oldenburg |
\ Inhouse: aragorn!joerg | D-2900 Oldenburg /

Frank Kaefer

ungelesen,
22.07.1990, 12:47:1022.07.90
an
ome...@quando.quantum.de (Thomas Omerzu) writes:

|In Artikel <22...@artcom0.artcom.north.de>
|schreibt p...@artcom0.artcom.north.de (Peter Funk):

|>konfiguriert, dass die Swap-Area >= dem physikalischen Hauptspeicher

|Diese Regel ist durchaus _nicht_ unbegruendet.

Also, ich kenne da die Regel: Swap = RAM * 2 (so machen wirs zumindest
in der Arbeit). Any further comments on that ?

Gruss, Frank
--
-------------------------------------------------------------------
| Frank Kaefer | f...@stasys.sta.sub.org | Starnberg, West Germany |
| (Compuserve: 72427,2101) | (BIX: fkaefer) | f...@Germany.sun.com |
-------------------------------------------------------------------

Rainer Bieniek

ungelesen,
22.07.1990, 20:05:4122.07.90
an
s...@scuzzy.mbx.sub.org (Heiko Blume) writes:
>bei xenix ist es (soweit ich weiss) ziemlich haesslich, wenn der swap space
>zu klein ist, d.h. man kommt um eine reorganisation der divisions nich rum.
>(d.h. dass es nicht moeglich ist zur laufzeit {nach dem mounten der root
>division und des 'anhaengen' des swap spaces der root platte} weiteren swap
>space auf einer anderen platte zu 'adden'.
Ich habe ihn zwar noch nicht ausprobiert, aber ich weiss, dass es bei
den neueren Xenix`en, d.h. 2.3.2 oder 2.3.3 den swapadd(S)-Call gibt, mit
dem man wohl swap-space hinzufuegen kann. Also, Heldenprogrammierer an
die Front :-)

Rainer
--
+- Rainer Bieniek rainer@flyer -+
| Wilhelmstr. 10 4100 Duisburg 11 |
| +49 0203/4060004 (0800-2100 ohne Carrier) |
| hz2...@sun-hrz.uni-duisburg.de, |

Walter Mecky

ungelesen,
23.07.1990, 20:35:1423.07.90
an
In article <1990Jul21.0...@scuzzy.mbx.sub.org> s...@scuzzy.mbx.sub.org (Heiko Blume) writes:
< weiss jemand obs bei SCO UNIX /etc/swap gibt ? (das ist das programm mit dem
< man swap file zum swap space adden, oder wieder wechnehmen und usage listen
< kann).

Jawoll. Gibt's.
--
Walter Mecky [ wal...@mecky.uucp or ...uunet!unido!mecky!walter ]

Heiko Blume

ungelesen,
26.07.1990, 21:47:1426.07.90
an
wal...@mecky.UUCP (Walter Mecky) writes:

>In article <1990Jul21.0...@scuzzy.mbx.sub.org> s...@scuzzy.mbx.sub.org (Heiko Blume) writes:
>< weiss jemand obs bei SCO UNIX /etc/swap gibt ? (das ist das programm mit dem
>< man swap file zum swap space adden, oder wieder wechnehmen und usage listen
>< kann).

>Jawoll. Gibt's.

na heldenhaft. da kann ich gleich noch beisteuern wie man von einem
programm aus mit den swap files rumspielen kann: mit dem sysi86(2)
system call. mehr info findet sich in <sys/sysi86.h>.

0 neue Nachrichten