Swap auf einem Desktopsystem sinnvoll?

[Georg Schwarz]

Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
deutlich mehr GB an RAM eine Swappartition anzulegen?

[Sven Hartge]

Georg Schwarz <georg....@freenet.de> wrote:

> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
> deutlich mehr GB an RAM eine Swappartition anzulegen?

Warum nicht? Es gibt immer Programme, wie z.B. nur einmal alle 24
Stunden benötigt werden und die der Kernel dann auslagern kann, um mehr
RAM für den Cache oder andere Anwendungen zu haben.

Solange du nicht Suspend-To-Disk machen willst ist aber Swap im Bereich
von 2GB vollkommen ausreichend.

S°

--
Sigmentation fault. Core dumped.

[Arno Welzel]

Georg Schwarz:

> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
> deutlich mehr GB an RAM eine Swappartition anzulegen?

Hier laufen einige Systeme mit 8-32 GB RAM ohne Swapspace ohne Probleme.


--
Arno Welzel
https://arnowelzel.de

[Manuel Reimer]

On 29.03.21 12:05, Georg Schwarz wrote:
> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
> deutlich mehr GB an RAM eine Swappartition anzulegen?

Gefühlt alle 6-7 Monate mal für Debugging-Zwecke. Dann aber nur bei
Bedarf manuell aktiviert.

Meist letztlich nur um zu prüfen ob ein Programm wirklich versucht allen
Speicher zu belegen oder irgendwann doch mal zufrieden ist. Die Antwort
ist bisher immer gewesen: Swap hilft auch nicht.

Meine Erfahrung mit Swap war bisher auch immer das der Kernel das gar
nicht nutzt solange noch RAM frei ist. Und bei dem was heute so an RAM
verbaut wird hatte ich im reinen Desktop-Betrieb nie RAM-Mangel.

Gruß

Manuel

[Tim Ritberg]

Am 29.03.21 um 12:35 schrieb Manuel Reimer:

>
> Meine Erfahrung mit Swap war bisher auch immer das der Kernel das gar
> nicht nutzt solange noch RAM frei ist. Und bei dem was heute so an RAM
> verbaut wird hatte ich im reinen Desktop-Betrieb nie RAM-Mangel.
>

Meine durchschnittliche Swap-Nutzung im Jahr ist 350MB und
maximal 3,2 GB bei 32 GB RAM.

Tim

[Stefan Froehlich]

On Mon, 29 Mar 2021 12:35:10 Manuel Reimer wrote:
> On 29.03.21 12:05, Georg Schwarz wrote:
> > Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
> > deutlich mehr GB an RAM eine Swappartition anzulegen?

> Gefühlt alle 6-7 Monate mal für Debugging-Zwecke. Dann aber nur

> bei Bedarf manuell aktiviert. [...]

> Meine Erfahrung mit Swap war bisher auch immer das der Kernel das
> gar nicht nutzt solange noch RAM frei ist. Und bei dem was heute
> so an RAM verbaut wird hatte ich im reinen Desktop-Betrieb nie
> RAM-Mangel.

Alle paar Wochen sind die Browser durch Memory-Leaks so aufgebläht,
dass sie meine derzeit 16G komplett ausfüllen. Der Vorteil einer
Swap-Partition ist dann, dass nicht wahllos Prozesse abgeschossen
werden, sondern das System so langsam wird, dass es auffällt und man
die schuldigen manuell entsorgen und neu starten kann.

Sorgfältig programmierte Browser wären freilich besser, scheinen
aber utopisch.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Belegte Himmel verdient Berlin: Stefan!
(Sloganizer)

[Claus Reibenstein]

Georg Schwarz schrieb am 29.03.2021 um 12:05:

> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
> deutlich mehr GB an RAM eine Swappartition anzulegen?

Das kommt ganz darauf an, was Du damit machen möchtest.

Für die üblichen Office-Aufgaben dürftest Du ohne Swap auskommen. Bei
anspruchsvolleren Aufgaben (große Datenbanken, virtuelle Maschinen, CAD,
Video-Bearbeitung) könnte es bei 4 GB recht schnell eng werden.

Gruß
Claus

[Andreas Neumann]

Stefan Froehlich wrote:

> Alle paar Wochen sind die Browser durch Memory-Leaks so aufgebläht,
> dass sie meine derzeit 16G komplett ausfüllen. Der Vorteil einer
> Swap-Partition ist dann, dass nicht wahllos Prozesse abgeschossen
> werden, sondern das System so langsam wird, dass es auffällt und man
> die schuldigen manuell entsorgen und neu starten kann.

Prinzipiell richtig, aber bei mir war der Übergang zum swappen und zäh
werden so schnell und massiv, dass Umschalten zur console, einloggen und
firefox abschiessen bereits zu lange dauerte, einmal habe ich
interessehalber über eine Stunde gewartet. Ich habe in dieser Zeit (vor 2-3
Jahren?) oft hart abgeschaltet und auf die Recovery-Fähigkeiten von ext4
vertraut.
Irgendwann habe ich mir dann entnervt ein script geschrieben, welches kurz
vorm Volllaufen des Speichers ein Info-Fenster aufpoppen ließ und so
genügend Zeit für Gegenmaßnahmen blieb.

> Sorgfältig programmierte Browser wären freilich besser, scheinen
> aber utopisch.

Mir scheint, die Qualität von Software ist heutzutage genauso im Absturz
begriffen wie bei den meisten Consumerartikeln.

Immerhin lässt die buggyness von firefox hier derzeit wieder ein durchlaufen
von 2-3 Wochen zu. Was sich aber bekanntermaßen schnell wieder
verschlechtern kann...

[Stefan Froehlich]

On Mon, 29 Mar 2021 13:24:00 Karl Davis wrote:
> Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
> > Alle paar Wochen sind die Browser durch Memory-Leaks so aufgebläht,
> > dass sie meine derzeit 16G komplett ausfüllen. Der Vorteil einer

> Kann ich nicht bestätigen (Debian Buster, meistgenutzt ist Firefox
> ESR). Ich habe mir 16GB Swap eingerichtet bei bis vor vier Wochen
> "nur" 8GB RAM. Da wurde in den letzten 6 Jahren vielleicht mal 2GB
> von genutzt - wenn überhaupt.

Wie lange lässt Du den Firefox denn laufen? Bei mir belegt er
momentan "nur" 4GB, aber er wurde auch erst vor wenigen Tagen neu
gestartet. Chromium und Google-Chrome liegen momentan etwas
darunter, aber damit ist der Speicher in Summe dann auch schon
wieder ganz gut gefüllt. Länger als zwei Wochen hält das leider nur
selten durch.

> Für Rechner mit typischen "Bürotätigkeiten" halte ich Swap
> mittlerweile für nicht mehr notwendig.

Ein Rechner, den ich täglich neu startet, bräuchte auch keinen Swap,
das ist korrekt.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - denn vertraute Liebe wimmert niemals.
(Sloganizer)

[Juergen Ilse]

Georg Schwarz <georg....@freenet.de> wrote:
> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
> deutlich mehr GB an RAM eine Swappartition anzulegen?

Bei aktuellen Kerneln hat eine Swapdatei im Filesystem keinne wesentlichen
Nachteile mehr gegenueber einer Swap-Partition. Mit Swap-Dateien ist man
womoeglich flexibler, deswegen wuerde ich evt. Swwapdateien gegenueber
Swappartitionen vorziehen ...

Ich wuerde auf jeden Fall auch bei viel Speicher (nein 4 GB ist in
heutiger Zeit nicht so furchtbaar viel Speicher) Swap einrichten.
Nicht genutzter Swap frisst kein Brot, fehlender benoetigter Swap
fuehrt moeglicherweise zur unerwuenschten Beendigung von Prozessen ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Arno]

Georg Schwarz <georg....@freenet.de> wrote:

> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
> deutlich mehr GB an RAM eine Swappartition anzulegen?

Da ich in der nächsten Zeit ein neues Ubuntu (20) installiere: Die
gleiche Frage: Ist swap bei 64 GB RAM (Ja...) und 2 TB SSD an NVe/PCI4
noch sinnvoll? Derzeitig geplante Arbeitsumgebung: Einige HDDs
durchsuchen nach alten Dateien (Bilder, 20 ..40 MB/Datei), Browserspiel,
vielleicht Bild- oder Videobearbeitung. Das Ubuntu wird auf Jahre nur
ein Nebensystem sein und eher selten benutzt.

--
Seit ... nutze ich:
1960: Diese Erde. 1963: Fahrräder.
1985: Apple Computer. 1999: Das Internet
2012: Newsgroups..

[Andreas M. Kirchwitz]

Georg Schwarz <georg....@freenet.de> wrote:

> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
> deutlich mehr GB an RAM eine Swappartition anzulegen?

Ja, Swap kann sinnvoll sein, denn Anwendungen können formell einen
sehr hohen Speicherbedarf (RAM + Swap) verursachen, der zwingend
gedeckt sein muss, egal ob RAM oder Swap. Es spielt keine Rolle,
ob die Anwendungen dies tatsächlich nutzen oder nicht.

Mit Swap überbucht man das RAM, spekuliert aber darauf, dass man
den Swap-Bereich niemals oder höchstens selten wirklich benötigt.

Inzwischen sind in Home-PCs RAM-Ausbauten möglich, wo Swap keine
Rolle mehr spielt. "Möglich" heißt freilich nicht, dass jeder das
hat oder sein Geld speziell dafür ausgeben möchte statt für was
anderes in seinem Leben.

Ich würde für RAM-Ausstattungen bis eineschließlich 8 GB noch Swap
vorsehen, da kratzen selbst normale Web-Browser manchmal dran.
Ab 16 GB wäre ich entspannt auch ohne Swap, aber das mag bei jedem
anders sein. Ich mache z.B. keine Bild- oder Videobearbeitung und
brauche auch keine hundert Tabs im Browser. Jeder ist da anders.

Es mag Leute geben, die schrammeln selbst mit 64 oder 128 GB RAM
bereits am Limit ihres PCs, noch bevor sie überhaupt die erste VM
gestartet haben. Es gibt nichts, was es nicht gibt.

Grüße, Andreas

[Peter Blancke]

Am 2021-03-29, Juergen Ilse <ne...@usenet-verwaltung.de> schrieb:
> Georg Schwarz <georg....@freenet.de> wrote:

>> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
>> deutlich mehr GB an RAM eine Swappartition anzulegen?

> Bei aktuellen Kerneln hat eine Swapdatei im Filesystem keinne
> wesentlichen Nachteile mehr gegenueber einer Swap-Partition. Mit
> Swap-Dateien ist man womoeglich flexibler, deswegen wuerde ich
> evt. Swwapdateien gegenueber Swappartitionen vorziehen ...

Es sei denn, Swap ist im LVM eingebunden, wie auf meinen Systemen.
Der läßt sich problemlos und nach Bedarf
verkleinern/vergrößern/abschalten.

> Ich wuerde auf jeden Fall auch bei viel Speicher (nein 4 GB ist in
> heutiger Zeit nicht so furchtbaar viel Speicher) Swap einrichten.

Mir erschließt sich bei heutigen Festplattengrößen ohnehin kaum noch
die Notwendigkeit einer Größendiskussion. Dann schon eher: Swap --
Ja oder Nein?

Und bitte mal nach "swapusage" googlen, das Skript hat mir schon oft
erstaunliche Ergebnisse angeliefert, wer denn da am Speicher so
heftiglich herumnagt.

Aber nur mal als Beispiel. Bei folgendem Befehl:

rsync -a --numeric-ids --times --links --hard-links --partial \
--block-size=8192 --delete \
$QUELLE \
$ZIEL \
> backup.log 2>backup.err

steht bei mir im Handbuch als Zusatzbemerkung:

"Vorher Swap einrichten, der braucht viel davon!"

Wie immer: Der Anwendungsfall entscheidet!

Gruß,

Peter Blancke

--
Hoc est enim verbum meum!

[Arno Welzel]

Marcus Jodorf:

> Arno Welzel <use...@arnowelzel.de> schrieb:

>
>>> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
>>> deutlich mehr GB an RAM eine Swappartition anzulegen?
>>
>> Hier laufen einige Systeme mit 8-32 GB RAM ohne Swapspace ohne

> ^^^
>> Probleme.
>
> Ich hab das Problem hinsichtlich der Antwortsignifikanz mal oben unterstrichen ;-)
>
> ~$ free -h
> total used free shared buff/cache available
> Mem: 31Gi 15Gi 7.8Gi 2.1Gi 8.3Gi 13Gi
> Swap: 31Gi 14Gi 17Gi
> ~$
>
> Ohne Swap würde ich zumindest nur mit 32GB überhaupt nicht klarkommen.

System 1, Server für etliche Dienste (Nextcloud, Mailserver etc.) für
ca. 80 Leute. Der nutzt das RAM überwiegend als Cache:

total used free shared buff/cache available
Mem: 31G 6.4G 801M 162M 24G 24G
Swap: 0B 0B 0B

System 2, eine Entwicklungsumgebung:

total used free shared buff/cache available
Mem: 7.8G 5.7G 224M 24M 1.9G 1.8G
Swap: 0B 0B 0B

> Oder einfacher:
>
> Frage kann man schlicht nicht beantworten, solange man nicht weiß, wie
> der Rechner benutzt wird.

Oder genauer: es kommt darauf an, ob das RAM alleine für die Anwendungen
ausreicht.

[Arno Welzel]

Arno:

> Georg Schwarz <georg....@freenet.de> wrote:
>
>> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
>> deutlich mehr GB an RAM eine Swappartition anzulegen?
>
> Da ich in der nächsten Zeit ein neues Ubuntu (20) installiere: Die
> gleiche Frage: Ist swap bei 64 GB RAM (Ja...) und 2 TB SSD an NVe/PCI4
> noch sinnvoll? Derzeitig geplante Arbeitsumgebung: Einige HDDs
> durchsuchen nach alten Dateien (Bilder, 20 ..40 MB/Datei), Browserspiel,
> vielleicht Bild- oder Videobearbeitung. Das Ubuntu wird auf Jahre nur
> ein Nebensystem sein und eher selten benutzt.

Bei 64 GB RAM und diesem Anwendungsszenario ist swap überflüssig. Wenn
Du wirklich jemals in die Situation kommen solltest, dass selbst 64 GB
Speicher zu wenig sind, hast Du eh ganz andere Probleme.

[Marcel Mueller]

Am 29.03.21 um 12:05 schrieb Georg Schwarz:

> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
> deutlich mehr GB an RAM eine Swappartition anzulegen?

Swap brauchst du immer.
1. wegen Overcommitment
2. für Suspend to Disk

Aber eine Swap-Partition braucht es dafür nicht. Ausreichend Platz auf
der Platte (oder SSD) tut es genauso. Also so wie es alle anderen
Betriebssysteme schon seit Jahrzehnten machen.


Marcel

[Marcel Mueller]

Am 31.03.21 um 21:53 schrieb Marcus Jodorf:
> Marcel Mueller <news.5...@spamgourmet.org> schrieb:

>
>> Aber eine Swap-Partition braucht es dafür nicht. Ausreichend Platz auf
>> der Platte (oder SSD) tut es genauso. Also so wie es alle anderen
>> Betriebssysteme schon seit Jahrzehnten machen.
>

> Was bei Linux ja auch schon seit Jahrzehnten geht. Aber insbesondere zu
> Zeiten des drehenden Rosts wollte man das aus naheliegenden Gründen eher
> nicht und daher war das unüblich.

