Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.os.unix.linux.misc > #125795 > unrolled thread
| Started by | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| First post | 2022-10-29 19:28 -0400 |
| Last post | 2022-11-02 10:30 +0100 |
| Articles | 20 on this page of 91 — 21 participants |
Back to article view | Back to de.comp.os.unix.linux.misc
OOM-Killer konfigurieren Andreas Kohlbach <ank@spamfence.net> - 2022-10-29 19:28 -0400
Re: OOM-Killer konfigurieren Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-10-30 08:26 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-10-30 11:13 +0100
Re: OOM-Killer konfigurieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-10-30 20:42 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-10-30 23:02 +0100
Re: OOM-Killer konfigurieren Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-10-31 21:27 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-31 07:54 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-10-31 13:14 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-31 16:20 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-10-31 18:50 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 08:07 +0100
Re: OOM-Killer konfigurieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-10-31 23:56 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 08:09 +0100
Re: OOM-Killer konfigurieren Thomas Dorner <de.comp.os.unix.linux.misc.221101.dorner@spamgourmet.com> - 2022-11-01 19:38 +0100
Re: OOM-Killer konfigurieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-11-02 01:32 +0100
Re: OOM-Killer konfigurieren Friedhelm Waitzmann <usenetf2022.fwnsp@spamgourmet.com> - 2022-10-30 15:53 +0000
Re: OOM-Killer konfigurieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-10-30 16:56 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-10-30 20:16 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-31 07:56 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-10-31 13:15 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-31 16:14 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-10-31 18:47 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 08:04 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-11-01 10:20 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 11:16 +0100
Re: OOM-Killer konfigurieren Friedhelm Waitzmann <usenetf2022.fwnsp@spamgourmet.com> - 2022-10-31 13:16 +0000
Re: OOM-Killer konfigurieren Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-10-30 21:52 +0100
Re: OOM-Killer konfigurieren Andreas Kohlbach <ank@spamfence.net> - 2022-10-30 18:20 -0400
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-31 08:00 +0100
Re: OOM-Killer konfigurieren Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-10-31 03:03 +0100
Re: OOM-Killer konfigurieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-11-01 09:40 +0000
Re: OOM-Killer konfigurieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-11-01 12:19 +0100
Re: OOM-Killer konfigurieren Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-11-01 18:23 +0100
Re: OOM-Killer konfigurieren Jens Schüßler <j.schuess@nurfuerspam.de> - 2022-11-01 23:50 +0100
Re: OOM-Killer konfigurieren Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-11-01 17:39 +0100
Re: OOM-Killer konfigurieren Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-11-01 22:59 +0000
Re: OOM-Killer konfigurieren Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-11-02 01:43 +0100
Re: OOM-Killer konfigurieren Claus Reibenstein <creibens@gmail.com> - 2022-11-02 16:31 +0100
Re: OOM-Killer konfigurieren Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-11-02 18:29 +0100
Re: OOM-Killer konfigurieren Claus Reibenstein <creibens@gmail.com> - 2022-11-03 14:38 +0100
Re: OOM-Killer konfigurieren Thomas Dorner <de.comp.os.unix.linux.misc.221103.dorner@spamgourmet.com> - 2022-11-03 20:10 +0100
Re: OOM-Killer konfigurieren Claus Reibenstein <creibens@gmail.com> - 2022-11-04 16:52 +0100
Re: OOM-Killer konfigurieren Thomas Dorner <de.comp.os.unix.linux.misc.221104.dorner@spamgourmet.com> - 2022-11-04 21:12 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 08:12 +0100
Re: OOM-Killer konfigurieren Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-10-30 09:15 +0000
Re: OOM-Killer konfigurieren Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-10-30 10:44 +0100
Re: OOM-Killer konfigurieren Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-10-30 12:16 +0000
Re: OOM-Killer konfigurieren Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-10-30 15:31 +0100
Re: OOM-Killer konfigurieren Christian Schumacher <cs.spam@nurfuerspam.de> - 2022-10-30 09:45 +0000
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-10-30 11:14 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-30 10:56 +0100
Re: OOM-Killer konfigurieren Andreas Kohlbach <ank@spamfence.net> - 2022-10-30 18:24 -0400
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-31 07:48 +0100
Re: OOM-Killer konfigurieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-11-01 00:02 +0100
Re: OOM-Killer konfigurieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-10-30 12:06 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-10-30 12:53 +0100
Re: OOM-Killer konfigurieren Andreas Kohlbach <ank@spamfence.net> - 2022-10-30 18:27 -0400
Re: OOM-Killer konfigurieren "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-11-01 00:09 +0100
Re: OOM-Killer konfigurieren Andreas Kohlbach <ank@spamfence.net> - 2022-10-31 19:57 -0400
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 08:22 +0100
Re: OOM-Killer konfigurieren Bernd Mayer <beambamboom@yahoo.com> - 2022-11-01 14:25 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 14:32 +0100
Re: OOM-Killer konfigurieren Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-11-01 18:30 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 19:25 +0100
Re: OOM-Killer konfigurieren Bernd Mayer <beambamboom@yahoo.com> - 2022-11-01 19:33 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-02 03:54 +0100
Re: OOM-Killer konfigurieren Bernd Mayer <beambamboom@yahoo.com> - 2022-11-02 18:57 +0100
Re: OOM-Killer konfigurieren Andreas Kohlbach <ank@spamfence.net> - 2022-11-01 13:17 -0400
Re: OOM-Killer konfigurieren Friedemann Stoyan <usenet@ip6-mail.de> - 2022-10-31 18:14 +0100
Re: OOM-Killer konfigurieren Rolf Buenning <r.buenning@gmx.de> - 2022-11-01 06:33 +0000
Re: OOM-Killer konfigurieren Friedemann Stoyan <usenet@ip6-mail.de> - 2022-11-01 10:47 +0100
Re: OOM-Killer konfigurieren Rolf Buenning <r.buenning@gmx.de> - 2022-11-01 10:18 +0000
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-11-01 11:23 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 11:28 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-11-01 11:51 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 13:25 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-11-01 13:28 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 14:22 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-11-01 15:20 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 15:41 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-11-01 15:48 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 16:03 +0100
Re: OOM-Killer konfigurieren Laurenz Trossel <me@example.invalid> - 2022-11-01 15:00 +0000
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 16:04 +0100
Re: OOM-Killer konfigurieren Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-11-01 15:08 +0000
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-11-01 16:39 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-01 17:01 +0100
Re: OOM-Killer konfigurieren Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-11-02 01:59 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-02 03:57 +0100
Re: OOM-Killer konfigurieren Tim Ritberg <tim@server.invalid> - 2022-11-02 09:17 +0100
Re: OOM-Killer konfigurieren Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-02 10:30 +0100
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Thomas Dorner <de.comp.os.unix.linux.misc.221103.dorner@spamgourmet.com> |
|---|---|
| Date | 2022-11-03 20:10 +0100 |
| Message-ID | <6eedujx39p.fsf@th-dorner.de> |
| In reply to | #125946 |
Claus Reibenstein <creibens@gmail.com> writes: D> Helmut Waitzmann schrieb am 02.11.2022 um 18:29: >> Claus Reibenstein <creibens@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): | > 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 Viele Grüße, Thomas -- Adresse gilt nur kurzzeitig!
[toc] | [prev] | [next] | [standalone]
| From | Claus Reibenstein <creibens@gmail.com> |
|---|---|
| Date | 2022-11-04 16:52 +0100 |
| Message-ID | <jskqq2FmmmvU1@mid.individual.net> |
| In reply to | #125947 |
Thomas Dorner schrieb am 03.11.2022 um 20:10: > Claus Reibenstein <creibens@gmail.com> writes: > >> Helmut Waitzmann schrieb am 02.11.2022 um 18:29: >> >>> Claus Reibenstein <creibens@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
[toc] | [prev] | [next] | [standalone]
| From | Thomas Dorner <de.comp.os.unix.linux.misc.221104.dorner@spamgourmet.com> |
|---|---|
| Date | 2022-11-04 21:12 +0100 |
| Message-ID | <6e7d0axyv7.fsf@th-dorner.de> |
| In reply to | #125958 |
Claus Reibenstein <creibens@gmail.com> writes: > Thomas Dorner schrieb am 03.11.2022 um 20:10: > >> Claus Reibenstein <creibens@gmail.com> writes: >> >>> Helmut Waitzmann schrieb am 02.11.2022 um 18:29: >>> >>>> Claus Reibenstein <creibens@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. Naja, wenn ich ein Skrip per "source" einbinde, bleibt das -k erhalten, also in diesen Fällen kann das schon auftreten. Viele Grüße, Thomas -- Adresse gilt nur kurzzeitig!
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-01 08:12 +0100 |
| Message-ID | <tjqgtc$o12a$4@dont-email.me> |
| In reply to | #125796 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) |
|---|---|
| Date | 2022-10-30 09:15 +0000 |
| Message-ID | <1t635e3f7di37468an3e8%sfroehli@Froehlich.Priv.at> |
| In reply to | #125795 |
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, 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. Wenn das reicht, ist es eh noch ok. In meinem Fall ist in der 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. 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. Servus, Stefan -- http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich Offizieller Erstbesucher(TM) von mmeike Für Liebhaber: Stefan - wenn alles mißlingt! (Sloganizer)
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2022-10-30 10:44 +0100 |
| Message-ID | <tjlh1q$1sq81$5@gwaiyur.mb-net.net> |
| In reply to | #125797 |
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. Aber mit "about:performance" kann die Übeltäter zumindest erkennen, und gelegentlich auch mal in die Schranken weisen. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) |
|---|---|
| Date | 2022-10-30 12:16 +0000 |
| Message-ID | <1t635e6a27i37982an3e8%sfroehli@Froehlich.Priv.at> |
| In reply to | #125798 |
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. > 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. Hm, muss ich einmal probieren. Jede Verbesserung ist etwas wert. > Gegen eigene Bloatware von den "großen" Websites hilft das aber > auch nicht. Es hilft noch nicht einmal gegen meine eigene, gelegentlich 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 Perfektum fantasticum, oder warum Stefan so blausam wirbt! (Sloganizer)
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2022-10-30 15:31 +0100 |
| Message-ID | <tjm1rf$1tvkb$1@gwaiyur.mb-net.net> |
| In reply to | #125805 |
Am 30.10.22 um 13:16 schrieb Stefan Froehlich: > 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 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
[toc] | [prev] | [next] | [standalone]
| From | Christian Schumacher <cs.spam@nurfuerspam.de> |
|---|---|
| Date | 2022-10-30 09:45 +0000 |
| Message-ID | <tjlh3m$7a7r$1@solani.org> |
| In reply to | #125797 |
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* -- Gruß, Christian »Wenn du klug bist, so mische eines mit dem anderen: Hoffe nicht ohne Zweifel, und zweifle nicht ohne Hoffnung.« --Seneca
[toc] | [prev] | [next] | [standalone]
| From | Tim Ritberg <tim@server.invalid> |
|---|---|
| Date | 2022-10-30 11:14 +0100 |
| Message-ID | <tjliq2$6s2g$2@tota-refugium.de> |
| In reply to | #125799 |
Am 30.10.22 um 10:45 schrieb Christian Schumacher: > 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 :-) Tim
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-30 10:56 +0100 |
| Message-ID | <tjlho8$3ddm$1@dont-email.me> |
| In reply to | #125795 |
Am 30.10.2022 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. > > 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2022-10-30 18:24 -0400 |
| Message-ID | <87o7tt54rp.fsf@usenet.ankman.de> |
| In reply to | #125800 |
On Sun, 30 Oct 2022 10:56:33 +0100, Bonita Montero wrote: > > Am 30.10.2022 um 01:28 schrieb Andreas Kohlbach: > >> 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. > > 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. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-31 07:48 +0100 |
| Message-ID | <tjnr30$epro$1@dont-email.me> |
| In reply to | #125814 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2022-11-01 00:02 +0100 |
| Message-ID | <slrntm0l07.42qu.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #125814 |
On 2022-10-30 22:24, Andreas Kohlbach <ank@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
Killer", Es steht Dir frei, einen atkd zu schreiben :-).
hp
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2022-10-30 12:06 +0100 |
| Message-ID | <slrntlsmls.lo2m.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #125795 |
On 2022-10-29 23:28, Andreas Kohlbach <ank@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).
> 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.
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.
hp
[toc] | [prev] | [next] | [standalone]
| From | Tim Ritberg <tim@server.invalid> |
|---|---|
| Date | 2022-10-30 12:53 +0100 |
| Message-ID | <tjlojd$6um3$1@tota-refugium.de> |
| In reply to | #125803 |
Am 30.10.22 um 12:06 schrieb Peter J. Holzer: > On 2022-10-29 23:28, Andreas Kohlbach <ank@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 das Problem. Tim
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2022-10-30 18:27 -0400 |
| Message-ID | <87leox54n2.fsf@usenet.ankman.de> |
| In reply to | #125803 |
On Sun, 30 Oct 2022 12:06:36 +0100, Peter J. Holzer wrote: > > On 2022-10-29 23:28, Andreas Kohlbach <ank@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. >> >> Da ich diesen Hog eh abschieße, könnte das eh gleich OOM machen. > > 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. Danke, auch an die anderen. Aber dann lasse ich es, wie es ist. 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). So wunderte ich zunächst, dass das nun nicht passiert. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2022-11-01 00:09 +0100 |
| Message-ID | <slrntm0lcq.42qu.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #125815 |
On 2022-10-30 22:27, Andreas Kohlbach <ank@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
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2022-10-31 19:57 -0400 |
| Message-ID | <8735b35yy7.fsf@usenet.ankman.de> |
| In reply to | #125848 |
On Tue, 1 Nov 2022 00:09:14 +0100, Peter J. Holzer wrote: > > On 2022-10-30 22:27, Andreas Kohlbach <ank@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 Memory vermeiden. War falsch gedacht. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-01 08:22 +0100 |
| Message-ID | <tjqhes$o12a$5@dont-email.me> |
| In reply to | #125849 |
Am 01.11.2022 um 00:57 schrieb Andreas Kohlbach: > On Tue, 1 Nov 2022 00:09:14 +0100, Peter J. Holzer wrote: >> >> On 2022-10-30 22:27, Andreas Kohlbach <ank@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 > Memory vermeiden. War falsch gedacht. Tut er ja auch, aber er setzt erst sehr viel später ein als das System beginnt zu swappen.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web