Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OOM-Killer konfigurieren
42 views
Skip to first unread message
Andreas Kohlbach
Oct 29, 2022, 7:28:21 PM10/29/22
to
OOM scheint bei Mint schon länger Default deaktiviert zu sein.
Es passiert mir trotz meiner üppigen *hüstel* 8 GB RAM, dass ein Programm
(in der Regel einer der Browser, oder LibreOffice) Amok läuft, dass
zeitweise auch die Uhr in der GUI stehen bleibt (zeigt hier auch Sekunden
an, sodass das auffällt), oft auch die Maus einfriert. Ich warte dann, um
auf eine TTY zu wechseln, top aufzurufen (was mitunter Minuten dauert,
bis top startet), und den Speicher-Hog abzuschießen.
Da ich diesen Hog eh abschieße, könnte das eh gleich OOM machen. Das
Programm dazu heißt vermutlich choom (lese mich gerade ein).
Meine Frage ist, was vernünftige Werte für meine Situation sind; Es soll
ein zu speicherhungriger Task nach einiger Zeit abgeschossen werden, wenn
das System kaum noch reagiert, *selbst* wenn dieser Prozess schon seit
Tagen oder Wochen läuft.
--
Andreas
Es passiert mir trotz meiner üppigen *hüstel* 8 GB RAM, dass ein Programm
(in der Regel einer der Browser, oder LibreOffice) Amok läuft, dass
zeitweise auch die Uhr in der GUI stehen bleibt (zeigt hier auch Sekunden
an, sodass das auffällt), oft auch die Maus einfriert. Ich warte dann, um
auf eine TTY zu wechseln, top aufzurufen (was mitunter Minuten dauert,
bis top startet), und den Speicher-Hog abzuschießen.
Da ich diesen Hog eh abschieße, könnte das eh gleich OOM machen. Das
Programm dazu heißt vermutlich choom (lese mich gerade ein).
Meine Frage ist, was vernünftige Werte für meine Situation sind; Es soll
ein zu speicherhungriger Task nach einiger Zeit abgeschossen werden, wenn
das System kaum noch reagiert, *selbst* wenn dieser Prozess schon seit
Tagen oder Wochen läuft.
--
Andreas
Marcel Mueller
Oct 30, 2022, 3:26:03 AM10/30/22
to
Am 30.10.22 um 01:28 schrieb Andreas Kohlbach:
sogar nur 6GB, aber das ist noch nicht passiert. Außer in der VM bekomme
ich den Speicher nicht annäherungsweise voll.
Allerdings hatte ich an der Arbeit unter Win kürzlich mehrfach so ein
Problem. Da waren innerhalb von 2 Tagen 38GB Speicherlast. Ich konnte
den Schuldigen nicht identifizieren, aber Firefox war zumindest auf
Verdächtigen-Liste. Sollte da eine matschige Version im Umlauf gewesen sein?
> Da ich diesen Hog eh abschieße, könnte das eh gleich OOM machen. Das
> Programm dazu heißt vermutlich choom (lese mich gerade ein).
Ich glaube, das ist nur, um das Verhalten bei /laufenden/ Prozessen zu
ändern.
Außerdem ist das auch ein Kernel-Feature. Ich glaube gar nicht, dass man
das abschalten kann, außer indem man Overcommit komplett deaktiviert,
was unter x64 keine gute Idee ist. Nur funktioniert dieser Killer eben
auch nicht immer. Wenn der Übeltäter im State D hängt, klappt es z.B. nicht.
> Meine Frage ist, was vernünftige Werte für meine Situation sind; Es soll
> ein zu speicherhungriger Task nach einiger Zeit abgeschossen werden, wenn
> das System kaum noch reagiert, *selbst* wenn dieser Prozess schon seit
> Tagen oder Wochen läuft.
Falls es um einen Desktop geht und du nicht gerade eine Datenbank auf
der Kiste hast, kannst du alles abschießen, sobald es mehr als 4GB
braucht. Etwas sinnvolles kann es dann jedenfalls nicht mehr sein.
Nur hilft das leider bei Browsern nicht mehr viel, denn die starten
jetzt Dutzende von Prozessen, damit es nicht mehr so auffällt. Die
können in Summe aber trotzdem riesige Mengen Ressourcen verbrennen.
Aber ich denke die mit Abstand sinnvollste Methode ist, die Größe des
Swap auf sinnvolle Werte zu begrenzen. Bei Linux ist ein bisschen blöd,
dass Swap auch für Hibernate herhalten muss. Dadurch kann man es nicht
beliebig klein machen. Aber falls du das nicht brauchst (ist zumindest
bei Ubuntu sowieso standardmäßig deaktiviert) kannst Du einfach die
Größe von Swap auf z.B. 2-3GB begrenzen. Dann sind der Langsamkeit
Grenzen gesetzt. Der OOM-Killer schlägt nämlich erst zu, wenn Swap nicht
mehr hilft.
BTW, bist du sicher dass es OOM war und nicht etwa Endlosschleifen auf
der CPU? Wenn man davon mehr als Kerne gesammelt hat, wird es nämlich
ähnlich zäh. Das hatten wir auch kürzlich mal bei einem Web-Server. Da
ging durch eine Data-Race eine Hashtable-Datenstruktur vom
Authentifizierungsmodul kaputt. Und dann hat jeder eingehende
Web-Request eine neue Endlosschleife gestartet. Ziemlich nervig.
Marcel
> OOM scheint bei Mint schon länger Default deaktiviert zu sein.
>
> Es passiert mir trotz meiner üppigen *hüstel* 8 GB RAM, dass ein Programm
> (in der Regel einer der Browser, oder LibreOffice) Amok läuft, dass
> zeitweise auch die Uhr in der GUI stehen bleibt (zeigt hier auch Sekunden
> an, sodass das auffällt), oft auch die Maus einfriert. Ich warte dann, um
> auf eine TTY zu wechseln, top aufzurufen (was mitunter Minuten dauert,
> bis top startet), und den Speicher-Hog abzuschießen.
Interessant. Ich habe hier auch 8GB, sogar auf mehreren Kisten in der VM
>
> Es passiert mir trotz meiner üppigen *hüstel* 8 GB RAM, dass ein Programm
> (in der Regel einer der Browser, oder LibreOffice) Amok läuft, dass
> zeitweise auch die Uhr in der GUI stehen bleibt (zeigt hier auch Sekunden
> an, sodass das auffällt), oft auch die Maus einfriert. Ich warte dann, um
> auf eine TTY zu wechseln, top aufzurufen (was mitunter Minuten dauert,
> bis top startet), und den Speicher-Hog abzuschießen.
sogar nur 6GB, aber das ist noch nicht passiert. Außer in der VM bekomme
ich den Speicher nicht annäherungsweise voll.
Allerdings hatte ich an der Arbeit unter Win kürzlich mehrfach so ein
Problem. Da waren innerhalb von 2 Tagen 38GB Speicherlast. Ich konnte
den Schuldigen nicht identifizieren, aber Firefox war zumindest auf
Verdächtigen-Liste. Sollte da eine matschige Version im Umlauf gewesen sein?
> Da ich diesen Hog eh abschieße, könnte das eh gleich OOM machen. Das
> Programm dazu heißt vermutlich choom (lese mich gerade ein).
ändern.
Außerdem ist das auch ein Kernel-Feature. Ich glaube gar nicht, dass man
das abschalten kann, außer indem man Overcommit komplett deaktiviert,
was unter x64 keine gute Idee ist. Nur funktioniert dieser Killer eben
auch nicht immer. Wenn der Übeltäter im State D hängt, klappt es z.B. nicht.
> Meine Frage ist, was vernünftige Werte für meine Situation sind; Es soll
> ein zu speicherhungriger Task nach einiger Zeit abgeschossen werden, wenn
> das System kaum noch reagiert, *selbst* wenn dieser Prozess schon seit
> Tagen oder Wochen läuft.
der Kiste hast, kannst du alles abschießen, sobald es mehr als 4GB
braucht. Etwas sinnvolles kann es dann jedenfalls nicht mehr sein.
Nur hilft das leider bei Browsern nicht mehr viel, denn die starten
jetzt Dutzende von Prozessen, damit es nicht mehr so auffällt. Die
können in Summe aber trotzdem riesige Mengen Ressourcen verbrennen.
Aber ich denke die mit Abstand sinnvollste Methode ist, die Größe des
Swap auf sinnvolle Werte zu begrenzen. Bei Linux ist ein bisschen blöd,
dass Swap auch für Hibernate herhalten muss. Dadurch kann man es nicht
beliebig klein machen. Aber falls du das nicht brauchst (ist zumindest
bei Ubuntu sowieso standardmäßig deaktiviert) kannst Du einfach die
Größe von Swap auf z.B. 2-3GB begrenzen. Dann sind der Langsamkeit
Grenzen gesetzt. Der OOM-Killer schlägt nämlich erst zu, wenn Swap nicht
mehr hilft.
BTW, bist du sicher dass es OOM war und nicht etwa Endlosschleifen auf
der CPU? Wenn man davon mehr als Kerne gesammelt hat, wird es nämlich
ähnlich zäh. Das hatten wir auch kürzlich mal bei einem Web-Server. Da
ging durch eine Data-Race eine Hashtable-Datenstruktur vom
Authentifizierungsmodul kaputt. Und dann hat jeder eingehende
Web-Request eine neue Endlosschleife gestartet. Ziemlich nervig.
Marcel
Stefan Froehlich
Oct 30, 2022, 5:15:29 AM10/30/22
to
On Sun, 30 Oct 2022 01:28:19 Andreas Kohlbach wrote:
> OOM scheint bei Mint schon länger Default deaktiviert zu sein.
>
> Es passiert mir trotz meiner üppigen *hüstel* 8 GB RAM, dass ein
> Programm (in der Regel einer der Browser, oder LibreOffice) Amok
> läuft, dass zeitweise auch die Uhr in der GUI stehen bleibt (zeigt
> hier auch Sekunden an, sodass das auffällt), oft auch die Maus
> einfriert.
Passiert mir mit 16GB spätestens alle paar Wochen, und ich vermute,
> OOM scheint bei Mint schon länger Default deaktiviert zu sein.
>
> Es passiert mir trotz meiner üppigen *hüstel* 8 GB RAM, dass ein
> Programm (in der Regel einer der Browser, oder LibreOffice) Amok
> läuft, dass zeitweise auch die Uhr in der GUI stehen bleibt (zeigt
> hier auch Sekunden an, sodass das auffällt), oft auch die Maus
> einfriert.
dass es auch mit 32 oder 64GB kaum anders wäre.
> Ich warte dann, um auf eine TTY zu wechseln, top aufzurufen (was
> mitunter Minuten dauert, bis top startet), und den Speicher-Hog
> abzuschießen.
Mehrzahl der Fälle X so beleidigt, dass ich es abschießen und neu
starten muss - das ist dann (angesichts der hoch zweistelligen Zahl
an offenen Fenstern) schon sehr unschön beim Wiederherstellen.
> Da ich diesen Hog eh abschieße, könnte das eh gleich OOM machen.
> Das Programm dazu heißt vermutlich choom (lese mich gerade ein).
> Meine Frage ist, was vernünftige Werte für meine Situation sind;
> Es soll ein zu speicherhungriger Task nach einiger Zeit
> abgeschossen werden, wenn das System kaum noch reagiert, *selbst*
> wenn dieser Prozess schon seit Tagen oder Wochen läuft.
gib bitte Bescheid. Im Grund genommen hätte ich zwar gerne Browser
ohne memory leaks, aber diese Hoffnung habe ich seit längerem
aufgegeben.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Für Liebhaber: Stefan - wenn alles mißlingt!
(Sloganizer)
Marcel Mueller
Oct 30, 2022, 5:44:28 AM10/30/22
to
Am 30.10.22 um 10:15 schrieb Stefan Froehlich:
startet, schafft er es doch kaum, vorher genug Speicher zu leaken. ;-)
Oft liegt es auch gar nicht am Browser, sondern an ausufernden
JavaScripten der Websites, die Speicherlecks haben. Wenn man sich per
PiHole zumindest die meisten Tracker vom Hals schafft, wird es ruhiger.
Gegen eigene Bloatware von den "großen" Websites hilft das aber auch nicht.
Aber mit "about:performance" kann die Übeltäter zumindest erkennen, und
gelegentlich auch mal in die Schranken weisen.
Marcel
> Solltest Du da irgendetwas substantiell sinnvolles herausbekommen,
> gib bitte Bescheid. Im Grund genommen hätte ich zwar gerne Browser
> ohne memory leaks, aber diese Hoffnung habe ich seit längerem
> aufgegeben.
So oft wie FF sich wegen gerade rein gelaufener Updates selbst neu
> gib bitte Bescheid. Im Grund genommen hätte ich zwar gerne Browser
> ohne memory leaks, aber diese Hoffnung habe ich seit längerem
> aufgegeben.
startet, schafft er es doch kaum, vorher genug Speicher zu leaken. ;-)
Oft liegt es auch gar nicht am Browser, sondern an ausufernden
JavaScripten der Websites, die Speicherlecks haben. Wenn man sich per
PiHole zumindest die meisten Tracker vom Hals schafft, wird es ruhiger.
Gegen eigene Bloatware von den "großen" Websites hilft das aber auch nicht.
Aber mit "about:performance" kann die Übeltäter zumindest erkennen, und
gelegentlich auch mal in die Schranken weisen.
Marcel
Christian Schumacher
Oct 30, 2022, 5:45:28 AM10/30/22
to
Stefan Froehlich schrieb am So, 30 Okt 2022 10:15:
> Solltest Du da irgendetwas substantiell sinnvolles herausbekommen,
> gib bitte Bescheid. Im Grund genommen hätte ich zwar gerne Browser
> ohne memory leaks, aber diese Hoffnung habe ich seit längerem
> aufgegeben.
lynx, w3m, …?
> Solltest Du da irgendetwas substantiell sinnvolles herausbekommen,
> gib bitte Bescheid. Im Grund genommen hätte ich zwar gerne Browser
> ohne memory leaks, aber diese Hoffnung habe ich seit längerem
> aufgegeben.
*duck*
--
Gruß, Christian
»Wenn du klug bist, so mische eines mit dem anderen: Hoffe nicht ohne
Zweifel, und zweifle nicht ohne Hoffnung.« --Seneca
Bonita Montero
Oct 30, 2022, 5:56:26 AM10/30/22
to
erst sehr spät nachdem angefangen wurde zu Swappen, und das sollte der
Zeitpunkt sein ab wo es unangenehm wird.
Tim Ritberg
Oct 30, 2022, 6:13:35 AM10/30/22
to
Am 30.10.22 um 08:26 schrieb Marcel Mueller:
> Allerdings hatte ich an der Arbeit unter Win kürzlich mehrfach so ein
> Problem. Da waren innerhalb von 2 Tagen 38GB Speicherlast. Ich konnte
> den Schuldigen nicht identifizieren, aber Firefox war zumindest auf
> Verdächtigen-Liste. Sollte da eine matschige Version im Umlauf gewesen
> sein?
>
>
Aber doch nur der virtuelle Adressraum?
Firefox läuft gar nicht unter 9GB. Kannst du mit der limit.conf testen,
startet dann nur mit leerem Fenster.
Tim
> Allerdings hatte ich an der Arbeit unter Win kürzlich mehrfach so ein
> Problem. Da waren innerhalb von 2 Tagen 38GB Speicherlast. Ich konnte
> den Schuldigen nicht identifizieren, aber Firefox war zumindest auf
> Verdächtigen-Liste. Sollte da eine matschige Version im Umlauf gewesen
> sein?
>
>
Firefox läuft gar nicht unter 9GB. Kannst du mit der limit.conf testen,
startet dann nur mit leerem Fenster.
Tim
Tim Ritberg
Oct 30, 2022, 6:14:28 AM10/30/22
to
Am 30.10.22 um 10:45 schrieb Christian Schumacher:
Tim
> Stefan Froehlich schrieb am So, 30 Okt 2022 10:15:
>
>> Solltest Du da irgendetwas substantiell sinnvolles herausbekommen,
>> gib bitte Bescheid. Im Grund genommen hätte ich zwar gerne Browser
>> ohne memory leaks, aber diese Hoffnung habe ich seit längerem
>> aufgegeben.
>
> lynx, w3m, …?
> *duck*
>
Im xterm zeigen die ja sogar Bilder an :-)
>
>> Solltest Du da irgendetwas substantiell sinnvolles herausbekommen,
>> gib bitte Bescheid. Im Grund genommen hätte ich zwar gerne Browser
>> ohne memory leaks, aber diese Hoffnung habe ich seit längerem
>> aufgegeben.
>
> lynx, w3m, …?
> *duck*
>
Tim
Peter J. Holzer
Oct 30, 2022, 7:06:37 AM10/30/22
to
On 2022-10-29 23:28, Andreas Kohlbach <a...@spamfence.net> wrote:
> OOM scheint bei Mint schon länger Default deaktiviert zu sein.
Ich glaube nicht, dass men den wirklich deaktivieren kann. Man kann
> OOM scheint bei Mint schon länger Default deaktiviert zu sein.
Overcommitment reduzieren/abschalten, was die Wahrscheinlichkeit sehr
gering macht, dass er anspringt, aber wenn der Kernel kein RAM mehr
findet, hat er eigentlich nur mehr zwei Möglichkeiten: Einen Prozess
killen oder das ganze System killen. Letzteres ist glaube ich nicht
vorgesehen (aber wenn Du das willst, gibt es Watchdogs).
> Es passiert mir trotz meiner üppigen *hüstel* 8 GB RAM, dass ein Programm
> (in der Regel einer der Browser, oder LibreOffice) Amok läuft, dass
> zeitweise auch die Uhr in der GUI stehen bleibt (zeigt hier auch Sekunden
> an, sodass das auffällt), oft auch die Maus einfriert. Ich warte dann, um
> auf eine TTY zu wechseln, top aufzurufen (was mitunter Minuten dauert,
> bis top startet), und den Speicher-Hog abzuschießen.
>
> Da ich diesen Hog eh abschieße, könnte das eh gleich OOM machen.
findet (also RAM und Swap komplett voll sind).
Es gibt allerdings den systemd-oomd, der das laufende System monitort
und Prozesse killt, wenn die MemoryPressure zu hoch wird:
https://www.man7.org/linux/man-pages/man8/systemd-oomd.8.html
Wie gut das in der Praxis funktioniert, musst Du selber ausprobieren.
Beachte insbesondere diesen Absatz:
| Be aware that if you intend to enable monitoring and actions on
| user.slice, user-$UID.slice, or their ancestor cgroups, it is
| highly recommended that your programs be managed by the systemd
| user manager to prevent running too many processes under the same
| session scope (and thus avoid a situation where memory intensive
| tasks trigger systemd-oomd to kill everything under the cgroup).
| If you're using a desktop environment like GNOME, it already
| spawns many session components with the systemd user manager.
Du musst also herausfinden, ob Dein Desktop-Environment bereits den
Browser und LibreOffice in einer eigenen CGroup startet, und wenn nicht,
wie Du es dazu bringst, das zu tun. Sonst schießt Dir der systemd-oomd
die ganze Session ab.
hp
Tim Ritberg
Oct 30, 2022, 7:53:18 AM10/30/22
to
Am 30.10.22 um 12:06 schrieb Peter J. Holzer:
das Problem.
Tim
> On 2022-10-29 23:28, Andreas Kohlbach <a...@spamfence.net> wrote:
>> OOM scheint bei Mint schon länger Default deaktiviert zu sein.
>
> Ich glaube nicht, dass men den wirklich deaktivieren kann. Man kann
> Overcommitment reduzieren/abschalten, was die Wahrscheinlichkeit sehr
> gering macht, dass er anspringt, aber wenn der Kernel kein RAM mehr
> findet, hat er eigentlich nur mehr zwei Möglichkeiten: Einen Prozess
> killen oder das ganze System killen. Letzteres ist glaube ich nicht
> vorgesehen (aber wenn Du das willst, gibt es Watchdogs).
>
Wird lustig, wenn er systemd kickt. Mit dem alten Init sicher nicht so
>> OOM scheint bei Mint schon länger Default deaktiviert zu sein.
>
> Ich glaube nicht, dass men den wirklich deaktivieren kann. Man kann
> Overcommitment reduzieren/abschalten, was die Wahrscheinlichkeit sehr
> gering macht, dass er anspringt, aber wenn der Kernel kein RAM mehr
> findet, hat er eigentlich nur mehr zwei Möglichkeiten: Einen Prozess
> killen oder das ganze System killen. Letzteres ist glaube ich nicht
> vorgesehen (aber wenn Du das willst, gibt es Watchdogs).
>
das Problem.
Tim
Stefan Froehlich
Oct 30, 2022, 8:16:06 AM10/30/22
to
On Sun, 30 Oct 2022 10:44:26 Marcel Mueller wrote:
> Am 30.10.22 um 10:15 schrieb Stefan Froehlich:
>> Solltest Du da irgendetwas substantiell sinnvolles
>> herausbekommen, gib bitte Bescheid. Im Grund genommen hätte ich
>> zwar gerne Browser ohne memory leaks, aber diese Hoffnung habe
>> ich seit längerem aufgegeben.
> So oft wie FF sich wegen gerade rein gelaufener Updates selbst neu
> startet, schafft er es doch kaum, vorher genug Speicher zu leaken.
> ;-)
Dererlei ignoriere ich tapfer.
> Am 30.10.22 um 10:15 schrieb Stefan Froehlich:
>> Solltest Du da irgendetwas substantiell sinnvolles
>> herausbekommen, gib bitte Bescheid. Im Grund genommen hätte ich
>> zwar gerne Browser ohne memory leaks, aber diese Hoffnung habe
>> ich seit längerem aufgegeben.
> So oft wie FF sich wegen gerade rein gelaufener Updates selbst neu
> startet, schafft er es doch kaum, vorher genug Speicher zu leaken.
> ;-)
> Oft liegt es auch gar nicht am Browser, sondern an ausufernden
> JavaScripten der Websites, die Speicherlecks haben. Wenn man sich
> per PiHole zumindest die meisten Tracker vom Hals schafft, wird es
> ruhiger.
> Gegen eigene Bloatware von den "großen" Websites hilft das aber
> auch nicht.
vorkommende Blödheit. Irgendwo einen Debug-Output in die Ausgabe
spucken und dabei entweder die irrtümlich gebaute Endlosschleife
übersehen oder alternativ aus versehen den gesamten Hauptspeicher
formatiert ausgeben wollen...
Meine Erfahrung ist, dass sich keiner der gängigen Browser nach
versuchter Anzeige einiger 100MB noch zu normalem Anzeigeverhalten
bewegen lässt, auch wenn das schuldige Tab schon längst geschlossen
ist.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Marcel Mueller
Oct 30, 2022, 10:31:13 AM10/30/22
to
Am 30.10.22 um 13:16 schrieb Stefan Froehlich:
eine Instanz der neuen, inkompatiblen Programmversion starten würden. Da
kommt dann ein Fehler.
> Meine Erfahrung ist, dass sich keiner der gängigen Browser nach
> versuchter Anzeige einiger 100MB noch zu normalem Anzeigeverhalten
> bewegen lässt, auch wenn das schuldige Tab schon längst geschlossen
> ist.
Das dauert eine Weile, bis sie sich von sowas erholen, wenn überhaupt.
Marcel
> On Sun, 30 Oct 2022 10:44:26 Marcel Mueller wrote:
>> Am 30.10.22 um 10:15 schrieb Stefan Froehlich:
>>> Solltest Du da irgendetwas substantiell sinnvolles
>>> herausbekommen, gib bitte Bescheid. Im Grund genommen hätte ich
>>> zwar gerne Browser ohne memory leaks, aber diese Hoffnung habe
>>> ich seit längerem aufgegeben.
>
>> So oft wie FF sich wegen gerade rein gelaufener Updates selbst neu
>> startet, schafft er es doch kaum, vorher genug Speicher zu leaken.
>> ;-)
>
> Dererlei ignoriere ich tapfer.
Dann kann man aber keine neuen Tabs mehr öffnen, da die unweigerlich
>> Am 30.10.22 um 10:15 schrieb Stefan Froehlich:
>>> Solltest Du da irgendetwas substantiell sinnvolles
>>> herausbekommen, gib bitte Bescheid. Im Grund genommen hätte ich
>>> zwar gerne Browser ohne memory leaks, aber diese Hoffnung habe
>>> ich seit längerem aufgegeben.
>
>> So oft wie FF sich wegen gerade rein gelaufener Updates selbst neu
>> startet, schafft er es doch kaum, vorher genug Speicher zu leaken.
>> ;-)
>
> Dererlei ignoriere ich tapfer.
eine Instanz der neuen, inkompatiblen Programmversion starten würden. Da
kommt dann ein Fehler.
> Meine Erfahrung ist, dass sich keiner der gängigen Browser nach
> versuchter Anzeige einiger 100MB noch zu normalem Anzeigeverhalten
> bewegen lässt, auch wenn das schuldige Tab schon längst geschlossen
> ist.
Marcel
Friedhelm Waitzmann
Oct 30, 2022, 11:53:31 AM10/30/22
to
Marcel Mueller:
>Aber ich denke die mit Abstand sinnvollste Methode ist, die
>Größe des Swap auf sinnvolle Werte zu begrenzen.
Warum nicht die Größe von Prozessen begrenzen? Siehe prlimit(1)
und ulimit innerhalb von bash.
>Marcel
Friedhelm
>Falls es um einen Desktop geht und du nicht gerade eine
>Datenbank auf der Kiste hast, kannst du alles abschießen, sobald
>es mehr als 4GB braucht. Etwas sinnvolles kann es dann
>jedenfalls nicht mehr sein. Nur hilft das leider bei Browsern
>nicht mehr viel, denn die starten jetzt Dutzende von Prozessen,
>damit es nicht mehr so auffällt. Die können in Summe aber
>trotzdem riesige Mengen Ressourcen verbrennen.
Kann man die Anzahl der Browser‐Prozesse begrenzen?
>Datenbank auf der Kiste hast, kannst du alles abschießen, sobald
>es mehr als 4GB braucht. Etwas sinnvolles kann es dann
>jedenfalls nicht mehr sein. Nur hilft das leider bei Browsern
>nicht mehr viel, denn die starten jetzt Dutzende von Prozessen,
>damit es nicht mehr so auffällt. Die können in Summe aber
>trotzdem riesige Mengen Ressourcen verbrennen.
>Aber ich denke die mit Abstand sinnvollste Methode ist, die
>Größe des Swap auf sinnvolle Werte zu begrenzen.
und ulimit innerhalb von bash.
>Marcel
Friedhelm
Peter J. Holzer
Oct 30, 2022, 11:56:15 AM10/30/22
to
On 2022-10-30 15:53, Friedhelm Waitzmann <usenetf2...@spamgourmet.com> wrote:
> Marcel Mueller:
>>Falls es um einen Desktop geht und du nicht gerade eine
>>Datenbank auf der Kiste hast, kannst du alles abschießen, sobald
>>es mehr als 4GB braucht. Etwas sinnvolles kann es dann
>>jedenfalls nicht mehr sein. Nur hilft das leider bei Browsern
>>nicht mehr viel, denn die starten jetzt Dutzende von Prozessen,
>>damit es nicht mehr so auffällt. Die können in Summe aber
>>trotzdem riesige Mengen Ressourcen verbrennen.
>
> Kann man die Anzahl der Browser‐Prozesse begrenzen?
Weniger Tabs öffnen?
> Marcel Mueller:
>>Falls es um einen Desktop geht und du nicht gerade eine
>>Datenbank auf der Kiste hast, kannst du alles abschießen, sobald
>>es mehr als 4GB braucht. Etwas sinnvolles kann es dann
>>jedenfalls nicht mehr sein. Nur hilft das leider bei Browsern
>>nicht mehr viel, denn die starten jetzt Dutzende von Prozessen,
>>damit es nicht mehr so auffällt. Die können in Summe aber
>>trotzdem riesige Mengen Ressourcen verbrennen.
>
> Kann man die Anzahl der Browser‐Prozesse begrenzen?
hp
Tim Ritberg
Oct 30, 2022, 3:16:42 PM10/30/22
to
Am 30.10.22 um 16:53 schrieb Friedhelm Waitzmann:
Tim
f sinnvolle Werte zu begrenzen.
>
> Warum nicht die Größe von Prozessen begrenzen? Siehe prlimit(1)
> und ulimit innerhalb von bash.
>
>
Firefox und Chrome laufen dann gar nicht mehr.
>
> Warum nicht die Größe von Prozessen begrenzen? Siehe prlimit(1)
> und ulimit innerhalb von bash.
>
>
Tim
Marcel Mueller
Oct 30, 2022, 4:52:36 PM10/30/22
to
Am 30.10.22 um 16:53 schrieb Friedhelm Waitzmann:
> Marcel Mueller:
>> Falls es um einen Desktop geht und du nicht gerade eine
>> Datenbank auf der Kiste hast, kannst du alles abschießen, sobald
>> es mehr als 4GB braucht. Etwas sinnvolles kann es dann
>> jedenfalls nicht mehr sein. Nur hilft das leider bei Browsern
>> nicht mehr viel, denn die starten jetzt Dutzende von Prozessen,
>> damit es nicht mehr so auffällt. Die können in Summe aber
>> trotzdem riesige Mengen Ressourcen verbrennen.
>
> Kann man die Anzahl der Browser‐Prozesse begrenzen?
Nicht mehr. Jeder Tab ist ein Prozess. Hatte erst nur Chrome und seit
>> Falls es um einen Desktop geht und du nicht gerade eine
>> Datenbank auf der Kiste hast, kannst du alles abschießen, sobald
>> es mehr als 4GB braucht. Etwas sinnvolles kann es dann
>> jedenfalls nicht mehr sein. Nur hilft das leider bei Browsern
>> nicht mehr viel, denn die starten jetzt Dutzende von Prozessen,
>> damit es nicht mehr so auffällt. Die können in Summe aber
>> trotzdem riesige Mengen Ressourcen verbrennen.
>
> Kann man die Anzahl der Browser‐Prozesse begrenzen?
einer Weile auch FF.
Eine der wirksamsten Maßnahmen ist noch, einen 32 Bit Firefox zu nehmen,
aber der fehlt mittlerweile in den meisten Repositories. Unter Win
klappt das aber ganz gut. Da dort die meisten Variablen nur halb so groß
sind braucht der zumindest erheblich weniger Speicher.
>> Aber ich denke die mit Abstand sinnvollste Methode ist, die
>> Größe des Swap auf sinnvolle Werte zu begrenzen.
>
> Warum nicht die Größe von Prozessen begrenzen? Siehe prlimit(1)
> und ulimit innerhalb von bash.
Marcel
Sieghard Schicktanz
Oct 30, 2022, 5:13:06 PM10/30/22
to
Hallo Tim,
Du schriebst am Sun, 30 Oct 2022 11:13:34 +0100:
> Aber doch nur der virtuelle Adressraum?
> Firefox läuft gar nicht unter 9GB. Kannst du mit der limit.conf
> testen, startet dann nur mit leerem Fenster.
Was schreibst Du da?
$ free
total used free shared buff/cache available
Mem: 7548368 2188952 731332 29312 4628084 488824
Swap 17753772 10496 17743276
$ ps aux | grep firefox
webuser 11262 Sl 20:29 0:06 /usr/lib64/firefox/firefox -no-remote
webuser 11355 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
webuser 11400 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
webuser 11444 Sl 20:29 0:05 /usr/lib64/firefox/firefox-bin -content...
webuser 11492 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
webuser 11504 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
webuser 11514 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
webuser 11569 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
(Ausgabe heftig postingfähig gestutzt)
Doch, "overcommit" ist aktiv, aber 9GB firefox seh' ich da nicht.
Gut, der läuft jetzt noch recht bescheiden, aber auch mit mehr Last
habe ich noch kein Problem damit gesehen. Vielleicht ab >20 Tabs mal,
aber das wär'mir dann doch zu unübersichtlich...
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Du schriebst am Sun, 30 Oct 2022 11:13:34 +0100:
> Aber doch nur der virtuelle Adressraum?
> Firefox läuft gar nicht unter 9GB. Kannst du mit der limit.conf
> testen, startet dann nur mit leerem Fenster.
$ free
total used free shared buff/cache available
Mem: 7548368 2188952 731332 29312 4628084 488824
Swap 17753772 10496 17743276
$ ps aux | grep firefox
webuser 11262 Sl 20:29 0:06 /usr/lib64/firefox/firefox -no-remote
webuser 11355 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
webuser 11400 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
webuser 11444 Sl 20:29 0:05 /usr/lib64/firefox/firefox-bin -content...
webuser 11492 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
webuser 11504 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
webuser 11514 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
webuser 11569 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
(Ausgabe heftig postingfähig gestutzt)
Doch, "overcommit" ist aktiv, aber 9GB firefox seh' ich da nicht.
Gut, der läuft jetzt noch recht bescheiden, aber auch mit mehr Last
habe ich noch kein Problem damit gesehen. Vielleicht ab >20 Tabs mal,
aber das wär'mir dann doch zu unübersichtlich...
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Tim Ritberg
Oct 30, 2022, 6:02:44 PM10/30/22
to
Am 30.10.22 um 20:42 schrieb Sieghard Schicktanz:
Tim
> Hallo Tim,
>
> Du schriebst am Sun, 30 Oct 2022 11:13:34 +0100:
>
>> Aber doch nur der virtuelle Adressraum?
>> Firefox läuft gar nicht unter 9GB. Kannst du mit der limit.conf
>> testen, startet dann nur mit leerem Fenster.
>
> Was schreibst Du da?
> $ free
> total used free shared buff/cache available
> Mem: 7548368 2188952 731332 29312 4628084 488824
> Swap 17753772 10496 17743276
>
> $ ps aux | grep firefox
> webuser 11262 Sl 20:29 0:06 /usr/lib64/firefox/firefox -no-remote
> webuser 11355 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> webuser 11400 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> webuser 11444 Sl 20:29 0:05 /usr/lib64/firefox/firefox-bin -content...
> webuser 11492 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> webuser 11504 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> webuser 11514 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> webuser 11569 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> (Ausgabe heftig postingfähig gestutzt)
>
> Doch, "overcommit" ist aktiv, aber 9GB firefox seh' ich da nicht.
> Gut, der läuft jetzt noch recht bescheiden, aber auch mit mehr Last
> habe ich noch kein Problem damit gesehen. Vielleicht ab >20 Tabs mal,
> aber das wär'mir dann doch zu unübersichtlich...
>
Stell für deinen User das Limit für as auf 8GB, dann solltest du das sehen.
>
> Du schriebst am Sun, 30 Oct 2022 11:13:34 +0100:
>
>> Aber doch nur der virtuelle Adressraum?
>> Firefox läuft gar nicht unter 9GB. Kannst du mit der limit.conf
>> testen, startet dann nur mit leerem Fenster.
>
> Was schreibst Du da?
> $ free
> total used free shared buff/cache available
> Mem: 7548368 2188952 731332 29312 4628084 488824
> Swap 17753772 10496 17743276
>
> $ ps aux | grep firefox
> webuser 11262 Sl 20:29 0:06 /usr/lib64/firefox/firefox -no-remote
> webuser 11355 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> webuser 11400 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> webuser 11444 Sl 20:29 0:05 /usr/lib64/firefox/firefox-bin -content...
> webuser 11492 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> webuser 11504 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> webuser 11514 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> webuser 11569 Sl 20:29 0:00 /usr/lib64/firefox/firefox-bin -content...
> (Ausgabe heftig postingfähig gestutzt)
>
> Doch, "overcommit" ist aktiv, aber 9GB firefox seh' ich da nicht.
> Gut, der läuft jetzt noch recht bescheiden, aber auch mit mehr Last
> habe ich noch kein Problem damit gesehen. Vielleicht ab >20 Tabs mal,
> aber das wär'mir dann doch zu unübersichtlich...
>
Tim
Bonita Montero
Oct 31, 2022, 2:48:02 AM10/31/22
to
Am 30.10.2022 um 23:24 schrieb Andreas Kohlbach:
> On Sun, 30 Oct 2022 10:56:33 +0100, Bonita Montero wrote:
>> Ich vermute mal, das macht gar keinen Sinn, denn der OOM-Killer greift
>> erst sehr spät nachdem angefangen wurde zu Swappen, und das sollte der
>> Zeitpunkt sein ab wo es unangenehm wird.
> Vielleicht geht es mir um Automatik: OMM könnte einen Task erkennen, der
> sich asozial verhält - und beenden. Sonst mache ich es. Das dauert aber
> mitunter lange, wenn es mir überhaupt gelingt.
Der OOM-Killer wird erst tätig wenn auch kein Swap mehr da ist.
Unangehem wird das Verhalten des Rechners aber sehr viel früher,
nämlich wenn der anfängt zu swappen.
Man könnte sich ein kleines Programm schreiben das perioodisch irgend-
wie /proc ausliest. Da stehen sicher Informationen über den Speicher
-Verbrauch drin. Und wenn eine Anwendung unter einem bestimmten Benut-
zer-Kontext zu viel tatsächlich comitteten Speicher verbrät, dann wird
die halt erst soft per Signal, also wie bei kill ohne -9, und wenn die
dann nicht reagiert hart, also wie bei kill mit -9, abgeschossen.
> On Sun, 30 Oct 2022 10:56:33 +0100, Bonita Montero wrote:
>> Ich vermute mal, das macht gar keinen Sinn, denn der OOM-Killer greift
>> erst sehr spät nachdem angefangen wurde zu Swappen, und das sollte der
>> Zeitpunkt sein ab wo es unangenehm wird.
> sich asozial verhält - und beenden. Sonst mache ich es. Das dauert aber
> mitunter lange, wenn es mir überhaupt gelingt.
Der OOM-Killer wird erst tätig wenn auch kein Swap mehr da ist.
Unangehem wird das Verhalten des Rechners aber sehr viel früher,
nämlich wenn der anfängt zu swappen.
Man könnte sich ein kleines Programm schreiben das perioodisch irgend-
wie /proc ausliest. Da stehen sicher Informationen über den Speicher
-Verbrauch drin. Und wenn eine Anwendung unter einem bestimmten Benut-
zer-Kontext zu viel tatsächlich comitteten Speicher verbrät, dann wird
die halt erst soft per Signal, also wie bei kill ohne -9, und wenn die
dann nicht reagiert hart, also wie bei kill mit -9, abgeschossen.
Bonita Montero
Oct 31, 2022, 2:54:44 AM10/31/22
to
Am 30.10.2022 um 11:13 schrieb Tim Ritberg:
> Aber doch nur der virtuelle Adressraum?
> Firefox läuft gar nicht unter 9GB. Kannst du mit der limit.conf testen,
> startet dann nur mit leerem Fenster.
Halt ich auch für Quatsch, dass Firefox per-se so viel RAM verbrät.
> Aber doch nur der virtuelle Adressraum?
> Firefox läuft gar nicht unter 9GB. Kannst du mit der limit.conf testen,
> startet dann nur mit leerem Fenster.
Bonita Montero
Oct 31, 2022, 2:56:39 AM10/31/22
to
Am 30.10.2022 um 20:16 schrieb Tim Ritberg:
> Am 30.10.22 um 16:53 schrieb Friedhelm Waitzmann:
> Am 30.10.22 um 16:53 schrieb Friedhelm Waitzmann:
>> Warum nicht die Größe von Prozessen begrenzen? Siehe prlimit(1)
>> und ulimit innerhalb von bash.
> Firefox und Chrome laufen dann gar nicht mehr.
Alles eine Frage welche Werte man einstellt.
>> und ulimit innerhalb von bash.
> Firefox und Chrome laufen dann gar nicht mehr.
Bonita Montero
Oct 31, 2022, 3:00:03 AM10/31/22
to
Am 30.10.2022 um 23:20 schrieb Andreas Kohlbach:
> LibreOffice braucht hier gerade (beim Idlen) 6.5 GB virtual. Das scheint
> hier normal.
Da darf man sich nicht täuschen, denn dieser virtuelle Speicher bein-
halltet ja auch Pages die zwar allokiert, aber nie geschrieben wurden,
d.h. wen das Overcommit an ist wird dafür nichtmal anteilig was vom
Swap abgehalten. Außerdem stecken in diesem virtuellen Speicher auch
gemappte Pages wie die des Executables und der Shared Objects, die
auch mit anderen Prozessen geteilt werden.
> LibreOffice braucht hier gerade (beim Idlen) 6.5 GB virtual. Das scheint
> hier normal.
Da darf man sich nicht täuschen, denn dieser virtuelle Speicher bein-
halltet ja auch Pages die zwar allokiert, aber nie geschrieben wurden,
d.h. wen das Overcommit an ist wird dafür nichtmal anteilig was vom
Swap abgehalten. Außerdem stecken in diesem virtuellen Speicher auch
gemappte Pages wie die des Executables und der Shared Objects, die
auch mit anderen Prozessen geteilt werden.
Tim Ritberg
Oct 31, 2022, 8:14:24 AM10/31/22
to
Am 31.10.22 um 07:54 schrieb Bonita Montero:
Nicht verbraten, reservieren.
Tim
Tim
Tim Ritberg
Oct 31, 2022, 8:15:14 AM10/31/22
to
Am 31.10.22 um 07:56 schrieb Bonita Montero:
Bei mir wollte Chrome sich direk beim Start 40GB reserviren im AS.
Tim
Tim
Friedhelm Waitzmann
Oct 31, 2022, 9:16:28 AM10/31/22
to
Tim Ritberg:
Bei mir läuft Firefox 102.4.0esr (32 Bit) mit den Softlimits
Data: 1572864 KiB
Stack: unlimited
Das System hat 2003 MiB Hauptspeicher und 8111 MiB Swap, und
Overcommittment ist strict: vm.overcommit_memory = 2
Data: 1572864 KiB
Stack: unlimited
Das System hat 2003 MiB Hauptspeicher und 8111 MiB Swap, und
Overcommittment ist strict: vm.overcommit_memory = 2
Bonita Montero
Oct 31, 2022, 11:14:19 AM10/31/22
to
ja nicht, denn wenn man das abgeschaltet hat würde das ja dazu führen,
dass bei jeder Allokation entsprechend viel vom Swap subtrahiert wird,
dass bei der erstmaligen Allokation der Page beim ersten Zugriff darauf
ggf. entsprechend Swap verfügbar ist falls die Page nicht direkt einer
freien physischen Page zugeordnet werden kann. Ich glaub ja nicht, dass
jemand so eine Käse programmiert.
Bonita Montero
Oct 31, 2022, 11:20:03 AM10/31/22
to
erlebt. Außerdem gibt es mehrere Interpretationen von "reservieren"
bzw. da bist Du sehr unscharf.
Friedemann Stoyan
Oct 31, 2022, 1:14:05 PM10/31/22
to
Peter J. Holzer wrote:
> Nein, der wird erst aktiv, wenn der Kernel keine freien Pages mehr
> findet (also RAM und Swap komplett voll sind).
> Es gibt allerdings den systemd-oomd, der das laufende System monitort
> und Prozesse killt, wenn die MemoryPressure zu hoch wird:
> https://www.man7.org/linux/man-pages/man8/systemd-oomd.8.html
> Wie gut das in der Praxis funktioniert, musst Du selber ausprobieren.
> Beachte insbesondere diesen Absatz:
>| Be aware that if you intend to enable monitoring and actions on
>| user.slice, user-$UID.slice, or their ancestor cgroups, it is
>| highly recommended that your programs be managed by the systemd
>| user manager to prevent running too many processes under the same
>| session scope (and thus avoid a situation where memory intensive
>| tasks trigger systemd-oomd to kill everything under the cgroup).
>| If you're using a desktop environment like GNOME, it already
>| spawns many session components with the systemd user manager.
> Du musst also herausfinden, ob Dein Desktop-Environment bereits den
> Browser und LibreOffice in einer eigenen CGroup startet, und wenn nicht,
> wie Du es dazu bringst, das zu tun. Sonst schießt Dir der systemd-oomd
> die ganze Session ab.
Ich starte hier™ den FF als transient Unit:
> Nein, der wird erst aktiv, wenn der Kernel keine freien Pages mehr
> findet (also RAM und Swap komplett voll sind).
> Es gibt allerdings den systemd-oomd, der das laufende System monitort
> und Prozesse killt, wenn die MemoryPressure zu hoch wird:
> https://www.man7.org/linux/man-pages/man8/systemd-oomd.8.html
> Wie gut das in der Praxis funktioniert, musst Du selber ausprobieren.
> Beachte insbesondere diesen Absatz:
>| Be aware that if you intend to enable monitoring and actions on
>| user.slice, user-$UID.slice, or their ancestor cgroups, it is
>| highly recommended that your programs be managed by the systemd
>| user manager to prevent running too many processes under the same
>| session scope (and thus avoid a situation where memory intensive
>| tasks trigger systemd-oomd to kill everything under the cgroup).
>| If you're using a desktop environment like GNOME, it already
>| spawns many session components with the systemd user manager.
> Du musst also herausfinden, ob Dein Desktop-Environment bereits den
> Browser und LibreOffice in einer eigenen CGroup startet, und wenn nicht,
> wie Du es dazu bringst, das zu tun. Sonst schießt Dir der systemd-oomd
> die ganze Session ab.
systemd-run --user --unit=firefox-user /usr/bin/firefox
Das sieht dann so aus:
$ systemctl --user status firefox-user.service --no-pager
● firefox-user.service - /usr/bin/firefox
Loaded: loaded (/run/user/1000/systemd/transient/firefox-user.service; transient)
Transient: yes
Active: active (running) since Mon 2022-10-31 17:56:15 CET; 15min ago
Main PID: 9453 (firefox)
Tasks: 317 (limit: 35980)
Memory: 613.2M
CPU: 1min 20.802s
CGroup: /user.slice/user-1000.slice/us...@1000.service/app.slice/firefox-user.service
├─ 9453 /usr/lib/firefox/firefox
├─ 9532 /usr/lib/firefox/firefox -contentproc -parentBuildID 20221025212237 -prefsLen 30732 -prefMapSize 237484 -appDir /usr/lib/firefox/browser {2512a642-8834-4394-9ca0-a1607769a961} 9453 true socket
├─ 9554 /usr/lib/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 30873 -prefMapSize 237484 -jsInitLen 246704 -parentBuildID 20221025212237 -appDir /usr/lib/firefox/browser {fc7bfeb4-1993-42ea-9820-bcccd98e0c3a}…
├─ 9601 /usr/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 36247 -prefMapSize 237484 -jsInitLen 246704 -parentBuildID 20221025212237 -appDir /usr/lib/firefox/browser {b338c5d0-a852-451d-85db-26c850d710ea}…
├─ 9657 /usr/lib/firefox/firefox -contentproc -childID 3 -isForBrowser -prefsLen 36306 -prefMapSize 237484 -jsInitLen 246704 -parentBuildID 20221025212237 -appDir /usr/lib/firefox/browser {9f707c06-3f06-4970-a5e6-b6e940da26e2}…
├─ 9660 /usr/lib/firefox/firefox -contentproc -childID 4 -isForBrowser -prefsLen 36306 -prefMapSize 237484 -jsInitLen 246704 -parentBuildID 20221025212237 -appDir /usr/lib/firefox/browser {2bdeb70a-127d-4423-8db2-e787dd767cc0}…
├─ 9763 /usr/lib/firefox/firefox -contentproc -childID 6 -isForBrowser -prefsLen 36387 -prefMapSize 237484 -jsInitLen 246704 -parentBuildID 20221025212237 -appDir /usr/lib/firefox/browser {333ef5c7-e8fd-4b32-a876-41315c1c8351}…
├─10048 /usr/lib/firefox/firefox -contentproc -childID 7 -isForBrowser -prefsLen 36462 -prefMapSize 237484 -jsInitLen 246704 -parentBuildID 20221025212237 -appDir /usr/lib/firefox/browser {4e6e2db9-4175-4fa4-b628-2a9d92aee495}…
├─10258 /usr/lib/firefox/firefox -contentproc -childID 8 -isForBrowser -prefsLen 36576 -prefMapSize 237484 -jsInitLen 246704 -parentBuildID 20221025212237 -appDir /usr/lib/firefox/browser {a5bc6177-ccf0-4e41-ad5f-656dd84097cc}…
└─10303 /usr/lib/firefox/firefox -contentproc -childID 9 -isForBrowser -prefsLen 36576 -prefMapSize 237484 -jsInitLen 246704 -parentBuildID 20221025212237 -appDir /usr/lib/firefox/browser {47611adf-9944-40fa-99e7-fd35cdbf32f5}…
Eventuell kann man das ja mit dem genannten systemd-oomd verheiraten.
mfg Friedemann
Tim Ritberg
Oct 31, 2022, 1:47:18 PM10/31/22
to
Am 31.10.22 um 16:14 schrieb Bonita Montero:
Ich habe 32GB Ram und hatte meinen User hard auf 30GB gesetzt, mit der
Idee dem OS ein bisschen überzulassen.
Chrome mag das gar nicht.
Tim
Idee dem OS ein bisschen überzulassen.
Chrome mag das gar nicht.
Tim
Tim Ritberg
Oct 31, 2022, 1:50:41 PM10/31/22
to
Am 31.10.22 um 16:20 schrieb Bonita Montero:
Ich hatte die Story auch in de.comp.os.unix.linux.misc erzählt
"limits.conf bringt Chrome durcheinander"
Enrik Berkhan schrieb:
"Dafür taugt dann der Ansatz mit dem "address space" limit für "moderne"
Software wohl nicht (mehr).
Ich habe mir das Verhalten von chrome bei mir nochmal angesehen: der
erzeugt einfach in jedem Prozess ziemlich am Anfang ein 32GB private
anonymous mapping. Deshalb braucht der soviel "address space". Belegter
Speicher ist das ja noch lange nicht. Weiter habe ich nicht geguckt. Es
gibt noch mehr solche Software, 'evolution' ist bei mir typischerweise
um die 100GB groß."
Tim
"limits.conf bringt Chrome durcheinander"
Enrik Berkhan schrieb:
"Dafür taugt dann der Ansatz mit dem "address space" limit für "moderne"
Software wohl nicht (mehr).
Ich habe mir das Verhalten von chrome bei mir nochmal angesehen: der
erzeugt einfach in jedem Prozess ziemlich am Anfang ein 32GB private
anonymous mapping. Deshalb braucht der soviel "address space". Belegter
Speicher ist das ja noch lange nicht. Weiter habe ich nicht geguckt. Es
gibt noch mehr solche Software, 'evolution' ist bei mir typischerweise
um die 100GB groß."
Tim
Sieghard Schicktanz
Oct 31, 2022, 5:13:11 PM10/31/22
to
Hallo Tim,
Du schriebst am Sun, 30 Oct 2022 23:02:43 +0100:
> > Doch, "overcommit" ist aktiv, aber 9GB firefox seh' ich da nicht.
Und warum, wenn ich eh nur 8GB in der Kiste drin habe?
Allenfalls könnte ich jetzt drüber schimpfen, daß der firefox offenbar
darauf aufgebaut ist, sich dank overcommit als "Speicherschwein"
gebärden zu dürfen und keine Rücksicht darauf nehmen zu müssen - und
auch nicht zu wollen - daß auch noch anderes auf "seiner" Maschine
laufen könnte.
_Eigentlich_ ein gutes Argument dafür, sich einen anderen Browser zu
suchen, der keine solchen Ansprüche stellt - nur, gibt's so einen?
Außer einem Text-Mode-Browser, natürlich.
Aber offenbar ist in _der_ "Community" die Grundeinstellung "wer
braucht schon was anderes als einen internet-Browser"? Saubande.
Du schriebst am Sun, 30 Oct 2022 23:02:43 +0100:
> > Doch, "overcommit" ist aktiv, aber 9GB firefox seh' ich da nicht.
...
> Stell für deinen User das Limit für as auf 8GB, dann solltest du das
> sehen.
Limit für _was_? "as"? Was soll das sein?
> Stell für deinen User das Limit für as auf 8GB, dann solltest du das
> sehen.
Und warum, wenn ich eh nur 8GB in der Kiste drin habe?
Allenfalls könnte ich jetzt drüber schimpfen, daß der firefox offenbar
darauf aufgebaut ist, sich dank overcommit als "Speicherschwein"
gebärden zu dürfen und keine Rücksicht darauf nehmen zu müssen - und
auch nicht zu wollen - daß auch noch anderes auf "seiner" Maschine
laufen könnte.
_Eigentlich_ ein gutes Argument dafür, sich einen anderen Browser zu
suchen, der keine solchen Ansprüche stellt - nur, gibt's so einen?
Außer einem Text-Mode-Browser, natürlich.
Aber offenbar ist in _der_ "Community" die Grundeinstellung "wer
braucht schon was anderes als einen internet-Browser"? Saubande.
Peter J. Holzer
Oct 31, 2022, 6:56:32 PM10/31/22
to
On 2022-10-31 15:20, Bonita Montero <Bonita....@gmail.com> wrote:
> Am 31.10.2022 um 13:14 schrieb Tim Ritberg:
>> Am 31.10.22 um 07:54 schrieb Bonita Montero:
>>> Am 30.10.2022 um 11:13 schrieb Tim Ritberg:
>>>> Aber doch nur der virtuelle Adressraum?
>>>> Firefox läuft gar nicht unter 9GB. Kannst du mit der limit.conf
>>>> testen, startet dann nur mit leerem Fenster.
>
>>> Halt ich auch für Quatsch, dass Firefox per-se so viel RAM verbrät.
>
>> Nicht verbraten, reservieren.
>
> Ich glaub's einfach nicht,
Du musst es nicht glauben. Probiers einfach aus:
> Am 31.10.2022 um 13:14 schrieb Tim Ritberg:
>> Am 31.10.22 um 07:54 schrieb Bonita Montero:
>>> Am 30.10.2022 um 11:13 schrieb Tim Ritberg:
>>>> Aber doch nur der virtuelle Adressraum?
>>>> Firefox läuft gar nicht unter 9GB. Kannst du mit der limit.conf
>>>> testen, startet dann nur mit leerem Fenster.
>
>>> Halt ich auch für Quatsch, dass Firefox per-se so viel RAM verbrät.
>
>> Nicht verbraten, reservieren.
>
> Ich glaub's einfach nicht,
Auf einem Ubuntu 22.04:
Mit "limit addressspace 15G"[1] erscheinen schon ein paar Meldungen
"os_mmap failed.: Cannot allocate memory" im Terminal, aber er scheint
noch problemlos zu funktionieren (mit ein paar eher wenig
anspruchsvollen Websites oberflächlich getestet).
Mit "limit addressspace 14G" bleibt er nach dem ersten "os_mmap failed.:
Cannot allocate memory" hat das Fenster vom ProfileManager[2]
schätzungsweise 1x1 Pixel und reagiert nicht.
> bzw. das hab ich so bei Firefox noch nicht erlebt.
Desktop-System schon?
> Außerdem gibt es mehrere Interpretationen von "reservieren" bzw. da
> bist Du sehr unscharf.
funktioniert, ist ziemlich klar, was er meint.
hp
[1] zsh-Syntax. Für die von Dir bevorzugte Shell bitte selber nachsehen
[2] Ich habe mehrere Profile und starte den FF daher immer mit -profileManager
Peter J. Holzer
Oct 31, 2022, 7:02:44 PM10/31/22
to
On 2022-10-30 22:24, Andreas Kohlbach <a...@spamfence.net> wrote:
> Vielleicht geht es mir um Automatik: OMM könnte einen Task erkennen, der
> sich asozial verhält - und beenden.
Ja, aber es ist halt ein "Out of Memory Killer" und kein "Asocial Task
> Vielleicht geht es mir um Automatik: OMM könnte einen Task erkennen, der
> sich asozial verhält - und beenden.
Killer", Es steht Dir frei, einen atkd zu schreiben :-).
hp
Peter J. Holzer
Oct 31, 2022, 7:09:16 PM10/31/22
to
On 2022-10-30 22:27, Andreas Kohlbach <a...@spamfence.net> wrote:
> Meine Frage kam, da ich mich erinnerte, dass Linux in der Vergangenheit
> (Jahrzehnt(e) her) durchaus asoziale Prozesse per OOM killte (fand
> Einträge dazu im Log).
Das hat der OOM-Killer aber immer erst gemacht - wie der Name schon sagt
- wenn das System Out of Memory war.
Kann sein, dass Du früher schneller in diese Situation gekommen bist.
Aber prinzipiell hat es auch früher schon Situationen gegeben, wo das
System stundenlang vor sich hin gethrasht hat (weil halt immer noch ein
bisschen Speicher vorhanden war) und es gibt heute immer noch
Situationen wo es innerhalb von Sekundenbruchteilen von "alles normal"
zu "OOM schlägt erbarmungslos zu" eskaliert.
> So wunderte ich zunächst, dass das nun nicht passiert.
Der OOM-Killer existiert und funktioniert nach wie vor. Aber er hat das
System nie zuverlässig vor Thrashing bewahrt und tut das wohl auch heute
noch nicht.
hp
> Meine Frage kam, da ich mich erinnerte, dass Linux in der Vergangenheit
> (Jahrzehnt(e) her) durchaus asoziale Prozesse per OOM killte (fand
> Einträge dazu im Log).
Das hat der OOM-Killer aber immer erst gemacht - wie der Name schon sagt
- wenn das System Out of Memory war.
Kann sein, dass Du früher schneller in diese Situation gekommen bist.
Aber prinzipiell hat es auch früher schon Situationen gegeben, wo das
System stundenlang vor sich hin gethrasht hat (weil halt immer noch ein
bisschen Speicher vorhanden war) und es gibt heute immer noch
Situationen wo es innerhalb von Sekundenbruchteilen von "alles normal"
zu "OOM schlägt erbarmungslos zu" eskaliert.
> So wunderte ich zunächst, dass das nun nicht passiert.
Der OOM-Killer existiert und funktioniert nach wie vor. Aber er hat das
System nie zuverlässig vor Thrashing bewahrt und tut das wohl auch heute
noch nicht.
hp
Helmut Waitzmann
Oct 31, 2022, 8:55:21 PM10/31/22
to
Marcel Mueller <news.5...@spamgourmet.org>:
> Am 30.10.22 um 01:28 schrieb Andreas Kohlbach:
>> ein Programm (in der Regel einer der Browser, oder LibreOffice)
>> Amok läuft, dass zeitweise auch die Uhr in der GUI stehen
>> bleibt (zeigt hier auch Sekunden an, sodass das auffällt), oft
>> auch die Maus einfriert. Ich warte dann, um auf eine TTY zu
>> wechseln, top aufzurufen (was mitunter Minuten dauert, bis top
>> startet), und den Speicher-Hog abzuschießen.
>
> Interessant. Ich habe hier auch 8GB, sogar auf mehreren Kisten
> in der VM sogar nur 6GB, aber das ist noch nicht passiert. Außer
> in der VM bekomme ich den Speicher nicht annäherungsweise voll.
> Allerdings hatte ich an der Arbeit unter Win kürzlich mehrfach
> so ein Problem. Da waren innerhalb von 2 Tagen 38GB
> Speicherlast. Ich konnte den Schuldigen nicht identifizieren,
> aber Firefox war zumindest auf Verdächtigen-Liste. Sollte da
> eine matschige Version im Umlauf gewesen sein?
>
>
>> Da ich diesen Hog eh abschieße, könnte das eh gleich OOM machen. Das
>> Programm dazu heißt vermutlich choom (lese mich gerade ein).
>
> Ich glaube, das ist nur, um das Verhalten bei /laufenden/
> Prozessen zu ändern.
>
[OOM‐Killer]
> Außerdem ist das auch ein Kernel-Feature. Ich glaube gar nicht,
> dass man das abschalten kann, außer indem man Overcommit
> komplett deaktiviert, was unter x64 keine gute Idee ist.
Inwiefern ist, Overcommit abzuschalten, also
printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
oder ein vergleichbares Kommando laufen zu lassen, bei X64 keine
gute Idee? Wenn Overcommit abgeschaltet ist, kann kein Prozess
mehr virtuellen Speicher anfordern, als das System noch frei
hat. Für Speicherfresser bedeutet das, dass gleich der
Systemaufruf, der den Speicher reserviert, scheitert und das
System gar nicht erst in einen Zustand gerät, in dem es den den
Prozessen versprochenen virtuellen Speicher nicht liefern kann,
weil es zuvor geschwindelt hat.
Ich halte das für besser als den Fall, dass der OOM‐Killer die
Runde machen muss und schauen, wen er per KILL‐Signal umbringt:
Ein Prozess kann auf einen scheiternden Systemaufruf zur
Speicherreservierung reagieren und Maßnahmen ergreifen: seine von
ihm angelegten Dateien in einen konsistenten Zustand bringen und
sich beenden.
Wenn ein Prozess hingegen ein KILL‐Signal erhält, kann er nicht
mehr reagieren. Sind seine Zustandsdateien zum Zeitpunkt des
Signalerhalts in inkonsistentem Zustand, bleiben sie es auch,
wenn der Prozess abgeschossen ist.
> Aber ich denke die mit Abstand sinnvollste Methode ist, die
> Größe des Swap auf sinnvolle Werte zu begrenzen. Bei Linux ist
> ein bisschen blöd, dass Swap auch für Hibernate herhalten muss.
> Dadurch kann man es nicht beliebig klein machen.
Mach den Swap so groß, wie du virtuellen Speicher brauchst
(beispielsweise genau so groß wie Hauptspeicher verbaut ist,
falls du willst, dass keine Swap‐Orgien auftreten können), und
stell dann das memory overcommit ratio auf 0:
printf '%s\n' 'vm.overcommit_ratio=0' | sysctl -p -
Dann zählt das System den Hauptspeicher nicht zum verfügbaren
Speicher dazu (verwendet ihn aber natürlich trotzdem) und gibt
deshalb nicht mehr Virtuellspeicher heraus als Swap vorhanden
ist. Auf diese Weise passt dann auch beim Winterschlaf
(hibernation) der ganze Virtuellspeicherinhalt in den Swap rein.
> Am 30.10.22 um 01:28 schrieb Andreas Kohlbach:
>> OOM scheint bei Mint schon länger Default deaktiviert zu sein.
>>
>>
>> Es passiert mir trotz meiner üppigen *hüstel* 8 GB RAM, dass
>>
>>
>> ein Programm (in der Regel einer der Browser, oder LibreOffice)
>> Amok läuft, dass zeitweise auch die Uhr in der GUI stehen
>> bleibt (zeigt hier auch Sekunden an, sodass das auffällt), oft
>> auch die Maus einfriert. Ich warte dann, um auf eine TTY zu
>> wechseln, top aufzurufen (was mitunter Minuten dauert, bis top
>> startet), und den Speicher-Hog abzuschießen.
>
> Interessant. Ich habe hier auch 8GB, sogar auf mehreren Kisten
> in der VM sogar nur 6GB, aber das ist noch nicht passiert. Außer
> in der VM bekomme ich den Speicher nicht annäherungsweise voll.
> Allerdings hatte ich an der Arbeit unter Win kürzlich mehrfach
> so ein Problem. Da waren innerhalb von 2 Tagen 38GB
> Speicherlast. Ich konnte den Schuldigen nicht identifizieren,
> aber Firefox war zumindest auf Verdächtigen-Liste. Sollte da
> eine matschige Version im Umlauf gewesen sein?
>
>
>> Da ich diesen Hog eh abschieße, könnte das eh gleich OOM machen. Das
>> Programm dazu heißt vermutlich choom (lese mich gerade ein).
>
> Ich glaube, das ist nur, um das Verhalten bei /laufenden/
> Prozessen zu ändern.
>
[OOM‐Killer]
> Außerdem ist das auch ein Kernel-Feature. Ich glaube gar nicht,
> dass man das abschalten kann, außer indem man Overcommit
> komplett deaktiviert, was unter x64 keine gute Idee ist.
Inwiefern ist, Overcommit abzuschalten, also
printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
oder ein vergleichbares Kommando laufen zu lassen, bei X64 keine
gute Idee? Wenn Overcommit abgeschaltet ist, kann kein Prozess
mehr virtuellen Speicher anfordern, als das System noch frei
hat. Für Speicherfresser bedeutet das, dass gleich der
Systemaufruf, der den Speicher reserviert, scheitert und das
System gar nicht erst in einen Zustand gerät, in dem es den den
Prozessen versprochenen virtuellen Speicher nicht liefern kann,
weil es zuvor geschwindelt hat.
Ich halte das für besser als den Fall, dass der OOM‐Killer die
Runde machen muss und schauen, wen er per KILL‐Signal umbringt:
Ein Prozess kann auf einen scheiternden Systemaufruf zur
Speicherreservierung reagieren und Maßnahmen ergreifen: seine von
ihm angelegten Dateien in einen konsistenten Zustand bringen und
sich beenden.
Wenn ein Prozess hingegen ein KILL‐Signal erhält, kann er nicht
mehr reagieren. Sind seine Zustandsdateien zum Zeitpunkt des
Signalerhalts in inkonsistentem Zustand, bleiben sie es auch,
wenn der Prozess abgeschossen ist.
> Aber ich denke die mit Abstand sinnvollste Methode ist, die
> ein bisschen blöd, dass Swap auch für Hibernate herhalten muss.
> Dadurch kann man es nicht beliebig klein machen.
Mach den Swap so groß, wie du virtuellen Speicher brauchst
(beispielsweise genau so groß wie Hauptspeicher verbaut ist,
falls du willst, dass keine Swap‐Orgien auftreten können), und
stell dann das memory overcommit ratio auf 0:
printf '%s\n' 'vm.overcommit_ratio=0' | sysctl -p -
Dann zählt das System den Hauptspeicher nicht zum verfügbaren
Speicher dazu (verwendet ihn aber natürlich trotzdem) und gibt
deshalb nicht mehr Virtuellspeicher heraus als Swap vorhanden
ist. Auf diese Weise passt dann auch beim Winterschlaf
(hibernation) der ganze Virtuellspeicherinhalt in den Swap rein.
Rolf Buenning
Nov 1, 2022, 2:33:05 AM11/1/22
to
Friedemann Stoyan <use...@ip6-mail.de> schrieb:
Was hat das für Vorteile gegenüber dem *normalen* Starten des Browsers?
Gruß Rolf
> Ich starte hier™ den FF als transient Unit:
>
> systemd-run --user --unit=firefox-user /usr/bin/firefox
Hallo!
>
> systemd-run --user --unit=firefox-user /usr/bin/firefox
Was hat das für Vorteile gegenüber dem *normalen* Starten des Browsers?
Gruß Rolf
Bonita Montero
Nov 1, 2022, 3:04:33 AM11/1/22
to
Am 31.10.2022 um 18:47 schrieb Tim Ritberg:
> Am 31.10.22 um 16:14 schrieb Bonita Montero:
> Am 31.10.22 um 16:14 schrieb Bonita Montero:
>> Theoretisch im Rahmen von Overcommitting denkbar, aber ich glaub's
>> ja nicht, denn wenn man das abgeschaltet hat würde das ja dazu führen,
>> dass bei jeder Allokation entsprechend viel vom Swap subtrahiert wird,
>> dass bei der erstmaligen Allokation der Page beim ersten Zugriff darauf
>> ggf. entsprechend Swap verfügbar ist falls die Page nicht direkt einer
>> freien physischen Page zugeordnet werden kann. Ich glaub ja nicht, dass
>> jemand so eine Käse programmiert.
> Ich habe 32GB Ram und hatte meinen User hard auf 30GB gesetzt,
> mit der Idee dem OS ein bisschen überzulassen.
> Chrome mag das gar nicht.
Ich halt's einfach nicht für plausibel, dass Chrome per-se so viel RAM
>> ja nicht, denn wenn man das abgeschaltet hat würde das ja dazu führen,
>> dass bei jeder Allokation entsprechend viel vom Swap subtrahiert wird,
>> dass bei der erstmaligen Allokation der Page beim ersten Zugriff darauf
>> ggf. entsprechend Swap verfügbar ist falls die Page nicht direkt einer
>> freien physischen Page zugeordnet werden kann. Ich glaub ja nicht, dass
>> jemand so eine Käse programmiert.
> Ich habe 32GB Ram und hatte meinen User hard auf 30GB gesetzt,
> mit der Idee dem OS ein bisschen überzulassen.
> Chrome mag das gar nicht.
verbrät.
Bonita Montero
Nov 1, 2022, 3:07:01 AM11/1/22
to
Am 31.10.2022 um 18:50 schrieb Tim Ritberg:
> Ich habe mir das Verhalten von chrome bei mir nochmal angesehen: der
> erzeugt einfach in jedem Prozess ziemlich am Anfang ein 32GB private
> anonymous mapping. ...
> Ich habe mir das Verhalten von chrome bei mir nochmal angesehen: der
> erzeugt einfach in jedem Prozess ziemlich am Anfang ein 32GB private
Das wäre theoretisch möglich, aber ich halte das für nicht plausibel
weil ein Pooling für Funktionen wie malloc() / oder den new-Operator
in den Dimensionen keinen Sinn ergibt. Außerdem wäre das auf Rechnern
gefährlich wo das Overcommit aus ist und nicht entsprechend viel bei
solch einer Reservierung vom Swap abgehalten wird.
> Deshalb braucht der soviel "address space". Belegter Speicher ist das
> ja noch lange nicht. Weiter habe ich nicht geguckt. Es gibt noch mehr
> solche Software, 'evolution' ist bei mir typischerweise um die 100GB
> groß."
Bonita Montero
Nov 1, 2022, 3:09:16 AM11/1/22
to
Am 31.10.2022 um 23:56 schrieb Peter J. Holzer:
> Vielleicht, weil Du keine Resource-Limits setzt? Wer tut das auf einem
> Desktop-System schon?
Das Resource-Limit greift an der Stelle sowieso nicht weil da ja auf
> Vielleicht, weil Du keine Resource-Limits setzt? Wer tut das auf einem
> Desktop-System schon?
physisch allokierem Speicher zählt, und nicht nur dem was einfach nur
reserviert ist, also Pages die man "allokiert" hat, wo aber noch kein
schreibender Zugriff erfolgt ist.
> Wenn man ungefähr weiß, wie die Speicherverwaltung von Linux
> funktioniert, ist ziemlich klar, was er meint.
Bonita Montero
Nov 1, 2022, 3:12:45 AM11/1/22
to
Am 30.10.2022 um 08:26 schrieb Marcel Mueller:
> ..., außer indem man Overcommit komplett deaktiviert,
> was unter x64 keine gute Idee ist. ...
Wenn man genug Swap vorhält sollte das kein Problem sein. Der wird
dann ja nicht tatsächlich angefasst, sondern es wird nur für jede
Reservierung entsprechend davon subtrahiert. Solaris handhabt das
immer so, d.h. wenn man mit stark fork()enden Anwendungen arbeitet
(gibt's zum Glück immer weniger), dann muss man ggf. eine Menge
Swap vorhalten.
> ..., außer indem man Overcommit komplett deaktiviert,
> was unter x64 keine gute Idee ist. ...
Wenn man genug Swap vorhält sollte das kein Problem sein. Der wird
dann ja nicht tatsächlich angefasst, sondern es wird nur für jede
Reservierung entsprechend davon subtrahiert. Solaris handhabt das
immer so, d.h. wenn man mit stark fork()enden Anwendungen arbeitet
(gibt's zum Glück immer weniger), dann muss man ggf. eine Menge
Swap vorhalten.
Bonita Montero
Nov 1, 2022, 3:22:06 AM11/1/22
to
Am 01.11.2022 um 00:57 schrieb Andreas Kohlbach:
> Memory vermeiden. War falsch gedacht.
Tut er ja auch, aber er setzt erst sehr viel später ein als
das System beginnt zu swappen.
> On Tue, 1 Nov 2022 00:09:14 +0100, Peter J. Holzer wrote:
>>
>> On 2022-10-30 22:27, Andreas Kohlbach <a...@spamfence.net> wrote:
>>> Meine Frage kam, da ich mich erinnerte, dass Linux in der Vergangenheit
>>> (Jahrzehnt(e) her) durchaus asoziale Prozesse per OOM killte (fand
>>> Einträge dazu im Log).
>>
>> Das hat der OOM-Killer aber immer erst gemacht - wie der Name schon sagt
>> - wenn das System Out of Memory war.
>
> Ich hatte angenommen, der Out Of Memery Killer will genau das Out Of
>>
>> On 2022-10-30 22:27, Andreas Kohlbach <a...@spamfence.net> wrote:
>>> Meine Frage kam, da ich mich erinnerte, dass Linux in der Vergangenheit
>>> (Jahrzehnt(e) her) durchaus asoziale Prozesse per OOM killte (fand
>>> Einträge dazu im Log).
>>
>> Das hat der OOM-Killer aber immer erst gemacht - wie der Name schon sagt
>> - wenn das System Out of Memory war.
>
> Memory vermeiden. War falsch gedacht.
Tut er ja auch, aber er setzt erst sehr viel später ein als
das System beginnt zu swappen.
Tim Ritberg
Nov 1, 2022, 5:20:54 AM11/1/22
to
Am 01.11.22 um 08:04 schrieb Bonita Montero:
https://github.com/google/tcmalloc/blob/master/docs/design.md
Bis etwa Mitte 2021 lief Chrome noch mit dem Limit. Dann haben sie was
geändert.
Tim
>
> Ich halt's einfach nicht für plausibel, dass Chrome per-se so viel RAM
> verbrät.
Das soll die Antwort sein:
> Ich halt's einfach nicht für plausibel, dass Chrome per-se so viel RAM
> verbrät.
https://github.com/google/tcmalloc/blob/master/docs/design.md
Bis etwa Mitte 2021 lief Chrome noch mit dem Limit. Dann haben sie was
geändert.
Tim
Ulli Horlacher
Nov 1, 2022, 5:40:43 AM11/1/22
to
Warum kein einfaches
echo vm.overcommit_memory=2 | sysctl -p -
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
echo vm.overcommit_memory=2 | sysctl -p -
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Friedemann Stoyan
Nov 1, 2022, 5:47:40 AM11/1/22
to
Rolf Buenning wrote:
> Was hat das für Vorteile gegenüber dem *normalen* Starten des Browsers?
Er läuft als eigene cgroup. Damit greifen alle Mechanismen, die es für cgroups
> Was hat das für Vorteile gegenüber dem *normalen* Starten des Browsers?
gibt. Ich dachte, das sei offensichtlich.
mfg Friedemann
Bonita Montero
Nov 1, 2022, 6:16:27 AM11/1/22
to
Speicherverwaltung aus und kenne die Architektur von TCMalloc, jemalloc
und mimalloc, die alle sehr ähnlich sind.
Für kleine Objekte runden die alle die Reservierungen auf die nächste
Zweier-Potenz auf, bis zur Größe von zwei Pages. Solche Allokierungen
finden in einem Pool statt der meines Wissens für alle drei Allokatoren
immer 2MB groß ist; auch wenn man größere Pools wählt, das liegt dann
ganz sicher nicht in den Größenordnungen, dass daraus von dir besagte
Reservierungen entstehen.
Für Objekte mittlerer Größe werden die Allokationen immer auf Page
-Größe aufgerundet und entsprechend vom Betriebssystem abgeholt und
bei der Freigabe wird das ggf. für eine spätere Wiederverwendung ge-
poolt. Das kann dann schon zu einer größeren Menge Speicher führen
der vorgehalten wird, aber dass passiert erst bei der Rückgabe, und
nicht von vorneherein. D.h. wenn die Anwendung fortlaufend Blöcke
mittlerer Größe reserviert und freigibt, dann kann es schon sein,
dass sich da was ansammelt, aber mich würde es wundern wenn das zu
derart großen Pools führt.
Allokationen über dem mittleren Limit werden immer beim Betriebssystem
abgeholt und direkt nach free() o.Ä. wieder freigegeben.
Von daher wäre so ein verhalten eher nicht durch einen derartigen
Allocator erklärbar.
Ich bin mir sicher, dass Du das Paper oben gar nicht gelesen hast.
Rolf Buenning
Nov 1, 2022, 6:18:14 AM11/1/22
to
Friedemann Stoyan <use...@ip6-mail.de> schrieb:
Sorry für die dumme Frage.
Ich bin nur ein Admin für meinen Privat-PC.
Ich lese hier (und woanders) um zu lernen, deshalb stelle ich
manchmal auch Fragen, wie diese.
Ich habe inzwischen über controlgroups, aka cgroups nachgelesen und
denke, das das für mich, ein PC, ein User, ohne Bedeutung ist.
Danke Rolf
Ich bin nur ein Admin für meinen Privat-PC.
Ich lese hier (und woanders) um zu lernen, deshalb stelle ich
manchmal auch Fragen, wie diese.
Ich habe inzwischen über controlgroups, aka cgroups nachgelesen und
denke, das das für mich, ein PC, ein User, ohne Bedeutung ist.
Danke Rolf
Tim Ritberg
Nov 1, 2022, 6:23:48 AM11/1/22
to
Am 01.11.22 um 10:47 schrieb Friedemann Stoyan:
Ich habs verstanden. Viellleicht ist das die Lösung für mein "Problem".
Ich möchte gerne OOM verhinder, weil der Kernel ja praktisch wild abschießt.
Ich hatte es lange über limits.conf auf RAM-2GB eingestellt, damit für
das OS etwas übring bleibt.
Tim
Ich möchte gerne OOM verhinder, weil der Kernel ja praktisch wild abschießt.
Ich hatte es lange über limits.conf auf RAM-2GB eingestellt, damit für
das OS etwas übring bleibt.
Tim
Bonita Montero
Nov 1, 2022, 6:28:51 AM11/1/22
to
Am 01.11.2022 um 11:23 schrieb Tim Ritberg:
> Ich habs verstanden. Viellleicht ist das die Lösung für mein "Problem".
> Ich möchte gerne OOM verhinder, weil der Kernel ja praktisch wild
> abschießt.
> Ich hatte es lange über limits.conf auf RAM-2GB eingestellt, damit für
> das OS etwas übring bleibt.
Die einzige Möglichkeit die dir bleibt ist dann, Overcommit abzuschal-
> Ich habs verstanden. Viellleicht ist das die Lösung für mein "Problem".
> Ich möchte gerne OOM verhinder, weil der Kernel ja praktisch wild
> abschießt.
> Ich hatte es lange über limits.conf auf RAM-2GB eingestellt, damit für
> das OS etwas übring bleibt.
ten. Das kann dazu führen, dass manche Programme sich selbst beenden
weil es nur noch sichere Allokationen gibt oder eine Anwendung sich
nicht fork()en kann.
Tim Ritberg
Nov 1, 2022, 6:51:33 AM11/1/22
to
Am 01.11.22 um 11:28 schrieb Bonita Montero:
WTF!
Evolution soll sich 100GB beim Start reinziehen wollen.
Das ist eine Fehlentwicklung!
Tim
>
> Die einzige Möglichkeit die dir bleibt ist dann, Overcommit abzuschal-
> ten. Das kann dazu führen, dass manche Programme sich selbst beenden
> weil es nur noch sichere Allokationen gibt oder eine Anwendung sich
> nicht fork()en kann.
>
Dann müsste ich wohl das Swapfile riesengroß machen.
> Die einzige Möglichkeit die dir bleibt ist dann, Overcommit abzuschal-
> ten. Das kann dazu führen, dass manche Programme sich selbst beenden
> weil es nur noch sichere Allokationen gibt oder eine Anwendung sich
> nicht fork()en kann.
>
WTF!
Evolution soll sich 100GB beim Start reinziehen wollen.
Das ist eine Fehlentwicklung!
Tim
Peter J. Holzer
Nov 1, 2022, 7:19:57 AM11/1/22
to
On 2022-11-01 09:40, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>> printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
>
> Warum kein einfaches
>
> echo vm.overcommit_memory=2 | sysctl -p -
Oder gar:
> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>> printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
>
> Warum kein einfaches
>
> echo vm.overcommit_memory=2 | sysctl -p -
sysctl vm.overcommit_memory=2
Ich habe in meinem Leben schon einigen bizarr umständlichen Code
gesehen, aber Helmuts Zeile hat einen Ehrenplatz verdient.
hp
Bonita Montero
Nov 1, 2022, 8:25:47 AM11/1/22
to
Am 01.11.2022 um 11:51 schrieb Tim Ritberg:
> Am 01.11.22 um 11:28 schrieb Bonita Montero:
>> Die einzige Möglichkeit die dir bleibt ist dann, Overcommit abzuschal-
>> ten. Das kann dazu führen, dass manche Programme sich selbst beenden
>> weil es nur noch sichere Allokationen gibt oder eine Anwendung sich
>> nicht fork()en kann.
> Dann müsste ich wohl das Swapfile riesengroß machen.
> ...
> Am 01.11.22 um 11:28 schrieb Bonita Montero:
>> Die einzige Möglichkeit die dir bleibt ist dann, Overcommit abzuschal-
>> ten. Das kann dazu führen, dass manche Programme sich selbst beenden
>> weil es nur noch sichere Allokationen gibt oder eine Anwendung sich
>> nicht fork()en kann.
> Dann müsste ich wohl das Swapfile riesengroß machen.
> Evolution soll sich 100GB beim Start reinziehen wollen.
> Das ist eine Fehlentwicklung!
Ich kann das ehrlich gesagt nicht glauben. Irgendwas musst Du bei der
> Das ist eine Fehlentwicklung!
Ermittlung dieses Wertes falsch machen. Wenn das wirklich so wäre, dann
wäre das auch dokumetiert; vielleicht hast Du ja nen Link und kannst
mich überzeugen.
Ich mein 100GB, das wären ja 10% einer 1TB SSD, ich mein das ist dann
für manche anteilig schon Kosten-relevant.
Tim Ritberg
Nov 1, 2022, 8:28:56 AM11/1/22
to
Am 01.11.22 um 13:25 schrieb Bonita Montero:
>
> Ich kann das ehrlich gesagt nicht glauben. Irgendwas musst Du bei der
> Ermittlung dieses Wertes falsch machen. Wenn das wirklich so wäre, dann
> wäre das auch dokumetiert; vielleicht hast Du ja nen Link und kannst
> mich überzeugen.
Das schrieb Enrik Berkhan 2021.
Tim
>
> Ich kann das ehrlich gesagt nicht glauben. Irgendwas musst Du bei der
> Ermittlung dieses Wertes falsch machen. Wenn das wirklich so wäre, dann
> wäre das auch dokumetiert; vielleicht hast Du ja nen Link und kannst
> mich überzeugen.
Tim
Bonita Montero
Nov 1, 2022, 9:22:38 AM11/1/22
to
Bernd Mayer
Nov 1, 2022, 9:25:08 AM11/1/22
to
Am 30.10.22 um 23:27 schrieb Andreas Kohlbach:
> On Sun, 30 Oct 2022 12:06:36 +0100, Peter J. Holzer wrote:
>>
>> On 2022-10-29 23:28, Andreas Kohlbach <a...@spamfence.net> wrote:
>
> [...]
>
Hallo,
hast Du dies hier schon berücksichtigt?
"Die Leistungseinstellungen von Firefox
Um die beste Geschwindigkeit und Zuverlässigkeit zu erreichen, verwendet
Firefox automatisch die für Ihren Computer optimierten
Leistungseinstellungen. Sie können diese in Ihren Firefox-Einstellungen
ändern."
https://support.mozilla.org/de/kb/firefox-leistungseinstellungen?as=u&utm_source=inproduct
Bernd Mayer
> On Sun, 30 Oct 2022 12:06:36 +0100, Peter J. Holzer wrote:
>>
>> On 2022-10-29 23:28, Andreas Kohlbach <a...@spamfence.net> wrote:
>
> [...]
>
>>> Es passiert mir trotz meiner üppigen *hüstel* 8 GB RAM, dass ein Programm
>>> (in der Regel einer der Browser, oder LibreOffice) Amok läuft, dass
>>> zeitweise auch die Uhr in der GUI stehen bleibt (zeigt hier auch Sekunden
>>> an, sodass das auffällt), oft auch die Maus einfriert. Ich warte dann, um
>>> auf eine TTY zu wechseln, top aufzurufen (was mitunter Minuten dauert,
>>> bis top startet), und den Speicher-Hog abzuschießen.
>>>
>
> Danke, auch an die anderen. Aber dann lasse ich es, wie es ist.
>>> Es passiert mir trotz meiner üppigen *hüstel* 8 GB RAM, dass ein Programm
>>> (in der Regel einer der Browser, oder LibreOffice) Amok läuft, dass
>>> zeitweise auch die Uhr in der GUI stehen bleibt (zeigt hier auch Sekunden
>>> an, sodass das auffällt), oft auch die Maus einfriert. Ich warte dann, um
>>> auf eine TTY zu wechseln, top aufzurufen (was mitunter Minuten dauert,
>>> bis top startet), und den Speicher-Hog abzuschießen.
>>>
>
>
Hallo,
hast Du dies hier schon berücksichtigt?
"Die Leistungseinstellungen von Firefox
Um die beste Geschwindigkeit und Zuverlässigkeit zu erreichen, verwendet
Firefox automatisch die für Ihren Computer optimierten
Leistungseinstellungen. Sie können diese in Ihren Firefox-Einstellungen
ändern."
https://support.mozilla.org/de/kb/firefox-leistungseinstellungen?as=u&utm_source=inproduct
Bernd Mayer
Bonita Montero
Nov 1, 2022, 9:32:18 AM11/1/22
to
gung vermehrt genutzt wird, und das wirkt sich sicher in dem diskutier-
ten Maße auf den Speicher-Verbrauch aus.
Tim Ritberg
Nov 1, 2022, 10:20:24 AM11/1/22
to
Am 01.11.22 um 14:22 schrieb Bonita Montero:
> Ich habe mal strace laufen lassen, noch mit dem gesetzten Limit:
>
> 382366:mmap(0x219c00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382366:mmap(0x219c00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382367:mmap(0x210400000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> log.txt.382367:mmap(0x210400000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382407:mmap(0x1bfc00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382407:mmap(0x1bfc00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382412:mmap(0x329c00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382412:mmap(0x329c00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
>
> Der Output ist von allen Forks.
(Chrome)
Jetzt weisst, was er gemacht hat.
Tim
>
> 382366:mmap(0x219c00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382366:mmap(0x219c00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382367:mmap(0x210400000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> log.txt.382367:mmap(0x210400000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382407:mmap(0x1bfc00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382407:mmap(0x1bfc00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382412:mmap(0x329c00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> 382412:mmap(0x329c00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
>
> Der Output ist von allen Forks.
(Chrome)
Jetzt weisst, was er gemacht hat.
Tim
Bonita Montero
Nov 1, 2022, 10:41:36 AM11/1/22
to
Insofern kann da nix allokiert worden sein.
Tim Ritberg
Nov 1, 2022, 10:48:47 AM11/1/22
to
Am 01.11.22 um 15:41 schrieb Bonita Montero:
>
> Naja, das beweist ja nur den Versuch, letztlich hat's ja ENOMEM gegeben.
> Insofern kann da nix allokiert worden sein.
>
Was stellst du dich eigentlich so an?
Stell das AS-limit hart auf 30GB und starte Chrome!
Stell das AS-limit hart auf 8GB und starte FF!
Tim
>
> Naja, das beweist ja nur den Versuch, letztlich hat's ja ENOMEM gegeben.
> Insofern kann da nix allokiert worden sein.
>
Stell das AS-limit hart auf 30GB und starte Chrome!
Stell das AS-limit hart auf 8GB und starte FF!
Tim
Laurenz Trossel
Nov 1, 2022, 11:00:43 AM11/1/22
to
On 2022-11-01, Tim Ritberg <t...@server.invalid> wrote:
> Ich habe mal strace laufen lassen, noch mit dem gesetzten Limit:
>> 382366:mmap(0x219c00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> Ich habe mal strace laufen lassen, noch mit dem gesetzten Limit:
>> 382366:mmap(0x219c00000000, 34359738368, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM
> Jetzt weisst, was er gemacht hat.
Ein mmap ist noch keine Allokation. Wenn du den virtuellen Adressraum
einschränkst, schiesst du dir nur selber in den Fuss.
Bonita Montero
Nov 1, 2022, 11:03:00 AM11/1/22
to
kein Prozess zu viel Speicher oder swappt. Dass passiert nur wenn
die entsprechenden Pages auch geschrieben wurden.
Bonita Montero
Nov 1, 2022, 11:04:04 AM11/1/22
to
bezeichnen. Es wird ja entsprechend Swapspace subtrahiert, auch
wenn das passiert ohne, dass der auch dafür angefasst werden muss.
Enrik Berkhan
Nov 1, 2022, 11:13:05 AM11/1/22
to
... habe ich damals geschrieben.
Tim Ritberg
Nov 1, 2022, 11:39:10 AM11/1/22
to
Am 01.11.22 um 16:08 schrieb Enrik Berkhan:
Ach, da issa ja!
Du hattest mir auch den guthub-Link gegeben und auf den letzten Absatz
gezeigt:
"It is worth noting that TCMalloc requests memory from the OS in large
chunks (typically 1 GiB regions). The address space is reserved, but not
backed by physical memory until it is used. Because of this approach the
VSS of the application can be substantially larger than the RSS. A side
effect of this is that trying to limit an application's memory use by
restricting VSS will fail long before the application has used that much
physical memory."
Tim
Du hattest mir auch den guthub-Link gegeben und auf den letzten Absatz
gezeigt:
"It is worth noting that TCMalloc requests memory from the OS in large
chunks (typically 1 GiB regions). The address space is reserved, but not
backed by physical memory until it is used. Because of this approach the
VSS of the application can be substantially larger than the RSS. A side
effect of this is that trying to limit an application's memory use by
restricting VSS will fail long before the application has used that much
physical memory."
Tim
Bonita Montero
Nov 1, 2022, 12:00:55 PM11/1/22
to
Am 01.11.2022 um 16:39 schrieb Tim Ritberg:
> "It is worth noting that TCMalloc requests memory from the OS in large
> chunks (typically 1 GiB regions). The address space is reserved, but not
> backed by physical memory until it is used. Because of this approach the
> VSS of the application can be substantially larger than the RSS. A side
> effect of this is that trying to limit an application's memory use by
> restricting VSS will fail long before the application has used that much
> physical memory."
Ist aber echt gefährlich was die da machen, denn wenn man das Overcommit
> "It is worth noting that TCMalloc requests memory from the OS in large
> chunks (typically 1 GiB regions). The address space is reserved, but not
> backed by physical memory until it is used. Because of this approach the
> VSS of the application can be substantially larger than the RSS. A side
> effect of this is that trying to limit an application's memory use by
> restricting VSS will fail long before the application has used that much
> physical memory."
abschaltet ist man schnell der Blöde, denn wenn dann nicht genügend Swap
da ist, schlagen solche Allokationen unmittelbar fehl.
Helmut Waitzmann
Nov 1, 2022, 1:39:57 PM11/1/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de>:
müssen, dass ein Gleichheitszeichen im Shell in diesem Fall keine
Sonderbedeutung hat, und, dass «echo» bei diesem Parameter keine
Sonderbehandlung vornimmt.
Da ist mir ein einfaches «printf '%s\n'» statt «echo» und
ein einfaches «'…=…'» statt «…=…» lieber. Da sind irgendwelche
Fallstricke von «echo» und der Shell‐Kommandozeile von vorne
herein ausgeschlossen.
> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>
>> printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
>
> Warum kein einfaches
>
> echo vm.overcommit_memory=2 | sysctl -p -
>
Weil ich keine Lust habe, mich jedes Mal darüber versichern zu
>
>> printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
>
> Warum kein einfaches
>
> echo vm.overcommit_memory=2 | sysctl -p -
>
müssen, dass ein Gleichheitszeichen im Shell in diesem Fall keine
Sonderbedeutung hat, und, dass «echo» bei diesem Parameter keine
Sonderbehandlung vornimmt.
Da ist mir ein einfaches «printf '%s\n'» statt «echo» und
ein einfaches «'…=…'» statt «…=…» lieber. Da sind irgendwelche
Fallstricke von «echo» und der Shell‐Kommandozeile von vorne
herein ausgeschlossen.
Helmut Waitzmann
Nov 1, 2022, 1:39:58 PM11/1/22
to
"Peter J. Holzer" <hjp-u...@hjp.at>:
definiert ist. In Debian 10 lese ich zur Option «-w»:
SYNOPSIS
sysctl [options] [variable[=value]] [...]
sysctl -p [file or regexp] [...]
OPTIONS
-w, --write
Use this option when all arguments prescribe
a key to be set.
In Debian 6 hieß es noch:
SYNOPSIS
sysctl [-n] [-e] variable ...
sysctl [-n] [-e] [-q] -w variable=value ...
sysctl [-n] [-e] [-q] -p [filename]
sysctl [-n] [-e] -a
sysctl [-n] [-e] -A
-w Use this option when you want to
change a sysctl setting.
Die in Debian 10 bei der Beschreibung dieser Option genannte
Voraussetzung («all arguments prescribe a key to be set») liegt
in diesem Fall vor. Die in Debian 6 genannte Voraussetzung liegt
ebenfalls vor. Also müsste sie verwendet werden, oder etwa
nicht?
Ein weiterer Unterschied in beiden Fassungen ist die Art der
Option «-w»: Bei Debian 10 ist sie eine Option ohne Parameter.
Bei Debian 6 ist sie eine Option mit der Zuweisung als Parameter.
Da ich nicht weiß, welche Fassung von «sysctl» bei den Lesern
hier vorliegt, ziehe ich mich auf die Anwendungsart, die bei
beiden mir vorliegenden Fassungen zu funktionieren garantiert
wird, zurück: Die Option «-p» mit dem Optionenparameter «-»
lässt «sysctl» von seiner Standardeingabe lesen.
> Ich habe in meinem Leben schon einigen bizarr umständlichen Code
> gesehen, aber Helmuts Zeile hat einen Ehrenplatz verdient.
So ist das halt: Robustheit kommt oft umständlicher daher als
Schnellschüsse.
> On 2022-11-01 09:40, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>
>> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>>> printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
>>
>> Warum kein einfaches
>>
>> echo vm.overcommit_memory=2 | sysctl -p -
>
> Oder gar:
>
> sysctl vm.overcommit_memory=2
>
Da bin ich mir nicht sicher, ob das laut Handbuch überhaupt
>
>> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>>> printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
>>
>> Warum kein einfaches
>>
>> echo vm.overcommit_memory=2 | sysctl -p -
>
> Oder gar:
>
> sysctl vm.overcommit_memory=2
>
definiert ist. In Debian 10 lese ich zur Option «-w»:
SYNOPSIS
sysctl [options] [variable[=value]] [...]
sysctl -p [file or regexp] [...]
OPTIONS
-w, --write
Use this option when all arguments prescribe
a key to be set.
In Debian 6 hieß es noch:
SYNOPSIS
sysctl [-n] [-e] variable ...
sysctl [-n] [-e] [-q] -w variable=value ...
sysctl [-n] [-e] [-q] -p [filename]
sysctl [-n] [-e] -a
sysctl [-n] [-e] -A
-w Use this option when you want to
change a sysctl setting.
Die in Debian 10 bei der Beschreibung dieser Option genannte
Voraussetzung («all arguments prescribe a key to be set») liegt
in diesem Fall vor. Die in Debian 6 genannte Voraussetzung liegt
ebenfalls vor. Also müsste sie verwendet werden, oder etwa
nicht?
Ein weiterer Unterschied in beiden Fassungen ist die Art der
Option «-w»: Bei Debian 10 ist sie eine Option ohne Parameter.
Bei Debian 6 ist sie eine Option mit der Zuweisung als Parameter.
Da ich nicht weiß, welche Fassung von «sysctl» bei den Lesern
hier vorliegt, ziehe ich mich auf die Anwendungsart, die bei
beiden mir vorliegenden Fassungen zu funktionieren garantiert
wird, zurück: Die Option «-p» mit dem Optionenparameter «-»
lässt «sysctl» von seiner Standardeingabe lesen.
> Ich habe in meinem Leben schon einigen bizarr umständlichen Code
> gesehen, aber Helmuts Zeile hat einen Ehrenplatz verdient.
Schnellschüsse.
Helmut Waitzmann
Nov 1, 2022, 1:39:59 PM11/1/22
to
Bonita Montero <Bonita....@gmail.com>:
Braucht GPU‐Beschleunigung vermehrt Speicher oder spart sie
welchen ein?
welchen ein?
Bonita Montero
Nov 1, 2022, 2:25:18 PM11/1/22
to
dass dafür solch gigantische Mengen RAM allokiert werden müssen.
Bernd Mayer
Nov 1, 2022, 2:33:37 PM11/1/22
to
Am 01.11.22 um 18:30 schrieb Helmut Waitzmann:
Hallo,
die GPU hat ja auch eigenen Speicher.
Weiter steht da unten ja auch noch:
"Die Anzahl der Inhaltsprozesse können Sie zwischen 1 und 8 einstellen.
Die Standardeinstellung ist 8. Mehr Inhaltsprozesse verbessern die
Leistung bei Verwendung mehrerer Tabs, sie belegen aber auch mehr
Arbeitsspeicher. Sie können die Zahl der Inhaltsprozesse verringern,
wenn auf Ihrem Computer zu wenig Arbeitsspeicher vorhanden ist."
und:
"Tipp: Wenn die Systeminformationen Ihres Computers zeigen, dass mehr
als 8 GB Arbeitsspeicher installiert sind, profitieren Sie
wahrscheinlich von einer höheren maximalen Anzahl an Inhaltsprozessen."
Der OP liegt ja gerade an dieser Schwelle mit 8 GB.
Bernd Mayer
die GPU hat ja auch eigenen Speicher.
Weiter steht da unten ja auch noch:
"Die Anzahl der Inhaltsprozesse können Sie zwischen 1 und 8 einstellen.
Die Standardeinstellung ist 8. Mehr Inhaltsprozesse verbessern die
Leistung bei Verwendung mehrerer Tabs, sie belegen aber auch mehr
Arbeitsspeicher. Sie können die Zahl der Inhaltsprozesse verringern,
wenn auf Ihrem Computer zu wenig Arbeitsspeicher vorhanden ist."
und:
"Tipp: Wenn die Systeminformationen Ihres Computers zeigen, dass mehr
als 8 GB Arbeitsspeicher installiert sind, profitieren Sie
wahrscheinlich von einer höheren maximalen Anzahl an Inhaltsprozessen."
Der OP liegt ja gerade an dieser Schwelle mit 8 GB.
Bernd Mayer
Thomas Dorner
Nov 1, 2022, 3:08:03 PM11/1/22
to
"Peter J. Holzer" <hjp-u...@hjp.at> writes:
> Auf einem Ubuntu 22.04:
Firefox auf Ubuntu 22.04? Das ist doch dann ein Snap, oder? Bezieht
sich das Limit dann möglicherweise auf Firefox plus alles andere im Snap
zusammen?
Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!
> Auf einem Ubuntu 22.04:
Firefox auf Ubuntu 22.04? Das ist doch dann ein Snap, oder? Bezieht
sich das Limit dann möglicherweise auf Firefox plus alles andere im Snap
zusammen?
Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!
Ulli Horlacher
Nov 1, 2022, 6:59:01 PM11/1/22
to
Helmut Waitzmann <nn.th...@xoxy.net> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de>:
>> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>>
>>> printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
>>
>> Warum kein einfaches
>>
>> echo vm.overcommit_memory=2 | sysctl -p -
>>
>
> Weil ich keine Lust habe, mich jedes Mal darüber versichern zu
> müssen, dass ein Gleichheitszeichen im Shell in diesem Fall keine
> Sonderbedeutung hat
In welcher Shell ist ein Gleichheitszeichen ein Metazeichen?
> Ulli Horlacher <fram...@rus.uni-stuttgart.de>:
>> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>>
>>> printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
>>
>> Warum kein einfaches
>>
>> echo vm.overcommit_memory=2 | sysctl -p -
>>
>
> Weil ich keine Lust habe, mich jedes Mal darüber versichern zu
> müssen, dass ein Gleichheitszeichen im Shell in diesem Fall keine
> Sonderbedeutung hat
Ich lerne gerne dazu :-)
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
Jens Schüßler
Nov 1, 2022, 7:00:18 PM11/1/22
to
* Helmut Waitzmann <nn.th...@xoxy.net> [01-11-22 17:23]:
Sonst noch aktuelle Erkenntnisse, zb. wie das in Win3.11 geregelt wird?
>
> OPTIONS
> -w, --write
> Use this option when all arguments prescribe
> a key to be set.
>
>
> In Debian 6 hieß es noch:
>
>
> SYNOPSIS
> sysctl [-n] [-e] variable ...
> sysctl [-n] [-e] [-q] -w variable=value ...
> sysctl [-n] [-e] [-q] -p [filename]
> sysctl [-n] [-e] -a
> sysctl [-n] [-e] -A
>
> -w Use this option when you want to
> change a sysctl setting.
>
>
> Die in Debian 10 bei der Beschreibung dieser Option genannte
> Voraussetzung («all arguments prescribe a key to be set») liegt
> in diesem Fall vor. Die in Debian 6 genannte Voraussetzung liegt
> ebenfalls vor. Also müsste sie verwendet werden, oder etwa
> nicht?
Debian Squeeze, 2011, nur um ein Argument nicht zu verlieren. Köstlich.
> OPTIONS
> -w, --write
> Use this option when all arguments prescribe
> a key to be set.
>
>
> In Debian 6 hieß es noch:
>
>
> SYNOPSIS
> sysctl [-n] [-e] variable ...
> sysctl [-n] [-e] [-q] -w variable=value ...
> sysctl [-n] [-e] [-q] -p [filename]
> sysctl [-n] [-e] -a
> sysctl [-n] [-e] -A
>
> -w Use this option when you want to
> change a sysctl setting.
>
>
> Die in Debian 10 bei der Beschreibung dieser Option genannte
> Voraussetzung («all arguments prescribe a key to be set») liegt
> in diesem Fall vor. Die in Debian 6 genannte Voraussetzung liegt
> ebenfalls vor. Also müsste sie verwendet werden, oder etwa
> nicht?
Sonst noch aktuelle Erkenntnisse, zb. wie das in Win3.11 geregelt wird?
Peter J. Holzer
Nov 1, 2022, 8:32:49 PM11/1/22
to
On 2022-11-01 18:38, Thomas Dorner <de.comp.os.unix.linu...@spamgourmet.com> wrote:
> "Peter J. Holzer" <hjp-u...@hjp.at> writes:
>> Auf einem Ubuntu 22.04:
>
> Firefox auf Ubuntu 22.04? Das ist doch dann ein Snap, oder?
Ja.
> "Peter J. Holzer" <hjp-u...@hjp.at> writes:
>> Auf einem Ubuntu 22.04:
>
> Firefox auf Ubuntu 22.04? Das ist doch dann ein Snap, oder?
> Bezieht sich das Limit dann möglicherweise auf Firefox plus alles
> andere im Snap zusammen?
Das ist auch ein Grund, warum sie in der Praxis wenig hilfreich sind.
hp
Helmut Waitzmann
Nov 1, 2022, 9:45:53 PM11/1/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de>:
> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de>:
>>> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>>>
>>>> printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
>>>
>>> Warum kein einfaches
>>>
>>> echo vm.overcommit_memory=2 | sysctl -p -
>>>
>>
>> Weil ich keine Lust habe, mich jedes Mal darüber versichern zu
>> müssen, dass ein Gleichheitszeichen im Shell in diesem Fall keine
>> Sonderbedeutung hat
>
> In welcher Shell ist ein Gleichheitszeichen ein Metazeichen?
> Ich lerne gerne dazu :-)
Dazuzulernen ist immer eine gute Idee. Bittesehr! Was liefert
> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de>:
>>> Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>>>
>>>> printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p -
>>>
>>> Warum kein einfaches
>>>
>>> echo vm.overcommit_memory=2 | sysctl -p -
>>>
>>
>> Weil ich keine Lust habe, mich jedes Mal darüber versichern zu
>> müssen, dass ein Gleichheitszeichen im Shell in diesem Fall keine
>> Sonderbedeutung hat
>
> In welcher Shell ist ein Gleichheitszeichen ein Metazeichen?
> Ich lerne gerne dazu :-)
dir das folgende Shell‐Kommando in den dir verfügbaren Shells?
( set -k && printenv variable variable=Wert1 )
variable=Wert2 printenv variable
Helmut Waitzmann
Nov 1, 2022, 9:45:54 PM11/1/22
to
Bonita Montero <Bonita....@gmail.com>:
Genau. So zu programmieren ist wirklich blöd: Speicher
anfordern, obwohl man ihn noch nicht braucht, ohne Rücksicht
darauf, ob man damit das ganze System in die Knie zwingt.
Nicht jeder hat ein System mit 64 GiB virtuellem Speicher zur
Verfügung. Das scheinen die Entwickler vergessen zu haben.
anfordern, obwohl man ihn noch nicht braucht, ohne Rücksicht
darauf, ob man damit das ganze System in die Knie zwingt.
Nicht jeder hat ein System mit 64 GiB virtuellem Speicher zur
Verfügung. Das scheinen die Entwickler vergessen zu haben.
Bonita Montero
Nov 1, 2022, 10:54:40 PM11/1/22
to
Am 01.11.2022 um 19:33 schrieb Bernd Mayer:
> die GPU hat ja auch eigenen Speicher.
In dem Rahmen war nur die Rede davon, wieviel RAM der Prozessor noch
> die GPU hat ja auch eigenen Speicher.
im Rahmen der GPU-Beschleunigung zusätzlich verbrät.
> "Die Anzahl der Inhaltsprozesse können Sie zwischen 1 und 8 einstellen.
> Die Standardeinstellung ist 8. Mehr Inhaltsprozesse verbessern die
> Leistung bei Verwendung mehrerer Tabs, sie belegen aber auch mehr
> Arbeitsspeicher. Sie können die Zahl der Inhaltsprozesse verringern,
> wenn auf Ihrem Computer zu wenig Arbeitsspeicher vorhanden ist."
> und:
einzelner Browser-Threads in eine Gruppe von Prozessen.
Bonita Montero
Nov 1, 2022, 10:57:31 PM11/1/22
to
>> Ist aber echt gefährlich was die da machen, denn wenn man das
>> Overcommit abschaltet ist man schnell der Blöde, denn wenn dann nicht
>> genügend Swap da ist, schlagen solche Allokationen unmittelbar fehl.
> Genau. So zu programmieren ist wirklich blöd: Speicher anfordern,
> obwohl man ihn noch nicht braucht, ...
>> Overcommit abschaltet ist man schnell der Blöde, denn wenn dann nicht
>> genügend Swap da ist, schlagen solche Allokationen unmittelbar fehl.
> Genau. So zu programmieren ist wirklich blöd: Speicher anfordern,
Ne, blöd ist das auch nicht, denn so muss man ja selten Speicher beim
Kernel explizit anfordern, sondern man hat einfach einen großen Pool,
greift erstmalig auf die entsprechenden Pages zu und der Kernel sorgt
dann dafür, dass die bei diesem Zugriff dann physischen Pages zugeord-
net wird.
> obwohl man ihn noch nicht braucht, ohne Rücksicht darauf, ob man damit
Passiert ja nicht, auch nicht bei ausgeschaltetem Overcommit. Es wird
halt ggf. nur entsprechend vom Swap subtrahiert, d.h. man muss in dem
Fall genug Swap reservieren ohne, dass der entsprechend angefasst wird.
Tim Ritberg
Nov 2, 2022, 4:17:06 AM11/2/22
to
Am 02.11.22 um 01:59 schrieb Helmut Waitzmann:
Ich könnte es ja noch akzeptieren, wenn er sich beim Start 1GB holt.
IT ist einfach nur noch kaputt :-(
Tim
>
> Genau. So zu programmieren ist wirklich blöd: Speicher anfordern,
> obwohl man ihn noch nicht braucht, ohne Rücksicht darauf, ob man damit
> das ganze System in die Knie zwingt. Nicht jeder hat ein System mit
> 64 GiB virtuellem Speicher zur Verfügung. Das scheinen die Entwickler
> vergessen zu haben.
Finde ich auch blöd, vor allem, es war eine leere Session, ein leerer Tab.
> Genau. So zu programmieren ist wirklich blöd: Speicher anfordern,
> obwohl man ihn noch nicht braucht, ohne Rücksicht darauf, ob man damit
> das ganze System in die Knie zwingt. Nicht jeder hat ein System mit
> 64 GiB virtuellem Speicher zur Verfügung. Das scheinen die Entwickler
> vergessen zu haben.
Ich könnte es ja noch akzeptieren, wenn er sich beim Start 1GB holt.
IT ist einfach nur noch kaputt :-(
Tim
Bonita Montero
Nov 2, 2022, 5:29:51 AM11/2/22
to
Am 02.11.2022 um 09:17 schrieb Tim Ritberg:
> Finde ich auch blöd, vor allem, es war eine leere Session, ein leerer Tab.
> Ich könnte es ja noch akzeptieren, wenn er sich beim Start 1GB holt.
> IT ist einfach nur noch kaputt :-(
Das ist im Endeffekt nur Adressraum geholt wird, oder mit Overcommit
> Finde ich auch blöd, vor allem, es war eine leere Session, ein leerer Tab.
> Ich könnte es ja noch akzeptieren, wenn er sich beim Start 1GB holt.
> IT ist einfach nur noch kaputt :-(
aus dann halt zusätzlich reserviertes Swapfile. Wirklich problematisch
ist das nur im letzteren Fall wenn nicht genug Swap da ist, dann schlägt
die Allokation fehl obwohl vom tatsächlich genutzten Speicher noch genug
da wäre.
Claus Reibenstein
Nov 2, 2022, 11:31:42 AM11/2/22
to
Helmut Waitzmann schrieb am 02.11.2022 um 01:43:
> ( set -k && printenv variable variable=Wert1 )
¯¯¯¯¯¯
> ( set -k && printenv variable variable=Wert1 )
Wer macht denn sowas?
Gruß
Claus
Bernd Mayer
Nov 2, 2022, 1:57:25 PM11/2/22
to
Am 02.11.22 um 03:54 schrieb Bonita Montero:
falls der OP eine CPU mit integrierter Grafik verwendet, dann sieht eh
alles anders aus. Er hat dann auch nicht seine ganzen 8 GB fürs System frei.
Bernd Mayer
> Am 01.11.2022 um 19:33 schrieb Bernd Mayer:
>
>> die GPU hat ja auch eigenen Speicher.
>
> In dem Rahmen war nur die Rede davon, wieviel RAM der Prozessor noch
> im Rahmen der GPU-Beschleunigung zusätzlich verbrät.
>
Hallo,
>
>> die GPU hat ja auch eigenen Speicher.
>
> In dem Rahmen war nur die Rede davon, wieviel RAM der Prozessor noch
> im Rahmen der GPU-Beschleunigung zusätzlich verbrät.
>
falls der OP eine CPU mit integrierter Grafik verwendet, dann sieht eh
alles anders aus. Er hat dann auch nicht seine ganzen 8 GB fürs System frei.
Bernd Mayer
Helmut Waitzmann
Nov 2, 2022, 2:08:53 PM11/2/22
to
Claus Reibenstein <crei...@gmail.com>:
solchen Abhängigkeiten möglichst unabhängig.
> Helmut Waitzmann schrieb am 02.11.2022 um 01:43:
>
>> ( set -k && printenv variable variable=Wert1 )
> ¯¯¯¯¯¯
>
> Wer macht denn sowas?
>
Weiß ich nicht. Aber robuste Shell‐Programmierung macht sich von
>
>> ( set -k && printenv variable variable=Wert1 )
> ¯¯¯¯¯¯
>
> Wer macht denn sowas?
>
solchen Abhängigkeiten möglichst unabhängig.
Claus Reibenstein
Nov 3, 2022, 9:38:11 AM11/3/22
to
Gruß
Claus
Thomas Dorner
Nov 3, 2022, 3:16:43 PM11/3/22
to
Claus Reibenstein <crei...@gmail.com> writes:
:-)
Zumindest BaSH 5.2.2 reicht ein -k nicht an aufgerufene Skripte weiter
(aber an Unterprozesse):
| > echo -e '#!/bin/bash\nset -o' >/tmp/seto.sh
| > chmod +x /tmp/seto.sh
| > (set -k; set -o; (set -o);/tmp/seto.sh) | fgrep keyword
| keyword on
| keyword on
| keyword off
Zumindest BaSH 5.2.2 reicht ein -k nicht an aufgerufene Skripte weiter
(aber an Unterprozesse):
| > echo -e '#!/bin/bash\nset -o' >/tmp/seto.sh
| > chmod +x /tmp/seto.sh
| > (set -k; set -o; (set -o);/tmp/seto.sh) | fgrep keyword
| keyword on
| keyword on
| keyword off
Claus Reibenstein
Nov 4, 2022, 11:52:36 AM11/4/22
to
Thomas Dorner schrieb am 03.11.2022 um 20:10:
> Claus Reibenstein <crei...@gmail.com> writes:
>
>> Helmut Waitzmann schrieb am 02.11.2022 um 18:29:
>>
>>> Claus Reibenstein <crei...@gmail.com>:
>>>
>>>> Helmut Waitzmann schrieb am 02.11.2022 um 01:43:
>>>>
>>>>> ( set -k && printenv variable variable=Wert1 )
>>>> ¯¯¯¯¯¯
>>>>
>>>> Wer macht denn sowas?
>>>
>>> Weiß ich nicht. Aber robuste Shell‐Programmierung macht sich von
>>> solchen Abhängigkeiten möglichst unabhängig.
>>
>> Zum Beispiel mit einem einfachen "set +k" :-)
>
> :-)
>
> Zumindest BaSH 5.2.2 reicht ein -k nicht an aufgerufene Skripte weiter
> (aber an Unterprozesse):
Stimmt. Eben getestet.
Dann verstehe ich aber Helmuts Problem nicht.
Gruß
Claus
> Claus Reibenstein <crei...@gmail.com> writes:
>
>> Helmut Waitzmann schrieb am 02.11.2022 um 18:29:
>>
>>> Claus Reibenstein <crei...@gmail.com>:
>>>
>>>> Helmut Waitzmann schrieb am 02.11.2022 um 01:43:
>>>>
>>>>> ( set -k && printenv variable variable=Wert1 )
>>>> ¯¯¯¯¯¯
>>>>
>>>> Wer macht denn sowas?
>>>
>>> Weiß ich nicht. Aber robuste Shell‐Programmierung macht sich von
>>> solchen Abhängigkeiten möglichst unabhängig.
>>
>> Zum Beispiel mit einem einfachen "set +k" :-)
>
> :-)
>
> Zumindest BaSH 5.2.2 reicht ein -k nicht an aufgerufene Skripte weiter
> (aber an Unterprozesse):
Dann verstehe ich aber Helmuts Problem nicht.
Gruß
Claus
Thomas Dorner
Nov 4, 2022, 4:38:02 PM11/4/22
to
also in diesen Fällen kann das schon auftreten.
0 new messages