War das wirklich nur den Platten geschuldet?
Mir war irgendwie, dass der Zugriffspfad über das Dateisystem früher
nicht sonderlich effizient implementiert war. Ich meine, das ist ja auch
nicht trivial. Page Faults können in allen möglichen Kontexten auftreten.


Marcel

[Helmut Waitzmann]

Marcel Mueller <news.5...@spamgourmet.org>:

>Swap brauchst du immer.
>
>1. wegen Overcommitment
>

Wenn ich mir im Handbuch «proc(5)» die Abschnitte zu
«/proc/sys/vm/overcommit_memory» einerseits und
«/proc/sys/vm/overcommit_ratio» und «/proc/sys/vm/overcommit_kbytes»
andererseits ansehe, erkenne ich da zwei verschiedene Bedeutungen
von memory overcommitment:  In der ersten bedeutet es, das System
sich über die Menge des freien virtuellen Speichers in die Tasche
lügen zu lassen.  In der zweiten beantwortet es die Frage, ob zum
für virtuellen Speicher verwendbaren Speicher zusätzlich zur Größe
des Swapspaces auch Anteile der Größe des Hauptspeichers gerechnet
werden sollen. 


Auf welche Bedeutung hebst Du mit

>Swap brauchst du immer.
>
>1. wegen Overcommitment
>

ab? 

>2. für Suspend to Disk
>

Genau:  Bei Suspend to Disk muss alles, was im Hauptspeicher sitzt,
im Massenspeicher untergebracht werden (oder sein), weil dem
Hauptspeicher der Strom abgestellt werden wird.  Wenn
«/proc/sys/vm/overcommit_ratio» und «/proc/sys/vm/overcommit_kbytes»
auf 0 stehen, ist diese Voraussetzung stets gegeben.  Dazu muss
allerdings genügend Swapspace vorhanden sein. 

[Arno Welzel]

Marcel Mueller:

> Am 29.03.21 um 12:05 schrieb Georg Schwarz:
>> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
>> deutlich mehr GB an RAM eine Swappartition anzulegen?
>
> Swap brauchst du immer.
> 1. wegen Overcommitment

Bitte erläutern. Besonders vor dem Hintergrund, dass auch Swap-Space
nicht beliebig groß ist.

> 2. für Suspend to Disk

Nur, wenn man das auch nutzen will.

[Andreas Kohlbach]

On Wed, 31 Mar 2021 23:10:35 +0200, Helmut Waitzmann wrote:
>
> Marcel Mueller <news.5...@spamgourmet.org>:

>
>> 2. für Suspend to Disk
>
> Genau:  Bei Suspend to Disk muss alles, was im Hauptspeicher sitzt, im
> Massenspeicher untergebracht werden (oder sein), weil dem
> Hauptspeicher der Strom abgestellt werden wird.  Wenn
> «/proc/sys/vm/overcommit_ratio» und «/proc/sys/vm/overcommit_kbytes»
> auf 0 stehen, ist diese Voraussetzung stets gegeben.  Dazu muss
> allerdings genügend Swapspace vorhanden sein. 

«/proc/sys/vm/overcommit_ratio» ist hier 50, der andere 0.

Hatte mir den Swap-Space lange zuvor eingerichtet, bevor ich das erste
Mal an suspend to disk dachte. Das erklärt nun, warum das bei mir nie
funktionierte (Fehlermeldung beim Suspend gab es IIRC aber keine auf der
Konsole): habe 4 GB RAM, aber nur 2 GB Swap eingerichtet.

Danke.
--
Andreas

https://news-commentaries.blogspot.com/

[Hermann Riemann]

Am 29.03.21 um 13:55 schrieb Juergen Ilse:

> Georg Schwarz <georg....@freenet.de> wrote:
>> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
>> deutlich mehr GB an RAM eine Swappartition anzulegen?
>

> Bei aktuellen Kerneln hat eine Swapdatei im Filesystem keine wesentlichen

> Nachteile mehr gegenueber einer Swap-Partition. Mit Swap-Dateien ist man
> womoeglich flexibler, deswegen wuerde ich evt. Swwapdateien gegenueber
> Swappartitionen vorziehen ...

Einer Frage ist,ob die Verwaltung mit open, Dateiverlängerung und close
einen erheblichen Zeitaufwand hat.

Und dann gibt es noch die Frage, ob man die partition,
in der die swap Datei liegt, frei wählen kann.
Ich lege meine swap partition auf HD statt auf SSD,
weil ich sonst wegen endlicher Überschreibzahl Nebeneffekte vermute.

> Ich wuerde auf jeden Fall auch bei viel Speicher (nein 4 GB ist in

> heutiger Zeit nicht so furchtbar viel Speicher) Swap einrichten.

Wegen möglicher swap Benutzung ( z.B. bei scp -rp von ca 1TB )
und suspend to disk würde ich doppelten RAM Speicherplatz empfehlen.

> Nicht genutzter Swap frisst kein Brot,

solange es auf dem "Lauf"werk nicht eng wird.

> fehlender benoetigter Swap
> fuehrt moeglicherweise zur unerwuenschten Beendigung von Prozessen ...

Nicht unbedingt.
Ich habe mal ( vor Jahrzehnten) den swap abgeschaltet.
Dann mittels eines C Programmes den meisten Speicher angefordert
( mit 0 belegt um ihn auch zu "benutzen" ) dann auf Eingabe gewartet.

Die anschließende Benutzung mit vi führte dazu
dass sehr viel zeit zwischen dem Tippen eines Buchstabens
und deren Anzeige auf dem Bildschirm verging.

Ein weiter Variante war ca 20% der Festplatte als swap einzurichten,
und es dann von gleichartigem C Programm zu benutzen.
Es gab da große Wartezeiten.
Fazit, swap Benutzung ist bei zeitkritischem Verwendung
nicht empfehlenswert.

Hermann
vermutend, das er swap für eigene Programme so lange
nicht benötigen wird, wie swap vorhanden ist.

--
http://www.hermann-riemann.de

[Helmut Waitzmann]

Andreas Kohlbach <a...@spamfence.net>:

Damit suspend to disk funktioniert, muss zum Zeitpunkt des suspends
mindestens so viel Swapspace frei sein, wie zum Einkellern des
Hauptspeicherinhalts[1] nötig ist.  Wenn nun
«/proc/sys/vm/overcommit_ratio» und «/proc/sys/vm/overcommit_kbytes»
auf 0 stehen, verwendet das System nie mehr virtuellen Speicher, als
Swapspace vorhanden ist. 

[1] Genaugenommen gibt es Hauptspeicherinhalte, die nicht im
Swapspace eingekellert werden müssen, beispielsweise Programmtexte
(denn die sind ja in der ausführbaren Programmdatei oder in
Programmbibliotheken bereits im Dateisystem) oder der buffer cache
(denn der kann jederzeit aus dem Dateisystem wieder neu geladen
werden). 

Die Formel für die maximale Nutzung virtuellen Speichers ist


Swap + overcommit_ratio/100 * RAM + 1024 * overcommit_kbytes

wobei immer nur eines von «/proc/sys/vm/overcommit_ratio» und
«/proc/sys/vm/overcommit_kbytes» ungleich 0 sein darf (siehe das
Handbuch «proc(5)»). 

In Deinem Fall bedeutet das, dass das System sich mit


2 GiB + 50/100 * 4 GiB + 1024 * 0 KiB = 4 GiB

virtuellen Speichers zufrieden gibt.


Wenn Du den Swapspace auf 4 GiB vergrößerst und
«/proc/sys/vm/overcommit_ratio» und «/proc/sys/vm/overcommit_kbytes»
auf 0 stellst, ist die Summe

4 GiB + 0/100 * 4 GiB + 1024 * 0 KiB = 4 GiB

virtuellen Speichers die gleiche, aber es ist garantiert, dass für
suspend to disk der ganze virtuelle Speicher in den Swapspace
passt. 

Ich meine, mal gelesen zu haben, dass Solaris (oder war es ein BSD?)
als Menge des verfügbaren virtuellen Speichers immer nur den
Swapspace in Betracht zieht und der RAM nicht in die Rechnung
eingeht. 

Daher kommt wohl auch die Empfehlung, (mindestens) so viel Swapspace
bereitzustellen, wie RAM eingebaut ist. 

Wenn der Swapspace mindestens so groß ist, dass der ganze verfügbare
virtelle Speicher reinpasst, hat das Betriebssystem auch die
Möglichkeit, jeden Virtuellspeicher‐Inhalt im RAM vorbeugend in den
Swapspace zu schreiben (etwa, wenn der betreffende Massenspeicher
gerade nichts anderes zu tun hat).  Sollte das Betriebssystem später
in die Lage kommen, Hauptspeicher für andere Verwendung frei
schaufeln zu wollen oder zu müssen, wäre das Herausschreiben des
augenblicklichen Inhalts möglicherweise (d. h., wenn er seit dem
letzten vorbeugenden Herausschreiben nicht mehr geändert wurde)
nicht mehr nötig, und es müssten nur noch die neuen Inhalte
hereingeholt werden:  Die Swapspace‐Nutzung wäre flinker. 

Ob Linux das tut, weiß ich nicht, denkbar wäre es aber. 

[Juergen Ilse]

Hallo,

Hermann Riemann <nosp...@hermann-riemann.de> wrote:
> Am 29.03.21 um 13:55 schrieb Juergen Ilse:
>> Georg Schwarz <georg....@freenet.de> wrote:
>>> Ist es heutzutage noch sinnvoll, für ein Desktopsystem mit 4 oder gar
>>> deutlich mehr GB an RAM eine Swappartition anzulegen?
>>
>> Bei aktuellen Kerneln hat eine Swapdatei im Filesystem keine wesentlichen
>> Nachteile mehr gegenueber einer Swap-Partition. Mit Swap-Dateien ist man
>> womoeglich flexibler, deswegen wuerde ich evt. Swwapdateien gegenueber
>> Swappartitionen vorziehen ...
>
> Einer Frage ist,ob die Verwaltung mit open, Dateiverlängerung und close
> einen erheblichen Zeitaufwand hat.

Ich meinte keine Swapdateien variabler Groesse (wie geht das denn mit
Linux? Das habe ich bisher bei Linux noch nie bewusst gesehen ...).

> Und dann gibt es noch die Frage, ob man die partition,
> in der die swap Datei liegt, frei wählen kann.

Zum Zeitpunkt des "swapon" muss die Partition r/w gemountet sein.
Das ist meines Wissens nach die einzige Bedingung.

>> Ich wuerde auf jeden Fall auch bei viel Speicher (nein 4 GB ist in
>> heutiger Zeit nicht so furchtbar viel Speicher) Swap einrichten.
>
> Wegen möglicher swap Benutzung ( z.B. bei scp -rp von ca 1TB )
> und suspend to disk würde ich doppelten RAM Speicherplatz empfehlen.

Ich habe sogar mal bis zu 8-fach Ram gefahren (auf einem Raspi4 mit 8GB
Ram), aber das war nur temporaer, weil compilieren und linken eines grossen
Software-Projekts bei 4 Jobs gleichzeitig u.U. bis mehr als 32 GB bei
parallelem Linken fressen konnte ... Es haette aber auch andere Loesungen
gegeben.

>> Nicht genutzter Swap frisst kein Brot,
> solange es auf dem "Lauf"werk nicht eng wird.

Bei "rotierendem Rost" sind heutzutaage die Groessen i.d.R. so, dass es
auf 64GB oder sogar 128GB Platz nicht unbedingt so sehr ankommen sollte ...

>> fehlender benoetigter Swap
>> fuehrt moeglicherweise zur unerwuenschten Beendigung von Prozessen ...
>
> Nicht unbedingt.

Wenn genug virtueller Speicher in Benutzung ist schon. Dann schlaegt bei
Li nux der "OOM Killer" zu.

> Ich habe mal ( vor Jahrzehnten) den swap abgeschaltet.
> Dann mittels eines C Programmes den meisten Speicher angefordert
> ( mit 0 belegt um ihn auch zu "benutzen" ) dann auf Eingabe gewartet.

Wenn noch etwas mehr benoetigt wuerde, haette vermutlich der OOM Killer
dennoch zugeschlagen. Abschalten von Swap vernindert nicht komplett das
auslagern von Speicher. Das "pagen" (auslagern von Programm-Code und
nachladen aus dem zugehoerigen binary) ist immer noch moeglich.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

Helmut Waitzmann <nn.th...@xoxy.net> wrote:
> Ich meine, mal gelesen zu haben, dass Solaris (oder war es ein BSD?)
> als Menge des verfügbaren virtuellen Speichers immer nur den
> Swapspace in Betracht zieht und der RAM nicht in die Rechnung
> eingeht. 

Bei Solaris 4 war das so (Solaris 4 war ein BSD) und zumindest bei alten
BSD-Versionen war es auch so. Ob es bei aktuellen BSD-Versionen noch so
ist, kann ich momentan nicht beantworten. Solaris 2.x war kein BSD mehr
sondern basierte auf SYSVR4. Wie dort die Speicherverwaltung implementiert
war bzw. ist, weiss ich nicht. Linux hatte IIRC auch mal eine Speicher-
verwaltung. die aehnlich wie die von aeelteren BSDs arbeitete. Im Laufe
der 2.4.x Kernel-Entwicklung wurde meines Wissens nach die Speicherverwal-
tung des Kernels mindestens einmal komplett ausgetauscht.

> Daher kommt wohl auch die Empfehlung, (mindestens) so viel Swapspace
> bereitzustellen, wie RAM eingebaut ist. 

Mindestens eine Empfehlung aus der damaligen Zeit lautete "Ram * 2" ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Christian Garbs]

Mahlzeit!

Arno Welzel <use...@arnowelzel.de> wrote:
> Marcus Jodorf:

>> Frage kann man schlicht nicht beantworten, solange man nicht weiß, wie
>> der Rechner benutzt wird.
>
> Oder genauer: es kommt darauf an, ob das RAM alleine für die Anwendungen
> ausreicht.

Nicht nur. Linux lagert ja auch schon präventiv länger nicht mehr
benutzte Dinge in den Swap aus. Das kann dazu führen, dass Du,
solange der ausgelagerte Kram nicht wieder benötigt wird, mehr Platz
für Buffer und Caches hast. Selbst, wenn Du von der Gesamtmenge des
angeforderten Speichers keinen Swap brauchst, könnte das System mit
Swap eine höhere Schwubbdizität besitzen.

Aber hier geht es um Optimierung, also: selber ausprobieren und messen :-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Glaube nicht alles, was im Internet steht.
--Abraham Lincoln

[Andreas Kohlbach]

On Thu, 01 Apr 2021 15:02:47 +0200, Helmut Waitzmann wrote:
>
> Andreas Kohlbach <a...@spamfence.net>:

[...]

> Die Formel für die maximale Nutzung virtuellen Speichers ist
>
>
> Swap + overcommit_ratio/100 * RAM + 1024 * overcommit_kbytes
>
> wobei immer nur eines von «/proc/sys/vm/overcommit_ratio» und
> «/proc/sys/vm/overcommit_kbytes» ungleich 0 sein darf (siehe das
> Handbuch «proc(5)»). 
>
> In Deinem Fall bedeutet das, dass das System sich mit
>
>
> 2 GiB + 50/100 * 4 GiB + 1024 * 0 KiB = 4 GiB
>
> virtuellen Speichers zufrieden gibt.
>
>
> Wenn Du den Swapspace auf 4 GiB vergrößerst und
> «/proc/sys/vm/overcommit_ratio» und «/proc/sys/vm/overcommit_kbytes»
> auf 0 stellst, ist die Summe
>
> 4 GiB + 0/100 * 4 GiB + 1024 * 0 KiB = 4 GiB
>
> virtuellen Speichers die gleiche, aber es ist garantiert, dass für
> suspend to disk der ganze virtuelle Speicher in den Swapspace
> passt. 

Dank meiner kaputten Partitionstabelle (ver)schiebe (vergrößere) ich da
nichts. Auch schon über ein Jahr her dank der anhaltenden Krise, dass ich
das Laptop mit raus nahm und in Suspend (to RAM) brachte.

> Ich meine, mal gelesen zu haben, dass Solaris (oder war es ein BSD?)
> als Menge des verfügbaren virtuellen Speichers immer nur den
> Swapspace in Betracht zieht und der RAM nicht in die Rechnung
> eingeht. 
>
> Daher kommt wohl auch die Empfehlung, (mindestens) so viel Swapspace
> bereitzustellen, wie RAM eingebaut ist. 

IIRC hörte ich vor Jahrzehnten schon, mindestens doppelt soviel SWAP wie
RAM haben zu sollen. Gilt vielleicht nicht mehr.
--
Andreas

[Claus Reibenstein]

Juergen Ilse schrieb am 01.04.2021 um 15:20:

> Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>
> Ich meinte keine Swapdateien variabler Groesse (wie geht das denn mit
> Linux? Das habe ich bisher bei Linux noch nie bewusst gesehen ...).

Dann installiere mal Linux ohne Swappartition und wirf anschließend
einen Blick in /etc/fstab.

Gruß
Claus

[Stefan Möding]

Außerdem braucht man mindestens diesen Platz, wenn man kernel crash dumps
nutzen will. Bei einer Kernel Panic wird der komplette RAM in den Swap
Space geschrieben und dann beim nächsten Booten als Datei nach /var/crash
kopiert. Damit konnte man mit dem Debugger post mortem die Ursache für den
Crash ermitteln. Natürlich nur, wenn Swap und /var groß genug waren...

> IIRC hörte ich vor Jahrzehnten schon, mindestens doppelt soviel SWAP wie
> RAM haben zu sollen. Gilt vielleicht nicht mehr.

IMHO stammt das alles noch aus der Zeit, als 50 Leute sich eine Maschine
mit 8 oder 12 Megabytes geteilt haben. Swapping gehörte da einfach dazu,
weil mehr RAM entweder zu teuer war oder die Hardware schon den Vollausbau
erreicht hatte.

--
Stefan

[Andreas Kohlbach]

On Thu, 01 Apr 2021 17:36:17 +0200, Stefan Möding wrote:

>
> Andreas Kohlbach <a...@spamfence.net> writes:
>
>> IIRC hörte ich vor Jahrzehnten schon, mindestens doppelt soviel SWAP wie
>> RAM haben zu sollen. Gilt vielleicht nicht mehr.
>
> IMHO stammt das alles noch aus der Zeit, als 50 Leute sich eine Maschine
> mit 8 oder 12 Megabytes geteilt haben. Swapping gehörte da einfach dazu,
> weil mehr RAM entweder zu teuer war oder die Hardware schon den Vollausbau
> erreicht hatte.

Du erinnerst mich gerade an 1997, als ich mein erstes Linux
installierte. Satte 24 MB [1] (nicht GB) RAM und eine riesige 1,3 GB
(nicht TB) große Festplatte, auf der Windows95 schon rund 800 MB
brauchte.

[1] Original kam der Computer mit 8 MB RAM, konnte ich "für wenig Geld"
(IIRC 199 DM) auf 16 MB aufrüsten. Habe um 1999 später einen weiteren 16
MB Riegel erworben, als die Preise "niedriger" waren und der "nur" weitere
199 DM kostete. Waren IIRC 2 nur RAM Slots drin, die mit je 4 MB (also 8)
belegt waren, dass ich mit dem neuen 16er auf 24 MB (statt der
gewünschten 32) kam.

IIRC hatte ich laut der (2 * RAM) Regel am Anfang 32 MB SWAP Space
angelegt. Bei den noch 500 MB Festplattenplatz (1300 - 800 für Windows)
taten 32 MB SWAP schon weh, die Linux selbst nicht mehr haben
konnte. "Gut", dass eh kein Platz für eine GUI war, dass Linux (ganz im
Gegensatz zu Windows, was ständig mit dem Auslagern beschäftigt war)
flüssig lief.
--
Andreas

[Marcel Mueller]

Am 01.04.21 um 17:17 schrieb Marcus Jodorf:
> Marcel Mueller <news.5...@spamgourmet.org> schrieb:
>

>> War das wirklich nur den Platten geschuldet?
>

> War zumindest ein Hauptgrund. Weil ein Swapfile kann auch fragmentiert
> sein und Zugriffszeiten schlagen nun mal bei Platten durch.

Ich hätte gesagt, das ist bei swap egal, weil die Zugriffe auf den
Inhalt ohnehin stakt fragmentiert sind. Da wird oft in 4k Häppchen
gelesen. Das ist es fast egal, ob die Datei fragmentiert ist.

> Zudem haben Platten meist unterschiedlich schnelle Zonen.

Das ist bei swap auch egal, denn 10 MB am Stück, wo das relevant wäre,
liest da auch keiner.

> Swap hat man daher auch mal gerne in eine Partition z.B. in der Mitte einer
> Platte gelegt, um die Zugriffszeiten im Durchschnitt zu optimieren und

Das ist tatsächlich ein Aspekt, der anders nur schwer zu erreichen ist.

>> Mir war irgendwie, dass der Zugriffspfad über das Dateisystem früher
>> nicht sonderlich effizient implementiert war. Ich meine, das ist ja
>> auch nicht trivial. Page Faults können in allen möglichen Kontexten
>> auftreten.
>

> Da ist sicherlich auch optimiert worden. Aber Platten haben nun mal auch
> ihre ganz speziellen Charakteristiken. Gerade wenn es als Medium schon
> langsamer Swap ist, will man das wenigstens vielleicht besonders optimal
> nutzen.
> Mit SSD stellen sich aber solche Fragen eigentlich nicht mehr.

Ich hatte da eher sowas wie die berüchtigten BKLs in Erinnerung. Aber
ich kann mich auch irren.


Marcel

[Marcel Mueller]

Am 31.03.21 um 23:10 schrieb Helmut Waitzmann:

> Marcel Mueller <news.5...@spamgourmet.org>:
>
>> Swap brauchst du immer.
>> 1. wegen Overcommitment
>
> Wenn ich mir im Handbuch «proc(5)» die Abschnitte zu
> «/proc/sys/vm/overcommit_memory» einerseits und
> «/proc/sys/vm/overcommit_ratio» und «/proc/sys/vm/overcommit_kbytes»
> andererseits ansehe, erkenne ich da zwei verschiedene Bedeutungen von
> memory overcommitment:  In der ersten bedeutet es, das System sich über
> die Menge des freien virtuellen Speichers in die Tasche lügen zu
> lassen.  In der zweiten beantwortet es die Frage, ob zum für virtuellen
> Speicher verwendbaren Speicher zusätzlich zur Größe des Swapspaces auch
> Anteile der Größe des Hauptspeichers gerechnet werden sollen.

Du meinst den physischen Speicher, oder?
Virtuellen gibt es nur pro Prozess.

> Auf welche Bedeutung hebst Du mit

AFAIK gehören die zwei Settings zusammen. Das erste ist ein Schalter,
das zweite eine Feineinstellung.

>> 2. für Suspend to Disk
>
> Genau:  Bei Suspend to Disk muss alles, was im Hauptspeicher sitzt, im
> Massenspeicher untergebracht werden (oder sein), weil dem Hauptspeicher
> der Strom abgestellt werden wird.  Wenn «/proc/sys/vm/overcommit_ratio»
> und «/proc/sys/vm/overcommit_kbytes» auf 0 stehen, ist diese
> Voraussetzung stets gegeben.  Dazu muss allerdings genügend Swapspace
> vorhanden sein.

Ja, und zwar /zusätzlich/. Es muss ja zu den bereits ausgelagerten
Seiten auch noch der RAM-Inhalt rein, abzüglich der aktuell doppelt
vorhandenen Seiten. Allerdings werden die Suspend-Images komprimiert.
Insofern muss es nicht die Summe sein.
Und RAM-Inhalte lassen sich sehr gut komprimieren, solange sie nicht
verschlüsselt sind. Ein Faktor 2 ist da schon drin. Es kann aber auch
mal Faktor 5 werden. Und wenn das nicht reicht, kann man auch noch
Cache-Pages verwerfen.


Marcel

[Helmut Waitzmann]

Hermann Riemann <nosp...@hermann-riemann.de>:

>Wegen möglicher swap Benutzung ( z.B. bei scp -rp von ca 1TB )
>

[…]

>würde ich doppelten RAM Speicherplatz empfehlen.
>

Das überrascht mich jetzt.  Ich hätte erwartet, dass «scp» nicht
besonders speicherhungrig ist:  Ein Datenblock wird gelesen,
komprimiert, verschlüsselt und über die Leitung geschickt.  Dann
kommt der nächste an die Reihe; dabei braucht man für den vorigen
keinen virtuellen Speicher mehr.  Beim empfangenden Ende geschieht
entsprechendes umgekehrt.  Die Datenblöcke müssen ja nicht viele MB
groß sein. 

[Hermann Riemann]

Am 01.04.21 um 18:34 schrieb Helmut Waitzmann:

Vor dem scp waren vielleicht 2 von 16 oder 32 GB belegt.
Irgendwann habe ich per top gesehen,
dass das meiste RAM belegt ist und swap verwendet wird.

Die Speicherverwaltung weiß vermutlich nicht,
wofür der Speicher verwendet wird.
Wenn er als Kriterium zum Auslagern die letzte Verwendung benutzt wird,
und die Verwendung einer eingelesenen Datei nicht bekannt ist,
könnte der Speicher eines Editors ausgelagert werden.

Hermann
nicht sicher ob scp Speicher zum Wiederverwenden freigeben kann,
bevor scp zu Ende ist.

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 01.04.21 um 17:50 schrieb Andreas Kohlbach:

> Du erinnerst mich gerade an 1997, als ich mein erstes Linux
> installierte. Satte 24 MB [1] (nicht GB) RAM und eine riesige 1,3 GB
> (nicht TB) große Festplatte, auf der Windows95 schon rund 800 MB
> brauchte.

Mein erstes Linux habe ich 1994 installiert.
8 MB RAM 80 MB Syquest Wechselplatte, 386 AMD CPU,
vielleich Tseng Grafikkarte.
( Eine Scheibe für DR-DOS, eine für OS/2 und eine für Linux 0.999 )

> [1] Original kam der Computer mit 8 MB RAM,

Aus Einzelteile selber zusammengesteckt.
Wenn ich da in einem laden in der Münchner Schillerstr. Linux rief,
wurde noch nach jemand, der Linux kannte, gesucht.

> "Gut", dass eh kein Platz für eine GUI war, dass Linux (ganz im
> Gegensatz zu Windows, was ständig mit dem Auslagern beschäftigt war)
> flüssig lief.

GUI mit Linux ( kein KDE nur X) kam später mit SuSE 4.2.
Kein Problem mit der Grafikeinstellung dank sax,

Hermann
der öfter den Eindruck hat,
das eine Linux Installation
auf leerem PC heutzutage schwieriger ist

--
http://www.hermann-riemann.de

[Helmut Waitzmann]

Marcel Mueller <news.5...@spamgourmet.org>:

>Am 31.03.21 um 23:10 schrieb Helmut Waitzmann:
>> Marcel Mueller <news.5...@spamgourmet.org>:
>>
>>> Swap brauchst du immer.
>>>
>>> 1. wegen Overcommitment
>>>
>>
>> Wenn ich mir im Handbuch «proc(5)» die Abschnitte zu
>> «/proc/sys/vm/overcommit_memory» einerseits und
>> «/proc/sys/vm/overcommit_ratio» und «/proc/sys/vm/overcommit_kbytes»
>> andererseits ansehe, erkenne ich da zwei verschiedene Bedeutungen
>> von memory overcommitment:  In der ersten bedeutet es, das System
>> sich über die Menge des freien virtuellen Speichers in die Tasche
>> lügen zu lassen.  In der zweiten beantwortet es die Frage, ob zum
>> für virtuellen Speicher verwendbaren Speicher zusätzlich zur Größe
>> des Swapspaces auch Anteile der Größe des Hauptspeichers gerechnet
>> werden sollen.
>
>Du meinst den physischen Speicher, oder?
>
>Virtuellen gibt es nur pro Prozess.
>

Ich meine den Speicher, den das System zur Verfügung hat, um ihn
zuzuteilen.  Das Handbuch «proc(5)» nennt ihn «total virtual address
space that can be allocated». 

>> Auf welche Bedeutung hebst Du mit
>>
>
>AFAIK gehören die zwei Settings zusammen. Das erste ist ein
>Schalter, das zweite eine Feineinstellung.
>

In «proc(5)» steht dazu (hier mit «|» am Zeilenanfang markiert), mit
unmarkierten Zwischenfragen oder ‐kommentaren von mir: 

| /proc/sys/vm/overcommit_memory
| This file contains the kernel virtual memory
| accounting mode. Values are:
|
| 0: heuristic overcommit (this is the default)
| 1: always overcommit, never check
| 2: always check, never overcommit
|
| In mode 0, calls of mmap(2) with MAP_NORESERVE are
| not checked, and the default check is very weak,
| leading to the risk of getting a process "OOM-
| killed".

In der Betriebsart 0 winkt Linux also Speicheranforderungen des Typs
«MAP_NORESERVE» eines Prozesses einfach durch, ohne dafür Speicher
zu reservieren.  Dadurch kann es dann, wenn der Prozess später
tatsächlich auf den Speicher zugreifen will, passieren, dass kein
Speicher dafür vorhanden ist.  Dann schickt Linux den Sensenmann
oder bekommt Panik, abhängig davon, was in
«/proc/sys/vm/panic_on_oom» eingestellt ist. 

|
| In mode 1, the kernel pretends there is always
| enough memory, until memory actually runs out.

«Memory actually runs out»:  Wann tritt das ein?  Was zählt zum
vorhandenen Speicher?  RAM?  Swapspace?  Die Summe von beiden?  Oder
ist es die Berechnungsmethode, die weiter unten bei der Betriebsart
2 beschrieben wird? 

| One use case for this mode is scientific computing
| applications that employ large sparse arrays. In Linux
| kernel versions before 2.6.0, any nonzero value implies
| mode 1.
|
| In mode 2 (available since Linux 2.6), the total
| virtual address space that can be allocated
| (CommitLimit in /proc/meminfo) is calculated as
|
| CommitLimit = (total_RAM - total_huge_TLB) *
| overcommit_ratio / 100 +
| total_swap
|
| where:
|
| * total_RAM is the total amount of RAM on the
| system;
|
| * total_huge_TLB is the amount of memory set
| aside for huge pages;
|
| * overcommit_ratio is the value in
| /proc/sys/vm/overcommit_ratio; and
|
| * total_swap is the amount of swap space.
|
| For example, on a system with 16GB of physical RAM,
| 16GB of swap, no space dedicated to huge pages, and
| an overcommit_ratio of 50, this formula yields a
| CommitLimit of 24GB.
|
| Since Linux 3.14, if the value in
| /proc/sys/vm/overcommit_kbytes is nonzero, then
| CommitLimit is instead calculated as:
|
| CommitLimit = overcommit_kbytes + total_swap
|
| See also the description of
| /proc/sys/vm/admiin_reserve_kbytes and
| /proc/sys/vm/user_reserve_kbytes.

Die Begriffe heißen da «overcommit_ratio» und «overcommit_kbytes»,
obwohl sie in der Betriebsart 2 nicht dazu führen, dass sich Linux
über die Menge des zuteilbaren Speichers in die Tasche lügt. 

>
>>> 2. für Suspend to Disk
>>>
>>
>> Genau:  Bei Suspend to Disk muss alles, was im Hauptspeicher
>> sitzt, im Massenspeicher untergebracht werden (oder sein), weil
>> dem Hauptspeicher der Strom abgestellt werden wird.  Wenn
>> «/proc/sys/vm/overcommit_ratio» und
>> «/proc/sys/vm/overcommit_kbytes» auf 0 stehen, ist diese
>> Voraussetzung stets gegeben.  Dazu muss allerdings genügend
>> Swapspace vorhanden sein.
>
>Ja, und zwar /zusätzlich/. Es muss ja zu den bereits ausgelagerten
>Seiten auch noch der RAM-Inhalt rein, abzüglich der aktuell doppelt
>vorhandenen Seiten. Allerdings werden die Suspend-Images
>komprimiert. Insofern muss es nicht die Summe sein.
>Und RAM-Inhalte lassen sich sehr gut komprimieren, solange sie
>nicht verschlüsselt sind. Ein Faktor 2 ist da schon drin. Es kann
>aber auch mal Faktor 5 werden. Und wenn das nicht reicht, kann man
>auch noch Cache-Pages verwerfen.

Danke für die Ergänzungen. 

[Juergen Ilse]

Hallo,

Und? Welche Geheimnisse offenbart die fstab in dem Fall?
Ich hatte im RaspiOS mal irgend einen komischen Daeon gesehen, der mir
immer wieder einen Swapbereich auf der sdcard angelegt hat (wo ich keinen
Swap haben wollte), also habe ich den Mist dann deaktiviert und eine
feste Swap-Datei auf der USB3 Platte angelegt. Wie sieht deiner Meinung
nach ein Eintrag fuer eine dynamische Swap-Datei in der fstab aus?

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Marcel Mueller <news.5...@spamgourmet.org> wrote:
> Am 01.04.21 um 17:17 schrieb Marcus Jodorf:

>> Zudem haben Platten meist unterschiedlich schnelle Zonen.
>
> Das ist bei swap auch egal, denn 10 MB am Stück, wo das relevant wäre,
> liest da auch keiner.
>
>> Swap hat man daher auch mal gerne in eine Partition z.B. in der Mitte einer
>> Platte gelegt, um die Zugriffszeiten im Durchschnitt zu optimieren und
>
> Das ist tatsächlich ein Aspekt, der anders nur schwer zu erreichen ist.

Bei modernen Platten hat man i.d.R. keine Informationen mehr darueber,
welche logischen Plattensektoren wo auf der pjasilalischen Platte liegen.
Das ist auch schon seit vielen Jahren so.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

Andreas Kohlbach <a...@spamfence.net> wrote:
> Du erinnerst mich gerade an 1997, als ich mein erstes Linux
> installierte. Satte 24 MB [1] (nicht GB) RAM und eine riesige 1,3 GB
> (nicht TB) große Festplatte, auf der Windows95 schon rund 800 MB
> brauchte.

Mein erstes Linux hatte seinen Platz (zusammen mit ca. 40 MB fuer DOS und
Windows 3.1) auf einer 105 MB NEC Platte, in einem Rechner mit 386DX
CPU und 8 MB Ram in Form von 72 einzelnen ICs in "Kombisockeln" in die
unterschiedliche Ramchips hineinpassten (je nach Chip-Tp konnte man das
Board mit bis zu 2 MB oder bis zu 8 MB Ram bestuecken). Ach ja, zu einem
80387 hatte es damals noch nicht gereicht ...
Dieses erste Linux wurde noch von 5 1/4 " Disketten installiert, es handelte
sich um eine SLS Distribution, damals mit Kernel 0.98PL4 Kernel, den ich
kurze Zeit spaeter auf eien damals brandneuen 0.98PL& Kernel upgedated hatte.
Damals gab es noch das Tools "psupdate", dass die Adressen der Kernel-
strukturen im Ram heraussuchte und in eine Datei schrieb, die dann von "ps"
und Konsorten ausgewertet wurde, um PIDs und andere Informationen direkt aus
dem Kernel-Adressraum zu lesen (weil ein Prozessfilesstem gab es noch nicht).
Bei jedem Kernel musse dann einmal "psupdate" (als root) ausgefuehrt werden.
damit das System wie erwartet funktionierte (einschliesslich Tools wie "ps",
"top" und aehnlichen) ...

> [1] Original kam der Computer mit 8 MB RAM, konnte ich "für wenig Geld"
> (IIRC 199 DM) auf 16 MB aufrüsten.

Das Mainboard meines ersten Linux-Rechners war mit den 8MB schon voll
bestueckt. Das Mainboard hatte eine Groesse, die wohl in heute uebliche
Gehaeuse beim besten Willen nicht mehr hineinpassen wuerde.

Das muss damals so um 1993 gewesen sein (genauer weiss ich das Datum nicht
mehr, aber oeglicherweise liesse es sich anhand der Kernel- Versionen naeher
eingrenzen...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Helmut Waitzmann]

Hermann Riemann <nosp...@hermann-riemann.de>:

>Am 01.04.21 um 18:34 schrieb Helmut Waitzmann:

>> Das überrascht mich jetzt.  Ich hätte erwartet, dass «scp» nicht
>> besonders speicherhungrig ist:  Ein Datenblock wird gelesen,
>> komprimiert, verschlüsselt und über die Leitung geschickt.  Dann
>> kommt der nächste an die Reihe; dabei braucht man für den vorigen
>> keinen virtuellen Speicher mehr.  Beim empfangenden Ende
>> geschieht entsprechendes umgekehrt.  Die Datenblöcke müssen ja
>> nicht viele MB groß sein.
>
>Vor dem scp waren vielleicht 2 von 16 oder 32 GB belegt.
>
>Irgendwann habe ich per top gesehen, dass das meiste RAM belegt ist
>und swap verwendet wird.

Schau Dir mal im Handbuch «proc(5)» die Datei
«/proc/sys/vm/swappiness» und den historischen Artikel
<https://lwn.net/Articles/83588/> an.  In die Datei kann ein
ganzzahliger Wert zwischen 0 und 100 geschrieben werden. 
Voreingestellt ist 60. 

Bei relativ hohen Werten kann es durchaus sein, dass das
Betriebssystem Speicherseiten eines Prozesses, der gerade nicht
läuft, in den Swapspace auslagert, um Platz für den buffer cache im
Hauptspeicher zu erhalten. 

Irgendwo anders habe ich mal gelesen, dass in späteren
Kernelversionen der Wert 0 dazu führt, dass Prozessspeicher
überhaupt nicht mehr ausgelagert wird und deshalb dem Betriebssystem
der Hauptspeicher insgesamt ausgehen kann, obwohl es noch freien
Swapspace hat.  Die Empfehlung war da, nicht unter den Wert 1 zu
gehen. 

>Die Speicherverwaltung weiß vermutlich nicht, wofür der Speicher
>verwendet wird.

Das nehme ich auch an. 

>Wenn er als Kriterium zum Auslagern die letzte Verwendung benutzt
>wird, und die Verwendung einer eingelesenen Datei nicht bekannt
>ist, könnte der Speicher eines Editors ausgelagert werden.

Das kann passieren, ja.  Aber wem Prozess‐Speicher‐Seiten heiliger
sind als buffer cache, der kann «/proc/sys/vm/swappiness» auf kleine
Werte setzen. 

Zum Weiterlesen (neuere Dokumente sind mir nicht bekannt):

<https://www.win.tue.nl/~aeb/linux/lk/lk-9.html>
<https://linux-mm.org/Low_On_Memory>
<https://www.kernel.org/doc/gorman/html/understand/index.html>



[Hermann ist sich]

>nicht sicher ob scp Speicher zum Wiederverwenden freigeben kann,
>bevor scp zu Ende ist.

Wenn «scp» korrekt programmiert ist, also den angeforderten Speicher
nicht einfach vergisst – schließlich gibt es in der
Laufzeitbibliothek neben der Funktion «malloc» auch die Funktion
«free» –, sondern an die Laufzeitumgebung zurückgibt, sollte das
geschehen. 

[Juergen Ilse]

Hallo,

Helmut Waitzmann <nn.th...@xoxy.net> wrote:

> Hermann Riemann <nosp...@hermann-riemann.de>:
>>Am 01.04.21 um 18:34 schrieb Helmut Waitzmann:
>
>>> Das überrascht mich jetzt.  Ich hätte erwartet, dass «scp» nicht
>>> besonders speicherhungrig ist:  Ein Datenblock wird gelesen,
>>> komprimiert, verschlüsselt und über die Leitung geschickt.  Dann
>>> kommt der nächste an die Reihe; dabei braucht man für den vorigen
>>> keinen virtuellen Speicher mehr.  Beim empfangenden Ende
>>> geschieht entsprechendes umgekehrt.  Die Datenblöcke müssen ja
>>> nicht viele MB groß sein.
>>
>>Vor dem scp waren vielleicht 2 von 16 oder 32 GB belegt.
>>
>>Irgendwann habe ich per top gesehen, dass das meiste RAM belegt ist
>>und swap verwendet wird.
>
> Schau Dir mal im Handbuch «proc(5)» die Datei
> «/proc/sys/vm/swappiness» und den historischen Artikel
> <https://lwn.net/Articles/83588/> an.  In die Datei kann ein
> ganzzahliger Wert zwischen 0 und 100 geschrieben werden. 
> Voreingestellt ist 60. 

Eine erheblich bessere Erklaerung findet man meiner Ansicht nach hier:
https://www.howtogeek.com/449691/what-is-swapiness-on-linux-and-how-to-change-it/

> Bei relativ hohen Werten kann es durchaus sein, dass das
> Betriebssystem Speicherseiten eines Prozesses, der gerade nicht
> läuft, in den Swapspace auslagert, um Platz für den buffer cache im
> Hauptspeicher zu erhalten. 

Laut dem von mir genannten Artikel beeinflusst die "swappiness" die Auswahl,
was fuer Speicherseiten bei Bedarf im Ram freigeschaufelt werden: Programm-
code wird i.d.R. nicht in den Swap geschrieben, sondern aus dem gerade aus-
gefuehrten binary wieder nachgeladen ("paging"), Speicherseten, die nicht aus
dem programmbinary nachgeladen werden koennen (weil sie im binary nicht exis-
tieren, z.B. weil sie erst zur Laufzeit alloziert wurden, oder weil sie
gegenueber dem entsprechenden Bereich im binary veraendert wuden) werden zum
auslagern in den Swapspace geschrieben, so es solchen gibt.Die "swappiness"
beeinflusst die Auswahl auszulagernder Speicherseiten (also das Verhaeltnis
zwischen "swapping" und "paging"). Zumindest ist das wohl bei hinreichend
aktuellen Kerneln so (die Speicherverwaltung im Kernel hat sich ja im Verlauf
der Entwicklung mehrfach komplett geaendert).


Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marcel Mueller]

Am 02.04.21 um 12:18 schrieb Juergen Ilse:

> Marcel Mueller <news.5...@spamgourmet.org> wrote:
>> Am 01.04.21 um 17:17 schrieb Marcus Jodorf:

>>> Swap hat man daher auch mal gerne in eine Partition z.B. in der Mitte einer
>>> Platte gelegt, um die Zugriffszeiten im Durchschnitt zu optimieren und
>>
>> Das ist tatsächlich ein Aspekt, der anders nur schwer zu erreichen ist.
>
> Bei modernen Platten hat man i.d.R. keine Informationen mehr darueber,
> welche logischen Plattensektoren wo auf der pjasilalischen Platte liegen.
> Das ist auch schon seit vielen Jahren so.

Theoretisch ja. Praktisch funktioniert Short-Stroke nach wie vor in fast
allen Fällen.

Es gab AFAIK nur eine Festplattenserie, die es mal anders gemacht hat.
Da lagen die Daten unterschiedlicher Köpfe (Oberflächen) in den
LBA-Nummern weit auseinander. Ich glaube, es war irgendeine alte
Travelstar. Die hat erst alle Blöcke einer Oberfläche von außen nach
innen genutzt, und dann die Blöcke auf der nächsten Oberfläche von innen
nach außen.
Mutmaßlich war die Kopfwechselzeit etwas größer als die Spurwechselzeit
zur Nachbarspur. Das ist gar nicht so abwegig, wenn man bedenkt, dass
immer nur ein Kopf über der aktuellen Spur gehalten werden kann. Die
anderen sind durch Toleranzen und thermische Ausdehnung zuweilen mehrere
Spuren daneben, gerade in den äußeren, schnellen Zonen.


Marcel

[Marc Haber]

Das Ergebnis ist wenig überraschend abhängig vom verwendeten
Installer. IIRC wird z.B. der Debian-Installer eher zickig wenn man
versucht ein System ohne Swap zu installieren versucht.

Nachträlich bauen und betreiben kann man alles in beliebigen
Kombinationen.

|[4/4996]mh@torres:~ $ sudo swapon --summary
|Filename Type Size Used Priority
|/dev/dm-5 partition 4194300 82176 -2
|[5/4997]mh@torres:~ $

Komplizierteres habe ich leider nicht; auf den zwei Systemen, auf
denen ich ein Swapfile vermutet hatte, hatte ich auch nur eine
Partition und eine LV.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marc Haber]

Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>Die Speicherverwaltung weiß vermutlich nicht,
>wofür der Speicher verwendet wird.

Die weiß das besser als Du.

> nicht sicher ob scp Speicher zum Wiederverwenden freigeben kann,
> bevor scp zu Ende ist.

Das ist ja auch nicht wichtig.

[Marc Haber]

Beide dieser Empfehlungen gehören zu den Märchen, die seit mehr als
zehn Jahren technisch überholt sind, aber nicht totzubekommen sind.

Legt man Wert auf Suspend-to-Disk, sind die Anforderungen direkt
nochmal anders, weil ja sowohl der Inhalt des Swap als auch das RAM
weggeschrieben werden muss. Die Anforderungen kenne ich aber nicht,
meine Server gehen nicht schlafen und die Desktops müssen nur
Suspend-to-RAM können.

Grüße
Marc

[Christian Garbs]

Mahlzeit!

Laut mkswap(8) wird die swap area auf die Große der zugeordneten Datei
bzw. Partition gesetzt, d.h. eine Swapdatei müsste man vor dem Aufruf
von mkswap mit einer bestimmten Größe anlegen.

Ich kann mir nicht vorstellen, dass sich von dieser Swapdatei
nachträglich dynamisch die Größe ändern lässt.
Wie sieht sowas denn in der fstab aus?

(Swap in Datei mit fester Größe ist klar, aber hier war die Frage nach
variabler Größe.)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Die Kunst der Optimierung von Microsoft-Programmen besteht darin, sämtliche
Neuerungen und Automatisierungsmechanismen abzuschalten, um den Programm-
umfang möglichst nahe an der Vorgängerversion zu halten. (C. Garbs)

[Christian Garbs]

Mahlzeit!

Hermann Riemann <nosp...@hermann-riemann.de> wrote:

> Und dann gibt es noch die Frage, ob man die partition,
> in der die swap Datei liegt, frei wählen kann.

Ja. Eine Swapdatei liegt als Datei im Dateisystem, wie andere Dateien
auch. Die Nutzung von "komischen" Dateisystemen (NFS, tmpfs, …) ist
dabei – falls sie möglich ist (ich hab's nicht ausprobiert) –
natürlich nicht sinnvoll.

> Ich lege meine swap partition auf HD statt auf SSD,
> weil ich sonst wegen endlicher Überschreibzahl Nebeneffekte vermute.

Wenn Du nicht dauerhaft am Swappen bist, sollte sich das nicht
bemerkbar machen. (Falls doch: mehr RAM kaufen.) Gerade Swap will
man im Falle des Falles doch möglichst schnell haben, …

> Ein weiter Variante war ca 20% der Festplatte als swap einzurichten,
> und es dann von gleichartigem C Programm zu benutzen.
> Es gab da große Wartezeiten.
> Fazit, swap Benutzung ist bei zeitkritischem Verwendung
> nicht empfehlenswert.

…weil sonst genau sowas passiert.

> vermutend, das er swap für eigene Programme so lange
> nicht benötigen wird, wie swap vorhanden ist.

Weise Worte :-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

"Heisenberg may have slept here"

[Christian Garbs]

Mahlzeit!

Hermann Riemann <nosp...@hermann-riemann.de> wrote:

> Vor dem scp waren vielleicht 2 von 16 oder 32 GB belegt.
> Irgendwann habe ich per top gesehen,
> dass das meiste RAM belegt ist und swap verwendet wird.

Bist Du Dir sicher, dass das "used" memory war oder nicht eher
"buffers" und "caches"?

> Die Speicherverwaltung weiß vermutlich nicht,
> wofür der Speicher verwendet wird.

Zumindest die Unterscheidung "used"/"buffers"/"caches" kann sie.

> Wenn er als Kriterium zum Auslagern die letzte Verwendung benutzt wird,
> und die Verwendung einer eingelesenen Datei nicht bekannt ist,
> könnte der Speicher eines Editors ausgelagert werden.

Wobei dabei zu unterscheiden ist zwischen dem Speicher, den scp
tatsächlich benutzt und dem, was der Kernel in buffers/caches geparkt
hat. Da kommt dann die schon genannte swappiness zum Tragen.

> nicht sicher ob scp Speicher zum Wiederverwenden freigeben kann,
> bevor scp zu Ende ist.

Das könnte man im Quellcode nachgucken, aber prinzipiell braucht scp
das eigentlich nicht. Wenn eine Datei übertragen wird, dann wird ja
Stück für Stück von der Platte gelesen, verschlüsselt und dann übers
Netzwerk verschickt (oder genau andersherum) – dabei ist der
Speicherbedarf konstant, den oder die Speicherbereiche kann man
während der gesamten Übertragung wiederverwenden, da muss ja immer nur
ein Stück der Datei reinpassen.

Im Hintergrund schreibt oder liest der Kernel natürlich die gesamte
Datei und packt sie dabei in den systemweiten buffer/cache. Ich
vermute, dass Du genau das beobachtet hast, als Du meintest, scp
frisst allen Speicher. Derartig belegter Speicher ist aber sofort
wieder frei, falls er für was "richtiges" benötigt wird.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Man is the Only Animal that Blushes. Or needs to.
- Mark Twain

[Helmut Waitzmann]

Juergen Ilse <ne...@usenet-verwaltung.de>:

>Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>> Hermann Riemann <nosp...@hermann-riemann.de>:
>>>Am 01.04.21 um 18:34 schrieb Helmut Waitzmann:

>> Schau Dir mal im Handbuch «proc(5)» die Datei
>> «/proc/sys/vm/swappiness» und den historischen Artikel
>> <https://lwn.net/Articles/83588/> an.  In die Datei kann ein
>> ganzzahliger Wert zwischen 0 und 100 geschrieben werden. 
>> Voreingestellt ist 60. 
>
>Eine erheblich bessere Erklaerung findet man meiner Ansicht nach
>hier:
>https://www.howtogeek.com/449691/what-is-swapiness-on-linux-and-how-to-change-it/

Das scheint mir etwas neueres zu sein, als das, was ich in meinen
Bookmarks stehen habe.  Danke. 

>> Bei relativ hohen Werten kann es durchaus sein, dass das
>> Betriebssystem Speicherseiten eines Prozesses, der gerade nicht
>> läuft, in den Swapspace auslagert, um Platz für den buffer cache
>> im Hauptspeicher zu erhalten. 
>
>Laut dem von mir genannten Artikel beeinflusst die "swappiness" die
>Auswahl, was fuer Speicherseiten bei Bedarf im Ram freigeschaufelt
>werden: Programm- code wird i.d.R. nicht in den Swap geschrieben,
>sondern aus dem gerade aus- gefuehrten binary wieder nachgeladen
>("paging"),

Ja.  Und dasselbe gilt für weitere Hauptspeicherinhalte, die ihr
Gegenstück im Dateisystem haben, etwa Dateiinhalte, wobei
Programmcode (der nicht geändert wird) und Dateien, die nur gelesen
wurden, noch den Vorteil haben, dass sie beim Rauswerfen aus dem
Hauptspeicher nicht erst noch geschrieben werden. 

>Speicherseten, die nicht aus dem programmbinary nachgeladen werden
>koennen (weil sie im binary nicht exis- tieren, z.B. weil sie erst
>zur Laufzeit alloziert wurden, oder weil sie gegenueber dem
>entsprechenden Bereich im binary veraendert wuden) werden zum
>auslagern in den Swapspace geschrieben, so es solchen gibt.Die
>"swappiness" beeinflusst die Auswahl auszulagernder Speicherseiten
>(also das Verhaeltnis zwischen "swapping" und "paging"). Zumindest
>ist das wohl bei hinreichend aktuellen Kerneln so (die
>Speicherverwaltung im Kernel hat sich ja im Verlauf der Entwicklung
>mehrfach komplett geaendert).

Auch diese Bedeutung von «swappiness» hat, wenn die Vermutung
stimmt, dass «scp» nicht viele anonyme Speicherseiten für sich
selbst braucht, aber den buffer cache flutet, wenn viele Daten zu
kopieren sind, zur Folge, dass bei kleinen «swappiness»‐Werten
tendenziell mehr die ganzen Dateiinhalte, die «scp» gelesen oder
geschrieben hat, aus dem buffer cache im Hauptspeicher geworfen
werden als die anonymen Speicherinhalte, die Prozessen gehören, aber
kein Gegenstück im Dateisystem haben. 

[Helmut Waitzmann]

Marc Haber <mh+usene...@zugschl.us>:

>Andreas Kohlbach <a...@spamfence.net> wrote:
>>On Thu, 01 Apr 2021 15:02:47 +0200, Helmut Waitzmann wrote:
>>> Daher kommt wohl auch die Empfehlung, (mindestens) so viel
>>> Swapspace bereitzustellen, wie RAM eingebaut ist. 
>>
>>IIRC hörte ich vor Jahrzehnten schon, mindestens doppelt soviel
>>SWAP wie RAM haben zu sollen. Gilt vielleicht nicht mehr.
>
>Beide dieser Empfehlungen gehören zu den Märchen, die seit mehr als
>zehn Jahren technisch überholt sind, aber nicht totzubekommen sind.

Wenn Du schon lästerst («Märchen»), solltest Du es wenigstens
sorgfältig tun:  Zu Zeiten, als manche Betriebssysteme die Menge des
verfügbaren virtuellen Speichers nur daran gemessen haben, wieviel
Swapspace im System vorhanden war, war die Empfehlung, mindestens so
viel Swapspace wie Hauptspeicher zu haben, kein Märchen sondern die
Voraussetzung, dass das Betriebssystem überhaupt so viel virtuellen
Speicher herausrückt, dass er den ganzen Hauptspeicher nutzt.  Also
ist diese Empfehlung bei (heutigen) Betriebssystemen, die nicht mehr
so verfahren, technisch überholt.  Wenn Du lästern willst, bezeichne
sie für diese Betriebssysteme als Märchen; wenn Du konstruktiv sein
willst, erkläre lieber, woher diese Empfehlung stammt, und, warum
sie nicht mehr angebracht ist. 

Ein Märchen, das seit mehr als zehn Jahren technisch überholt ist,
ist eines, das vor mehr als zehn Jahren ein den technischen
Tatsachen entsprechendes Märchen, also eine vor mehr als zehn Jahren
falsche Empfehlung war. 

Verzeihung, aber das musste ich mal loswerden:  Du bist zwar
technisch kompetent, manchmal aber ein ziemliches Lästermaul.  Und
damit bist Du für manches Gezänk hier im Usenet – am besten auch
noch ohne Betreffsanpassung –, das das Signal‐Rausch‐Verhältnis
ziemlich in den Keller fahren lässt, mitverantwortlich. 

[Helmut Waitzmann]

Hermann Riemann <nosp...@hermann-riemann.de>:
>Am 29.03.21 um 13:55 schrieb Juergen Ilse:

>> fehlender benoetigter Swap fuehrt moeglicherweise zur
>> unerwuenschten Beendigung von Prozessen ...
>
>Nicht unbedingt.
>
>Ich habe mal ( vor Jahrzehnten) den swap abgeschaltet.
>
>Dann mittels eines C Programmes den meisten Speicher angefordert
>( mit 0 belegt um ihn auch zu "benutzen" ) dann auf Eingabe
>gewartet.
>
>Die anschließende Benutzung mit vi führte dazu
>dass sehr viel zeit zwischen dem Tippen eines Buchstabens
>und deren Anzeige auf dem Bildschirm verging.

>
>Ein weiter Variante war ca 20% der Festplatte als swap
>einzurichten, und es dann von gleichartigem C Programm zu benutzen.
>Es gab da große Wartezeiten.
>

Hast Du dabei sichergestellt, dass das C‐Programm im zweiten Fall
nicht mehr Speicher angefordert hatte wie im ersten Fall? 

Nur dann, wenn das der Fall war, sind die beiden Fälle überhaupt
vergleichbar, damit man eine Aussage wie die folgende

>Fazit, swap Benutzung ist bei zeitkritischem Verwendung
>nicht empfehlenswert.

überhaupt machen kann. 

[Hermann Riemann]

Am 03.04.21 um 03:32 schrieb Helmut Waitzmann:

> Hast Du dabei sichergestellt, dass das C‐Programm im zweiten Fall nicht
> mehr Speicher angefordert hatte wie im ersten Fall?

Das C- Programm ist von der Art:

int64_t l=4096;
void *p;
while(1){
p=malloc(l);
if (p==NULL) break;
memset(p,0,l);
free(p);
printf("%llX\n"l);
l*=2;}

Da ist der Unterschied ob swap abgeschaltet ist,
deutlich sichtbar.
( Und ob der gleiche Speicherplatz wiederverwendet wird. )

Hermann
der damals bei OS/2 auch nur halb soviel
Platz bekommen hat, wie bei windows oder Linux.

--
http://www.hermann-riemann.de

[Helmut Waitzmann]

Juergen Ilse <ne...@usenet-verwaltung.de>:

>Hermann Riemann <nosp...@hermann-riemann.de> wrote:

>> Und dann gibt es noch die Frage, ob man die partition,
>> in der die swap Datei liegt, frei wählen kann.
>

>Zum Zeitpunkt des "swapon" muss die Partition r/w gemountet sein.
>

Heißt das, man darf, sobald «swapon» zu Ende gekommen ist, die
Partition abmontieren und muss sie erst wieder montieren, wenn man
die Swapdatei mittels «swapoff» außer Betrieb nehmen möchte?  Oder
muss die Partition so lang montiert bleiben, solange die Swapdatei
in Verwendung ist? 

[Klaus von der Heyde]

Christian Garbs schrieb:

[Speicherverbrauch von scp]

> Wenn eine Datei übertragen wird, dann wird ja Stück
> für Stück von der Platte gelesen, verschlüsselt und dann übers Netzwerk
> verschickt (oder genau andersherum) – dabei ist der Speicherbedarf
> konstant, den oder die Speicherbereiche kann man während der gesamten
> Übertragung wiederverwenden, da muss ja immer nur ein Stück der Datei
> reinpassen.

Eine andere Möglichkeit wäre, die zu lesende Datei zu mmap(2)en. Wie sähe
das dann aus? Ein schnelles »grep« auf dem scp-Quellcode fördert
allerdings kein »mmap« zu Tage.

-- Klaus

[Christian Garbs]

Mahlzeit!

Klaus von der Heyde <asc...@freenet.de> wrote:
> Christian Garbs schrieb:
>
> [Speicherverbrauch von scp]
>
>> Wenn eine Datei übertragen wird, dann wird ja Stück
>> für Stück von der Platte gelesen, verschlüsselt und dann übers Netzwerk
>> verschickt (oder genau andersherum) – dabei ist der Speicherbedarf
>> konstant, den oder die Speicherbereiche kann man während der gesamten
>> Übertragung wiederverwenden, da muss ja immer nur ein Stück der Datei
>> reinpassen.
>
> Eine andere Möglichkeit wäre, die zu lesende Datei zu mmap(2)en. Wie sähe
> das dann aus?

Vermutlich ähnlich, aber mit etwas weniger Speicherbedarf (ggf. ein
Buffer weniger).

Ich hatte überlegt, ob man dem Netzwerk nicht irgendwie direkt eine
gemmap(2)te Datei oder so vorwerfen kann, so dass man sich das „links
lesen, rechts schreiben“ im Programmcode sparen kann – das kann der
Kernel effizienter. (Ich programmiere selten so maschinennah, da
kenne ich mich nicht aus.)

Aber eine der Haupttätigkeiten von scp ist ja die Verschlüsselung, da
kommt man um einen Speicherbereich zum Arbeiten nicht herum – egal, ob
man die Datei per read(2) oder mmap(2) einliest.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Und der beste Grund jemandem eine leere eMail zu schreiben ist:
Weil da der Staat nicht mitlesen kann.

[Stefan Reuther]

Am 03.04.2021 um 03:09 schrieb Helmut Waitzmann:
> Marc Haber <mh+usene...@zugschl.us>:
>> Andreas Kohlbach <a...@spamfence.net> wrote:
>>> On Thu, 01 Apr 2021 15:02:47 +0200, Helmut Waitzmann wrote:
>>>> Daher kommt wohl auch die Empfehlung, (mindestens) so viel Swapspace
>>>> bereitzustellen, wie RAM eingebaut ist. 
>>>
>>> IIRC hörte ich vor Jahrzehnten schon, mindestens doppelt soviel SWAP
>>> wie RAM haben zu sollen. Gilt vielleicht nicht mehr.
>>
>> Beide dieser Empfehlungen gehören zu den Märchen, die seit mehr als
>> zehn Jahren technisch überholt sind, aber nicht totzubekommen sind.
>
> Wenn Du schon lästerst («Märchen»), solltest Du es wenigstens sorgfältig
> tun:  Zu Zeiten, als manche Betriebssysteme die Menge des verfügbaren
> virtuellen Speichers nur daran gemessen haben, wieviel Swapspace im
> System vorhanden war, war die Empfehlung, mindestens so viel Swapspace
> wie Hauptspeicher zu haben, kein Märchen sondern die Voraussetzung, dass
> das Betriebssystem überhaupt so viel virtuellen Speicher herausrückt,
> dass er den ganzen Hauptspeicher nutzt.

Welche Betriebssysteme waren das denn? Linux zählt jedenfalls seit
mindestens 20 Jahren nicht dazu (ich bin mir ziemlich sicher, auch davor
nicht). Windows ebenso nicht. Oder ist das nur ein Märchen?

Auf einem System mit ein- bis zweistelligen Megabytes ergibt Swap Sinn:
man hat ja immer ein paar Programme laufen, die im Wesentlichen nix tun:
ein paar gettys, ein sendmail, inetd, cron, etc. Lässt man zu, dass die
in den Swap geschoben werden, kann die Applikation, mit der man
interaktiv arbeitet, den kompletten RAM nutzen. Mehr als das ein- bis
zweifache des RAM ist wiederum nicht sinnvoll, weil man die nicht
sinnvoll gefüllt bekommt, das System ist schon vorher interaktiv
unbenutzbar.

Seit man RAM in Gigabytes misst, gehen die ganzen Hintergrundprozesse in
Rundungsfehlern unter. Da erfüllt Swap nur noch den Zweck, den
RAM-fressenden Prozess so auszubremsen, dass man eine höhere Chance hat,
noch das passende kill-Kommando abzusetzen.

Wenn man den Swap-Space also nicht für Suspend-to-Disk braucht, kommt
man gut ohne aus; ich hab seit Jahren keinen mehr.


Stefan

[Andreas Kohlbach]

AFAIK kann man «swapoff» nicht (mit entsprechenden Parametern) ausführen,
solange der Swap-Space nicht leer ist. Darf sie solange auch nicht
"abmontieren" (können wir vielleicht den Begriff "abbesteigen" verwenden,
weil der sich noch kaputter anhört? [1]). So, wie man AFAIK keine noch in
Benutzung befindliche Directory abbesteigen kann.

[1] Zur richtigen [1] Verwendung eingedeutschter englischer Begriffe rund
um den Computer vielleicht mal nach "Mutterbrett" und "Riesenbiß"
suchen, wie beispielsweise
<http://www.netzmafia.de/service/mutterbrett.html>. Das Original muss
von etwa 1998 sein, wenn ich mich auch erinnere, mich über
"Mutterbrett" schon in den 1980ern amüsiert zu haben.

Auszug:

| Es ist sehr wichtig, bei der Auswahl der Hartware sorgsam zu sein,
| denn nur auf guter Hartware kann die Weichware richtig schnell
| laufen. Bei der Hartware ist das Mutterbrett von besonderer
| Bedeutung. Das Mutterbrett soll unter anderem mit einem
| Schnitzelsatz von Intel ausgerüstet sein. Die gleiche Firma sollte
| auch die ZVE (Zentrale Voranschreitungs-Einheit) geliefert haben.
|
| Damit auch anspruchsvolle Weichware eine gute Vorführung zeigt,
| müssen mindestens 32 Riesenbiß Erinnerung eingebaut sein. Natürlich
| gehört neben dem 3 1/2 Daumenlang-Schlappscheibentreiber auch eine
| Dichtscheiben-Lese-nur-Einrichtung zur Grundausrüstung. Eine
| Hartscheibe mit vier Gigantischbiß dürfte für die nächsten zwei bis
| drei Jahre ausreichend Erinnerungsplatz für Weichware und Daten
| bieten.
--
Andreas

https://news-commentaries.blogspot.com/

[Arno Welzel]

Claus Reibenstein:

> Juergen Ilse schrieb am 01.04.2021 um 15:20:
>

>> Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>>
>> Ich meinte keine Swapdateien variabler Groesse (wie geht das denn mit
>> Linux? Das habe ich bisher bei Linux noch nie bewusst gesehen ...).
>
> Dann installiere mal Linux ohne Swappartition und wirf anschließend
> einen Blick in /etc/fstab.

Was soll da besonderes sein? Exemplarisch ein System ohne Swappartition
installiert:

UUID=a76778d2-ea08-4cdb-8b52-f0ea22c80a0a / ext4
errors=remount-ro,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0
0 1
UUID=4b681548-97e3-44be-88bf-378972abc7d2 /boot ext4
defaults 0 2


--
Arno Welzel
https://arnowelzel.de

[Marc Haber]

Andreas Kohlbach <a...@spamfence.net> wrote:
>Darf sie solange auch nicht
>"abmontieren" (können wir vielleicht den Begriff "abbesteigen" verwenden,
>weil der sich noch kaputter anhört? [1])

Also ich sage einhängen und aushängen.

[Sven Hartge]

Stefan Reuther <stefa...@arcor.de> wrote:
> Am 03.04.2021 um 03:09 schrieb Helmut Waitzmann:

>> Wenn Du schon lästerst («Märchen»), solltest Du es wenigstens
>> sorgfältig tun:  Zu Zeiten, als manche Betriebssysteme die Menge des
>> verfügbaren virtuellen Speichers nur daran gemessen haben, wieviel
>> Swapspace im System vorhanden war, war die Empfehlung, mindestens so
>> viel Swapspace wie Hauptspeicher zu haben, kein Märchen sondern die
>> Voraussetzung, dass das Betriebssystem überhaupt so viel virtuellen
>> Speicher herausrückt, dass er den ganzen Hauptspeicher nutzt.

> Welche Betriebssysteme waren das denn? Linux zählt jedenfalls seit
> mindestens 20 Jahren nicht dazu (ich bin mir ziemlich sicher, auch
> davor nicht). Windows ebenso nicht. Oder ist das nur ein Märchen?

Wir reden hier von den Ur-Unixen, die so gestaltet waren. Also Dinge,
die 40 bis 50 Jahre her sind mittlerweile.

S°

--
Sigmentation fault. Core dumped.

[Andreas Kohlbach]

Eigentlich Linux, siehe Gruppen-Name. UNIX ist nebenan. ;-)

Was hält man von dieser Tabelle
<https://opensource.com/article/19/2/swap-space-poll> aus dem Februar 2019?

Physikalisches RAM SWAP Hibernation
≤ 2GB 2X RAM 3X RAM
2GB - 8GB = RAM 2X RAM
8GB - 64GB 4G to 0.5X RAM 1.5X
RAM >64GB Minimum 4GB Hibernation not recommended
--
Andreas

https://news-commentaries.blogspot.com/

[Gerald E:scher]

Andreas Kohlbach schrieb am 4/4/2021 20:48:

> Was hält man von dieser Tabelle
> <https://opensource.com/article/19/2/swap-space-poll> aus dem Februar 2019?
>
> Physikalisches RAM SWAP Hibernation
> ≤ 2GB 2X RAM 3X RAM
> 2GB - 8GB = RAM 2X RAM
> 8GB - 64GB 4G to 0.5X RAM 1.5X
> RAM >64GB Minimum 4GB Hibernation not recommended

Auf meinem EeePC habe ich jahrelang unter Ubuntu Hibernation (ging
damals noch) mit SWAP = RAM benutzt.

Bei einem Embedded Linux versagt die Tabelle völlig, da gilt häufig
RAM > Flash ;-)

--
Gerald

[Marc Haber]

Andreas Kohlbach <a...@spamfence.net> wrote:
>Was hält man von dieser Tabelle
><https://opensource.com/article/19/2/swap-space-poll> aus dem Februar 2019?
>
>Physikalisches RAM SWAP Hibernation

>? 2GB 2X RAM 3X RAM

>2GB - 8GB = RAM 2X RAM
>8GB - 64GB 4G to 0.5X RAM 1.5X
>RAM >64GB Minimum 4GB Hibernation not recommended

Ich würde von so einer starren Empfehlung Abstand nehmen wollen, aber
wenn ich mir so meine nach "pi mal daumen" angelegten Systeme so
anschaue, sind meine Swapspaces eher größer als das. Passt also schon.

Ausnahme ist meine fetteste Kiste mit 32 GB RAM, auf der ein Haufen
VMs läuft, die hat nur 2 GB Swap (und Null davon in Benutzung). Mein
Notebook hat 16 GB RAM, 8 GB Swap und davon 2,3 GB in Benutzung. Mein
Desktop hat auch 16 GB RAM, aber völlig daneben 24 GB Swap (was hat
mich da denn geritten?), davon 2 MB (sic!) in Benutzung.

[Georg Schwarz]

Martin Schnitkemper <news.trash...@spamgourmet.com> wrote:

> Ich würde es erst mal ohne versuchen, die Swappartition kann man auch
> später noch anlegen, falls es sich als notwendig erweisen sollte.

danke für all die Hinweise.
In der Tat zeigte sich nun, das z.B. zum Compilieren von Firefox 8 GB
RAM nicht ausreichen. Ist aber kein Problem gewesen, schnell mal ein 16
GB Swapfile zu aktivieren (im laufenden Betrieb).

[Juergen Ilse]

Hallo,

Christian Garbs <mi...@cgarbs.de> wrote:
> Mahlzeit!
>
> Claus Reibenstein <crei...@gmail.com> wrote:
>> Juergen Ilse schrieb am 01.04.2021 um 15:20:
>
>>> Ich meinte keine Swapdateien variabler Groesse (wie geht das denn mit
>>> Linux? Das habe ich bisher bei Linux noch nie bewusst gesehen ...).
>>
>> Dann installiere mal Linux ohne Swappartition und wirf anschließend
>> einen Blick in /etc/fstab.
>
> Laut mkswap(8) wird die swap area auf die Große der zugeordneten Datei
> bzw. Partition gesetzt, d.h. eine Swapdatei müsste man vor dem Aufruf
> von mkswap mit einer bestimmten Größe anlegen.

Man kann mkswap auch eine Groesse mitgeben. Was dann passiert, wenn man die
(kleinere) Swapdatei mit Swapsignatur fuer einen groesseren Bereich enabled,
habe ich nie versucht. Vielleicht wird sie automatisch vergroessert, viel-
leicht stuerzt auch das System ab (evt. erst, wenn "zuviel" Swap benoetigt
wird), Was aber mit Sicherheit nicht passieren wird, ist das eine Swapdatei
sich "automatisch wieder verkleinert".

> Ich kann mir nicht vorstellen, dass sich von dieser Swapdatei
> nachträglich dynamisch die Größe ändern lässt.

Ich auch nicht.

> Wie sieht sowas denn in der fstab aus?

Deswegen fragte ich nach.

> (Swap in Datei mit fester Größe ist klar, aber hier war die Frage nach
> variabler Größe.)

Eben.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

Helmut Waitzmann <nn.th...@xoxy.net> wrote:

> Juergen Ilse <ne...@usenet-verwaltung.de>:
>>Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>
>>> Und dann gibt es noch die Frage, ob man die partition,
>>> in der die swap Datei liegt, frei wählen kann.
>>
>>Zum Zeitpunkt des "swapon" muss die Partition r/w gemountet sein.
>
> Heißt das, man darf, sobald «swapon» zu Ende gekommen ist, die
> Partition abmontieren und muss sie erst wieder montieren, wenn man
> die Swapdatei mittels «swapoff» außer Betrieb nehmen möchte?

Nein, nach dem swapon ist die Partition auf der die Swapdatei liegt "busy".
Schaltet man die Swadatei wieder ab, kann man die Partition kann man (sofern
darauf keine anderen Dateien oder Verzeichnisse in Gebrauch sind) wieder
umounten.

> Oder muss die Partition so lang montiert bleiben, solange die Swapdatei
> in Verwendung ist? 

Ja. Ich hatte auch nichts anderes behauptet.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

Hermann Riemann <nosp...@hermann-riemann.de> wrote:
> Am 03.04.21 um 03:32 schrieb Helmut Waitzmann:
>
>> Hast Du dabei sichergestellt, dass das C‐Programm im zweiten Fall nicht
>> mehr Speicher angefordert hatte wie im ersten Fall?
>
> Das C- Programm ist von der Art:
>
> int64_t l=4096;
> void *p;
> while(1){
> p=malloc(l);
> if (p==NULL) break;
> memset(p,0,l);
> free(p);
> printf("%llX\n"l);
> l*=2;}
>
> Da ist der Unterschied ob swap abgeschaltet ist,
> deutlich sichtbar.

... weil mit Swap mehr Speicheranforderungen bedient werden koennen, und
soit der Swap, falls er vorhanden ist, auch garantiert genutzt wird. Deine
Werte fuer beide Faeelle sind *nicht* vergleichbar, weil mit Swap mehr
Speicher von deinem Programm genutzt wird (es sei denn, du beschraenkst die
maximale vom Programm nutzbare Groesse mit ulimit ...).

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Sieghard Schicktanz]

Hallo Andreas,

Du schriebst am Sat, 03 Apr 2021 10:36:01 -0400:

> >>"abmontieren" (können wir vielleicht den Begriff "abbesteigen"
> >>verwenden, weil der sich noch kaputter anhört? [1])
> >
> > Also ich sage einhängen und aushängen.
>

> Stimme ich zu. Hört sich besser als "de/montieren" an.

Wobei _eigentlich_ "montieren" die korrekte deutsche Übersetzung für
"mount" ist - You do mount your hard disk into your computer initially.
(Naja, vielleicht nicht Du selber, aber Dein Händler oder der Hersteller
hat die mit Sicherheit montiert. Und die Benutzung von "mount" für das
Zurverfügungstellen der Daten darauf ist dann doch eigentlich eine
folgerichtige Übertragung des Vorgangs, oder?)

> Ich meine das erste mal "einhängen" im deutsche Amiga Handbuch zum Befehl
> "mount" gelesen zu haben. Muss um 1987 gewesen sein. Gerade wurden
> Erinnerungen dazu wach.

Das wäre dann eine Eindeutschung, die Benutzung eines _deskritiven_ Wortes
für einen anderssprachigen Begriff.
Allerdings hört sich auch meiner Meinung nach "einhängen" der Funktion von
Software angemessener an.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Sieghard Schicktanz]

Hallo Helmut,

Du schriebst am Thu, 01 Apr 2021 18:34:53 +0200:

> Das überrascht mich jetzt.  Ich hätte erwartet, dass «scp» nicht
> besonders speicherhungrig ist:  Ein Datenblock wird gelesen,
> komprimiert, verschlüsselt und über die Leitung geschickt.  Dann

Du übersiehst, daß der Block eben _nicht_ "über die Leitung geschickt"
wird, sondern sozusagen "auf" die Leitung - es wird erstmal nur der Auftrag
zum Verschicken an den Treiber gegeben.

> kommt der nächste an die Reihe; dabei braucht man für den vorigen
> keinen virtuellen Speicher mehr. 

Die Daten sind damit noch lange nicht übertragen. Das Übertragen dauert für
den Prozessor enorm lange, da hat er ggfs. schon wieder eine ganze Menge
weiterer Blöcke verarbeitet, bevor die ersten wirklich übertragen sind. Das
kann durchaus zu einem "nicht ganz" kleinen Stau führen, der den Speicher
gut auslasten könnte.

> keinen virtuellen Speicher mehr.  Beim empfangenden Ende geschieht
> entsprechendes umgekehrt.  Die Datenblöcke müssen ja nicht viele MB
> groß sein. 

Auf der Empfangsseite gibt es kein solches Problem, solange der Datenträger
zum Speichern schnell genug ist. Aber beschreib' mal eine SD-Karte per
GB-Ethernet-Verbindung so, dann staut sich das auch auf der Empfangsseite.

[Juergen Ilse]

Hallo,

Andreas Kohlbach <a...@spamfence.net> wrote:
> AFAIK kann man «swapoff» nicht (mit entsprechenden Parametern) ausführen,
> solange der Swap-Space nicht leer ist. Darf sie solange auch nicht
> "abmontieren"

"swapoff" bewikte bei mir stets, dass der Swapbereich durch "umlagern"
der belegten Bereiche auf ggfs. vorhandene andere Swapbereiche verlagert
oder freigegeben (und dann im Ram gehalten) werden. Dann wird der Swap-
bereich abgemeldet. Solange auch ohne den Swwapbereich noch genuegend
Speicher vorhanden ist, geht dass alles automatisch und man benoetigt
da keine speziellen Kommandooptionen.

> (können wir vielleicht den Begriff "abbesteigen" verwenden,

Nein.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Stefan Reuther <stefa...@arcor.de> wrote:
> Am 03.04.2021 um 03:09 schrieb Helmut Waitzmann:
>> Wenn Du schon lästerst («Märchen»), solltest Du es wenigstens sorgfältig
>> tun:  Zu Zeiten, als manche Betriebssysteme die Menge des verfügbaren
>> virtuellen Speichers nur daran gemessen haben, wieviel Swapspace im
>> System vorhanden war, war die Empfehlung, mindestens so viel Swapspace
>> wie Hauptspeicher zu haben, kein Märchen sondern die Voraussetzung, dass
>> das Betriebssystem überhaupt so viel virtuellen Speicher herausrückt,
>> dass er den ganzen Hauptspeicher nutzt.
>
> Welche Betriebssysteme waren das denn? Linux zählt jedenfalls seit
> mindestens 20 Jahren nicht dazu (ich bin mir ziemlich sicher, auch davor
> nicht).

Bei letzterem liegst du falsch. Es gab auch mal einige Linux-Kernel, bei
denen die Speicherverwaltung genau so arbeitete (wenn ich mich recht er-
innere, waren das einige 2.4.x Kernel).

> Windows ebenso nicht. Oder ist das nur ein Märchen?

Bei aktuellen BSDs bin ich mir nicht sicher, aber frueher war das bei BSD
auch so, sofern man ueberhaupt Swap hatte, bestimmte die Groesse des Swaps
die groesse des vom Betriebssystem verwalteten virtuellen Speichers.
Das betraf auch noch SunOS 4.x (Solaris 1.x) das ein BSD wa, im Gegensatz
zu spaeteren Solaris-Versionen, die dann eher ein SYSVR4 waren (mit ein
paar Kompatibilitaetszugestaendnissen in Richtung BSD).

> Seit man RAM in Gigabytes misst, gehen die ganzen Hintergrundprozesse in
> Rundungsfehlern unter. Da erfüllt Swap nur noch den Zweck, den
> RAM-fressenden Prozess so auszubremsen, dass man eine höhere Chance hat,
> noch das passende kill-Kommando abzusetzen.

Hast du mal LLVM als Debugversion selbst compiliert? Da werden 8GB beim
linken einiger der erzeugten binaries schon fast knapp ... Und es gibt
durchaus Software-Projekte, die noch groesser sind.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Andreas Kohlbach]

On Mon, 5 Apr 2021 16:12:43 +0200, Sieghard Schicktanz wrote:
>
> Hallo Andreas,
>
> Du schriebst am Sat, 03 Apr 2021 10:36:01 -0400:
>
>> >>"abmontieren" (können wir vielleicht den Begriff "abbesteigen"
>> >>verwenden, weil der sich noch kaputter anhört? [1])
>> >
>> > Also ich sage einhängen und aushängen.
>>
>> Stimme ich zu. Hört sich besser als "de/montieren" an.
>
> Wobei _eigentlich_ "montieren" die korrekte deutsche Übersetzung für
> "mount" ist - You do mount your hard disk into your computer initially.
> (Naja, vielleicht nicht Du selber, aber Dein Händler oder der Hersteller
> hat die mit Sicherheit montiert. Und die Benutzung von "mount" für das
> Zurverfügungstellen der Daten darauf ist dann doch eigentlich eine
> folgerichtige Übertragung des Vorgangs, oder?)

"You install your hard disk..." würde ich sagen. Sowohl für den Vorgang
des Einbaus, als der Installation von Treibern, falls man die
braucht. Zumindest die Amis. Ich müsste mal einen Bekannten aus UK
fragen, wie er das sagen würde.

>> Ich meine das erste mal "einhängen" im deutsche Amiga Handbuch zum Befehl
>> "mount" gelesen zu haben. Muss um 1987 gewesen sein. Gerade wurden
>> Erinnerungen dazu wach.
>
> Das wäre dann eine Eindeutschung, die Benutzung eines _deskritiven_ Wortes
> für einen anderssprachigen Begriff.

IIRC war das ganze deutsche Handbuch eine Katastrophe. IIRC übersetzte
man u.a. "Icons" mit "Ikonen". War ja ein neuer Begriff damals -
trotzdem...

Den Hammer brachte eine Krawatte von Commodore bei der Vorstellung des
Amigas 1986 in Frankfurt (ein Event, was mit einer Show mit Frank Elsner
endete), als der Commodore-Mann in einer extrem langweiligen 20 minütigen
Rede die Maus beschrieb, und diese "Rollkugeleingabegerät" (und das muss
ich einfach mal in einem Wort schreiben :-D ) nannte. Youtube hat Videos
drüber.

> Allerdings hört sich auch meiner Meinung nach "einhängen" der Funktion von
> Software angemessener an.

IIRC kann "mount" (auf dem Amiga) auch "Software-Devices", wie RAM-Disks,
einhängen.
--
Andreas

https://news-commentaries.blogspot.com/

[Helmut Waitzmann]

Juergen Ilse <ne...@usenet-verwaltung.de>:

Danke für die Verdeutlichung. 

Deine Aussage ließ beide Interpretationen zu.  Und nachdem Du die
Formulierung «zum Zeitpunkt des "swapon"», die ausdrücklich nur
einen kurzen Zeitraum am Anfang der Inbetriebnahme der Swapdatei
meint, verwendest hast, konnte ich die «andere Behauptung» nicht
mehr als ausgeschlossen betrachten. 

[Helmut Waitzmann]

Hermann Riemann <nosp...@hermann-riemann.de>:

>Am 03.04.21 um 03:32 schrieb Helmut Waitzmann:

>> Hast Du dabei sichergestellt, dass das C‐Programm im zweiten Fall
>> nicht mehr Speicher angefordert hatte wie im ersten Fall?
>
>Das C- Programm ist von der Art:
>
>
>int64_t l=4096;
>void *p;
>while(1){
> p=malloc(l);
> if (p==NULL) break;
> memset(p,0,l);
> free(p);
> printf("%llX\n"l);
> l*=2;}
>
>Da ist der Unterschied ob swap abgeschaltet ist,
>deutlich sichtbar.

Das C‐Programm fordert also in geometrischer Folge, mit 4 KiB
beginnend, in jedem Schleifendurchlauf die doppelte Menge Speicher
an, so lang, bis das Betriebssystem den Wunsch nicht mehr erfüllen
kann. 

=> Mit Swapspace tritt der Fall, dass das C‐Programm zu Ende kommt,
erst viel später ein, als ohne.  Daher sind beide Fälle nicht
vergleichbar. 

Der Versuch taugt also auf den ersten Blick allenfalls für die
Frage, ob mehr oder weniger Swapspace im Fall, dass ein
wildgewordenes Programm amoklaufend allen Speicher frisst, den es
kriegen kann, besser ist oder nicht, aber nicht für die Frage, ob
ein System ohne wildgewordene Programme besser ohne oder mit
Swapspace läuft. 

Wenn ich Dich richtig verstanden habe, möchtest Du durch Verzicht
auf Swapspace um den Preis, dass der Betriebssystemkern den
Sensenmann (OoM‐Killer) losschickt und im System möglicherweise
Schaden anrichtet, Swappen verhindern. 

Da hätte ich Dir einen besseren Vorschlag, der ohne den Sensenmann
auskommt:  Verbiete dem Programm, sich allen Speicher zu krallen. 
Dann kann man trotzdem noch, falls man will, Swapspace
bereitstellen. 

Schau Dir dazu das Handbuch «prlimit(2)» für den Systemaufruf
«prlimit» an, mit dem man Prozesse im Ressourcen‐Verbrauch
beschränken kann.  Dort findest Du u. a. folgende Abschnitte, hier
mit «|» am Zeilenanfang markiert, durchbrochen von Kommentaren:

| The resource argument must be one of:
|
| RLIMIT_AS
| This is the maximum size of the process's virtual
| memory (address space). The limit is specified in
| bytes, and is rounded down to the system page size.
| This limit affects calls to brk(2), mmap(2), and
| mremap(2), which fail with the error ENOMEM upon
| exceeding this limit. In addition, automatic stack
| expansion fails (and generates a SIGSEGV that kills
| the process if no alternate stack has been made
| available via sigaltstack(2)). Since the value is a
| long, on machines with a 32-bit long either this
| limit is at most 2 GiB, or this resource is
| unlimited.

Das hört sich doch schon mal sehr gut an, um einen Prozess, der mit
«malloc» allzu gierig umgeht, in Speicherschranken zu weisen.  Aber
es gibt sogar noch spezifischeres: 

|
| RLIMIT_DATA
| This is the maximum size of the process's data
| segment (initialized data, uninitialized data, and
| heap). The limit is specified in bytes, and is
| rounded down to the system page size. This limit
| affects calls to brk(2), sbrk(2), and (since Linux
| 4.7) mmap(2), which fail with the error ENOMEM upon
| encountering the soft limit of this resource.

Diese Schranke ist genau das, was man hier brauchen kann, um einen
Prozess, der mit «malloc» allzu gierig umgeht, in Schranken zu
weisen. 

Und dann gibt es auch noch eine Begrenzung für den Stack: 


| RLIMIT_STACK
| This is the maximum size of the process stack, in
| bytes. Upon reaching this limit, a SIGSEGV signal
| is generated. To handle this signal, a process must
| employ an alternate signal stack (sigaltstack(2)).
|
| Since Linux 2.6.23, this limit also determines the
| amount of space used for the process's command-line
| arguments and environment variables; for details,
| see execve(2).

Das wäre für amoklaufende Programme, die etwa eine Endlosrekursion
in Funktions‐ oder Prozeduraufrufe machen und deshalb den Stack
unbeschränkt wachsen lassen, einerseits interessant.  Die Folge ist
dann, dass sie ein SEGV‐Signal erhalten.  Andererseits kann man
davon ausgehen, dass die meisten Programme sich keinen alternativen
Signal‐Stack einrichten.  Dann läuft der Stacküberlauf auf ein
KILL‐Signal hinaus, das es dem Prozess nicht erlaubt, noch
irgendwelche Aufräumarbeiten zu tun. 

Für das Programm «prlimit» (das natürlich den Systemaufruf «prlimit»
benutzt) steht im Handbuch «prlimit(1)», wie es aufzurufen ist. 

Eine weitere Hilfe, das System flüssig zu halten, ist, Programme,
die viel Speicher anfordern, mit einem schlechten (also großen)
«ionice»‐Wert oder «nice»‐Wert zu starten.  «nice» ist eigentlich
immer eine gute Idee beim Start von nicht‐zeitkritischen Programmen,
die das System ziemlich beanspruchen könnten. 

Dann kannst Du folgenden Aufruf des C‐Programms probieren: 


# Starte das Programm mit in Bytes gemessener
# (beispielsweise auf 1 GiB) begrenzter Speichergroesze
# und gesenkter Prioritaet:
nice -n 19 -- prlimit --data="$(( 1 << 30 ))": -- \
das_C-Programm

Gib als Speichergrößengrenze die Menge von Speicher an, die das
C‐Programm beim Versuch ohne Swapspace erhalten konnte.

Nimm den Swapspace in Betrieb und wiederhole den Versuch.  Hast Du
jetzt immer noch große Wartezeiten?  Meine Vermutung:  Man erhält
ein stabiles System, bei dem das amoklaufende C‐Programm scheitert,
ohne das ganze System auszubremsen und – vor allem – ohne vom
Sensenmann daran gehindert zu werden, vor dem Ende Aufräumarbeiten
zu tun. 

[Helmut Waitzmann]

Sieghard Schicktanz <Sieghard....@SchS.de>:

>Hallo Helmut,
>Du schriebst am Thu, 01 Apr 2021 18:34:53 +0200:
>
>> Das überrascht mich jetzt.  Ich hätte erwartet, dass «scp» nicht
>> besonders speicherhungrig ist:  Ein Datenblock wird gelesen,
>> komprimiert, verschlüsselt und über die Leitung geschickt.  Dann
>
>Du übersiehst, daß der Block eben _nicht_ "über die Leitung
>geschickt" wird, sondern sozusagen "auf" die Leitung - es wird
>erstmal nur der Auftrag zum Verschicken an den Treiber gegeben.
>
>> kommt der nächste an die Reihe; dabei braucht man für den vorigen
>> keinen virtuellen Speicher mehr. 
>
>Die Daten sind damit noch lange nicht übertragen. Das Übertragen
>dauert für den Prozessor enorm lange, da hat er ggfs. schon wieder
>eine ganze Menge weiterer Blöcke verarbeitet, bevor die ersten
>wirklich übertragen sind. Das kann durchaus zu einem "nicht ganz"
>kleinen Stau führen, der den Speicher gut auslasten könnte.

Du hast vollkommen recht:  Das Netzwerk kann der Flaschenhals sein. 
Aber da hätte ich erwartet, dass «scp» im Systemaufruf zum
Abschicken der Daten steckenbleibt, bis die Daten tatsächlich
verschickt sind.  Ist das nicht der Fall? 

[Marc Haber]

Marcus Jodorf <tr...@killfile.de> wrote:
>Insofern bin ich da auch eher bei ein-/aushängen für mounten.

Wobei "mounten" sogar richtig wäre, der Duden sagt, dass aus dem
Englishen entlehnte Verben schwach konjugiert werden. Also muss man
auch sagen, man habe das System geupdatet, und wenn man das konsequent
macht, klingt es nach einer Weile auch gar nicht mehr so schlimm.

>hätte. Einhängen gelegentlich - aber ehrlich gesagt vewendet man einfach
>mounten und wer sowas eindeutscht, muß immer mit der einen oder anderen
>hochgezogenen Augenbraue rechnen, weil das deutet immer auf absoluten
>Laien hin.

Naja, "ich mounte" geht ja noch, wobei "ich hab geunmountet" mir schon
so ein wenig die Fußnägel hochdreht. Meine Tendenz geht deutlichst
dazu, solche Texte gleich auf Englisch zu schreiben, aber das findet
selten die Begeisterung des Publikums.

[Claus Reibenstein]

Andreas Kohlbach schrieb am 06.04.2021 um 12:58:

> Aber auch jüngere Franzosen (oder Kanadier), und die Werbung, verwenden
> französische Begriffe. Jeder kennt Gigabyte. Hier schreibt die Werbung
> stattdessen von "Giga Octets".

Ein Byte ist definiert als die kleinste adressierbare Einheit. Sie kann
also auch eine andere Größe als 8 Bit haben. Im allgemeinen
Sprachgebrauch wird jedoch Byte mit 8 Bit gleichgesetzt, was eigentlich
falsch ist. Die Franzosen umgehen dieses Problem mit ihrem "octet".

Generell mögen Franzosen keine Fremdwörter in ihrer Sprache, oder sie
sprechen sie französisch aus. Verlange mal in einem Geschäft ein Bounty
oder ein Nuts ...

Gruß
Claus

[Stefan Reuther]

Am 05.04.2021 um 19:38 schrieb Juergen Ilse:
> Stefan Reuther <stefa...@arcor.de> wrote:
>> Am 03.04.2021 um 03:09 schrieb Helmut Waitzmann:
>>> Wenn Du schon lästerst («Märchen»), solltest Du es wenigstens sorgfältig
>>> tun:  Zu Zeiten, als manche Betriebssysteme die Menge des verfügbaren
>>> virtuellen Speichers nur daran gemessen haben, wieviel Swapspace im
>>> System vorhanden war, war die Empfehlung, mindestens so viel Swapspace
>>> wie Hauptspeicher zu haben, kein Märchen sondern die Voraussetzung, dass
>>> das Betriebssystem überhaupt so viel virtuellen Speicher herausrückt,
>>> dass er den ganzen Hauptspeicher nutzt.
>>
>> Welche Betriebssysteme waren das denn? Linux zählt jedenfalls seit
>> mindestens 20 Jahren nicht dazu (ich bin mir ziemlich sicher, auch davor
>> nicht).
>
> Bei letzterem liegst du falsch. Es gab auch mal einige Linux-Kernel, bei
> denen die Speicherverwaltung genau so arbeitete (wenn ich mich recht er-
> innere, waren das einige 2.4.x Kernel).

Dann, bitte, zeigen.

Das System, an das ich mit der Jahreszahl "vor 20 Jahren" dachte, wo die
Erinnerung also noch frisch ist, hatte 1 GB RAM und 200 MB Swap und
einen 2.4er Kernel. Natürlich konnte ich den kompletten RAM damit
nutzen. Auch eine Anzahl VMs mit 2.4er Kerneln hatte ich. Die hatten nie
Swap.

Ich will nicht ausschließen, dass so eine Einschränkung entsteht, wenn
man z.B. Suspend-to-Disk will, aber Standard ist das nicht.

>> Seit man RAM in Gigabytes misst, gehen die ganzen Hintergrundprozesse in
>> Rundungsfehlern unter. Da erfüllt Swap nur noch den Zweck, den
>> RAM-fressenden Prozess so auszubremsen, dass man eine höhere Chance hat,
>> noch das passende kill-Kommando abzusetzen.
>
> Hast du mal LLVM als Debugversion selbst compiliert? Da werden 8GB beim
> linken einiger der erzeugten binaries schon fast knapp ... Und es gibt
> durchaus Software-Projekte, die noch groesser sind.

Es ist ja nicht so, dass ich nicht im Notfall wüsste, wo ich Swap
herbekomme.


Stefan

[Sieghard Schicktanz]

Hallo Andreas,

Du schriebst am Mon, 05 Apr 2021 14:30:58 -0400:

> >> (können wir vielleicht den Begriff "abbesteigen" verwenden,
> >
> > Nein.
>

> Dann "entsteigen"?

Absteigen. Das, was man machen soll, wenn man auf einem toten Pferd sitzt.

[Sieghard Schicktanz]

Hallo Helmut,

Du schriebst am Mon, 05 Apr 2021 23:35:08 +0200:

> >> besonders speicherhungrig ist:  Ein Datenblock wird gelesen,
> >> komprimiert, verschlüsselt und über die Leitung geschickt.  Dann
> >
> >Du übersiehst, daß der Block eben _nicht_ "über die Leitung
> >geschickt" wird, sondern sozusagen "auf" die Leitung - es wird
> >erstmal nur der Auftrag zum Verschicken an den Treiber gegeben.

...

> Du hast vollkommen recht:  Das Netzwerk kann der Flaschenhals sein. 

Solche Übertragungen laufen durchaus nicht nur über "[d]as Netzwerk" - es
gibt viele unterschiedliche Kanäle, über die sowas abgewickelt werden kann.
Dazu zählen die seriellen Schnittstellen, aber auch die Tastatur, die Maus,
diverse Bussysteme für Steuerungswecke (wie der CAN-Bus, der evtl. in
Deinem Auto arbeitet, oft sogar in mehreren Ausgaben ["Instanzen"]) oder
auch der USB oder ein WLAN.

> Aber da hätte ich erwartet, dass «scp» im Systemaufruf zum
> Abschicken der Daten steckenbleibt, bis die Daten tatsächlich
> verschickt sind.  Ist das nicht der Fall? 

Das war so bei den Primitivsystemen wie CP/M und MSDOS so, aber geht
bei neueren wie Linux durchaus auch noch. Das nennt man dann "synchrone
Ein-Ausgabe", und die drückt halt heftig die Bearbeitungsleistung des
Programms. Deswegen nutzt man fast immer die entsprechend benannte
"asynchrone Ein-Ausgabe", bei der dem System lediglich der Auftrag und
die zu bearbeitenden Daten übergeben werden und sich dann das System
unabhängig vom (weiter) verarbeitenden Programm um die Ein-Ausgabe
kümmert.

[Sieghard Schicktanz]

Hallo Marcus,

Du schriebst am Mon, 05 Apr 2021 23:40:15 +0200:

> > "mount" ist - You do mount your hard disk into your computer
> > initially.
>

> Nee, die „install“en da eher.

Das sagrt halt nichts über den Vorgang - zu der Zeit, als das aufkam, war
das eine richtiggehende mechanische Montagearbeit.

> Und auch physikalisch „häng“ ich persönlich auch eher Platten in einen
> Rechner (tray/Plattenkäfig).

Ja, inzwischen, mit den labbrigen Schnell"montage"rahmen...

> Insofern bin ich da auch eher bei ein-/aushängen für mounten.

> „Montieren“ ist einfach nur gruselig. Mir ist auch ehrlich gesagt seit

Und trotzdem war das mal ein offizieller Ausdruck in der deutschen
Computertechnik, sogar für einen software-mäßigen Vorgang, das "Linken".
AFAIR war das die (Telefunken?) TR440 odersowas, bei der man mit dem
Schlüsselwort "montiere" den Link-Vorgang ausgelöst hat. Die hatte für
spezielle Zwecke der Eingabe auch ein besonderes "Fluchtsymbol", das man
zur Ablaufsteuerung benuzten konnte, und deren Befehle waren allesamt
deutsche Wortte. Ich weiß aber nicht mehr, was damit machbar war.
War ja immerhin im letzten Jahrtausend...

[Sieghard Schicktanz]

Hallo Andreas,

Du schriebst am Mon, 05 Apr 2021 14:24:13 -0400:

> > Wobei _eigentlich_ "montieren" die korrekte deutsche Übersetzung für
> > "mount" ist - You do mount your hard disk into your computer initially.

...

> "You install your hard disk..." würde ich sagen. Sowohl für den Vorgang

Auch wenn Du mit dem "screw driver" die "mounting screws" durch die
"mounting holes" im Rahmen in die "mounts" der Platte drehst?
Klar, auch Abflußrohre werden "installed", aber werden auch die Motoren
in den Autos "installed", oder doch eher "mounted"?
Aber klar, das ist wohl durchaus auch regional unterschiedlich.

["einhängen"]

> > Das wäre dann eine Eindeutschung, die Benutzung eines _deskritiven_

^pt

> > Wortes für einen anderssprachigen Begriff.
>
> IIRC war das ganze deutsche Handbuch eine Katastrophe. IIRC übersetzte

Das ist normal. Es tut der Ausdrucksweise halt nicht so recht gut, wenn ein
Text über drei (oder so) Zwischensprachen aus der Ausgangs- in eine Ziel-
Sprache übertragen wird. Da gibt's dann mehr Übertragungsfehler als
korrekte Ausdrücke, trotz der enorman Redundanz in "natürlichen" Sprechen.

> man u.a. "Icons" mit "Ikonen". War ja ein neuer Begriff damals -

Heißen Ikonen auf englisch nicht tatsächlich "Icons"?

> trotzdem...

...liest man das gelegentlich immer noch manchmal.

> Den Hammer brachte eine Krawatte von Commodore bei der Vorstellung des
> Amigas 1986 in Frankfurt (ein Event, was mit einer Show mit Frank Elsner
> endete), als der Commodore-Mann in einer extrem langweiligen 20 minütigen
> Rede die Maus beschrieb, und diese "Rollkugeleingabegerät" (und das muss

Und wenn Du Dich totlachst - das war zu der Zeit der korrekte deutsche
Begriff dafür. Der hat sogar die Mechanik darin richtig beschrieben.

> ich einfach mal in einem Wort schreiben :-D ) nannte. Youtube hat Videos

Das ist auch korrekt so.

[Claus Reibenstein]

Sieghard Schicktanz schrieb am 05.04.2021 um 16:12:

> Hallo Andreas,

So heiße ich zwar nicht, antworte Dir aber trotzdem.

> Wobei _eigentlich_ "montieren" die korrekte deutsche Übersetzung für
> "mount" ist

Das ist _eine_ von vielen möglichen Übersetzungen, und im gegebenen
Kontext nicht gerade die beste.

Gruß
Claus

[Andreas Kohlbach]

On Tue, 6 Apr 2021 19:07:32 +0200, Sieghard Schicktanz wrote:
>
> Du schriebst am Mon, 05 Apr 2021 14:24:13 -0400:
>

>> man u.a. "Icons" mit "Ikonen". War ja ein neuer Begriff damals -
>
> Heißen Ikonen auf englisch nicht tatsächlich "Icons"?

Mag sein. Aber "Ikonen" verwendet im Zusammenhang mit Computern niemand
(oder keiner, den ich kenne, nicht mal frühere AOL ("Bin ich schon drin?)
User.

>> trotzdem...
>
> ...liest man das gelegentlich immer noch manchmal.
>
>> Den Hammer brachte eine Krawatte von Commodore bei der Vorstellung des
>> Amigas 1986 in Frankfurt (ein Event, was mit einer Show mit Frank Elsner
>> endete), als der Commodore-Mann in einer extrem langweiligen 20 minütigen
>> Rede die Maus beschrieb, und diese "Rollkugeleingabegerät" (und das muss
>
> Und wenn Du Dich totlachst - das war zu der Zeit der korrekte deutsche
> Begriff dafür. Der hat sogar die Mechanik darin richtig beschrieben.

Yup. Wie in der DDR, um seine verbliebenen zwangsumgetauschten Ost-Märker
auf der Rückreise vor dem Grenzübertritt Helmstedt in einem Restaurant an
der Autobahn mit einem Essen "Broiler mit Sättigungsbeiage" zu
verbrennen.

Diese Begriffe sind heute (schon seit den 1990ern) nicht mehr sinnvoll.
--
Andreas

https://news-commentaries.blogspot.com/

[Andreas Kohlbach]

On Tue, 6 Apr 2021 19:41:40 +0200, Sieghard Schicktanz wrote:
>
> Du schriebst am Mon, 05 Apr 2021 14:30:58 -0400:
>
>> >> (können wir vielleicht den Begriff "abbesteigen" verwenden,
>> >
>> > Nein.
>>
>> Dann "entsteigen"?
>
> Absteigen. Das, was man machen soll, wenn man auf einem toten Pferd sitzt.

Guter Vergleich. Aber ob der Jürgen überzeugt? ;-)
--
Andreas

[Sieghard Schicktanz]

Hallo Claus,

Du schriebst am Tue, 6 Apr 2021 21:38:19 +0200:

> > Hallo Andreas,
>
> So heiße ich zwar nicht, antworte Dir aber trotzdem.

Kommt drauf an, auf welches Posting an wen Du hier antwortest.

> > Wobei _eigentlich_ "montieren" die korrekte deutsche Übersetzung für
> > "mount" ist
>
> Das ist _eine_ von vielen möglichen Übersetzungen, und im gegebenen
> Kontext nicht gerade die beste.

Soviele wüßte ich da jetzt nicht, mein Wörterbuch auch nicht. Ich finde die
schon die geeignetste, was schlügest Du denn vor?

[Ralph Angenendt]

Ich denke schon, dass sie das ist, siehe die manpage von mount auf
MacOS:

| The mount command calls the mount(2) system call to prepare and graft a
| special device or the remote node (rhost:path) on to the file system
| tree at the point mount_point,

Speziell prepare (vorbereiten) und graft (pfropfen).

Ralph
--
Übervaterlandverräter und Mutterkornblumenblau

[Claus Reibenstein]

Sieghard Schicktanz schrieb am 07.04.2021 um 23:54:
(Einleitungsroman sachgerecht gekürzt)

> Claus schrieb am Tue, 6 Apr 2021 21:38:19 +0200:
>
>>> Wobei _eigentlich_ "montieren" die korrekte deutsche Übersetzung für
>>> "mount" ist
>>
>> Das ist _eine_ von vielen möglichen Übersetzungen, und im gegebenen
>> Kontext nicht gerade die beste.
>
> Soviele wüßte ich da jetzt nicht, mein Wörterbuch auch nicht.

Leo <http://dict.leo.org/> kennt einige.

Gruß
Claus

[Christoph 'Mehdorn' Weber]

Hallo!

* Hermann Riemann <nosp...@hermann-riemann.de>:
> Am 29.03.21 um 13:55 schrieb Juergen Ilse:

>> Bei aktuellen Kerneln hat eine Swapdatei im Filesystem keine wesentlichen
>> Nachteile mehr gegenueber einer Swap-Partition. Mit Swap-Dateien ist man
>> womoeglich flexibler, deswegen wuerde ich evt. Swwapdateien gegenueber
>> Swappartitionen vorziehen ...
> Einer Frage ist,ob die Verwaltung mit open, Dateiverlängerung und close
> einen erheblichen Zeitaufwand hat.

Es gibt Tools wie dphys-swapfile und swapspace, die dynamisch
neue Swap-Dateien hinzufügen können, wenn der Speicher knapp wird.
Der größte Haken dabei ist, daß Swap nicht auf "sparse files"
funktioniert und man daher eine entsprechend große Datei wirklich
erst anlegen/befüllen muß, bevor man sie zum Swapspace machen
kann. Setzt man den Wert zu groß an, dauert es im ungünstigsten
Fall zu lang, bis die nächste Swap-Datei bereit ist.

Das open und close kostet dagegen fast nichts. Vergrößern ist
mir allerdings neu, vermutlich müßte man dann sowieso noch mal mit
"mkswap" drüber gehen. Die Tools legen daher einfach zusätzliche
Dateien an, und deaktivieren/löschen sie bei geringer Swap-Nutzung
ggf. wieder.

Vielleicht kann man die auch auf LVM umkonfigurieren, damit sie
bei Bedarf LVs anlegen, mkswap anwenden und sie dann auch wieder
abräumen. Dann spart man sich das Datei-Schreiben, was die grösste
Bremse an der Stelle sein dürfte.

> Und dann gibt es noch die Frage, ob man die partition,
> in der die swap Datei liegt, frei wählen kann.

Bei den Tools beiden genannten Tools IIRC schon.

>> Nicht genutzter Swap frisst kein Brot,
> solange es auf dem "Lauf"werk nicht eng wird.

Ob die beiden Tools darauf achten und ggf. versuchen, Swapfiles
bei knappem Platz rückzubauen, weiß ich nicht mehr. Länger nicht
benutzt.

(Auf vielen Systemen hab ich inzwischen Hibernate im Betrieb, da
gibt es sowieso einen großen Swap und Extra-Spapfiles brauche ich
dort eher selten und wenn nur temporär da bau ich die manuell.
Ansonsten wurden die RAM-knappen Systeme inzwischen durch
Exemplare mit mehr RAM ersetzt/aufgerüstet.)

Christoph

--
Manager und Propheten haben Visionen.
Propheten schaffen in Erfuellung gehende Visionen ohne Koks.
Manager schaffen nicht in Erfuellung gehende Visionen mit Koks.
(Ulrich Eckhardt)