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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-31 16:14 +0100 |
| Message-ID | <tjooo9$h5du$1@dont-email.me> |
| In reply to | #125821 |
Am 31.10.2022 um 13:15 schrieb Tim Ritberg: > Am 31.10.22 um 07:56 schrieb Bonita Montero: >> Am 30.10.2022 um 20:16 schrieb Tim Ritberg: >> >>> 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. >> > > Bei mir wollte Chrome sich direk beim Start 40GB reserviren im AS. 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.
[toc] | [prev] | [next] | [standalone]
| From | Tim Ritberg <tim@server.invalid> |
|---|---|
| Date | 2022-10-31 18:47 +0100 |
| Message-ID | <tjp1n5$8hdm$1@tota-refugium.de> |
| In reply to | #125823 |
Am 31.10.22 um 16:14 schrieb Bonita Montero: > Am 31.10.2022 um 13:15 schrieb Tim Ritberg: >> Am 31.10.22 um 07:56 schrieb Bonita Montero: >>> Am 30.10.2022 um 20:16 schrieb Tim Ritberg: >>> >>>> 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. >>> >> >> Bei mir wollte Chrome sich direk beim Start 40GB reserviren im AS. > > 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. Tim
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-01 08:04 +0100 |
| Message-ID | <tjqgdv$o12a$1@dont-email.me> |
| In reply to | #125826 |
Am 31.10.2022 um 18:47 schrieb Tim Ritberg: > 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 verbrät.
[toc] | [prev] | [next] | [standalone]
| From | Tim Ritberg <tim@server.invalid> |
|---|---|
| Date | 2022-11-01 10:20 +0100 |
| Message-ID | <tjqodk$9bdi$1@tota-refugium.de> |
| In reply to | #125852 |
Am 01.11.22 um 08:04 schrieb Bonita Montero: > > Ich halt's einfach nicht für plausibel, dass Chrome per-se so viel RAM > verbrät. Das soll die Antwort sein: 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
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-01 11:16 +0100 |
| Message-ID | <tjqrlp$oot4$1@dont-email.me> |
| In reply to | #125857 |
Am 01.11.2022 um 10:20 schrieb Tim Ritberg: > Am 01.11.22 um 08:04 schrieb Bonita Montero: >> >> Ich halt's einfach nicht für plausibel, dass Chrome per-se so viel RAM >> verbrät. > > > Das soll die Antwort sein: > 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. Ne, das ist definitiv keine Antwort. Und ich kenne mich sehr gut mit 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.
[toc] | [prev] | [next] | [standalone]
| From | Friedhelm Waitzmann <usenetf2022.fwnsp@spamgourmet.com> |
|---|---|
| Date | 2022-10-31 13:16 +0000 |
| Message-ID | <tjohra$adc$1@gioia.aioe.org> |
| In reply to | #125809 |
Tim Ritberg: >Am 30.10.22 um 16:53 schrieb Friedhelm Waitzmann: >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. 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
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2022-10-30 21:52 +0100 |
| Message-ID | <tjmo6j$1v83i$1@gwaiyur.mb-net.net> |
| In reply to | #125807 |
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 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. Das bringt halt wenig, wenn die Prozesse nachwachsende Rohstoffe sind. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2022-10-30 18:20 -0400 |
| Message-ID | <87r0yp54xi.fsf@usenet.ankman.de> |
| In reply to | #125796 |
On Sun, 30 Oct 2022 08:26:02 +0100, Marcel Mueller wrote: > > Am 30.10.22 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. > > 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. LibreOffice braucht hier gerade (beim Idlen) 6.5 GB virtual. Das scheint hier normal. > 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 ich top oder htop sagen, die Summe des RAM-Verbrauchs oder CPU-Loads von allen Threads eines Prozessen anzuzeigen. > 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. Meine 8 GB (waren nach der Installation 2) scheinen zum Hibernate weiter zu klein. und als Swap noch 2 GB waren, kam ich bei genanntem Verhalten gar nicht mehr (auch nicht nach 12 Stunden über Nacht) ans System heran. Nun mit 8 GB geht es einigermaßen. [...] > 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. Es war vermutlich eine Swap-Orgie. Eine Funktion von LibreOffice brachte es nach Aufruf dazu, fast 70 % RAM zu verbrauchen. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-31 08:00 +0100 |
| Message-ID | <tjnrph$er06$3@dont-email.me> |
| In reply to | #125813 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Helmut Waitzmann <nn.throttle@xoxy.net> |
|---|---|
| Date | 2022-10-31 03:03 +0100 |
| Message-ID | <83sfj4lpg3.fsf@helmutwaitzmann.news.arcor.de> |
| In reply to | #125796 |
Marcel Mueller <news.5.maazl@spamgourmet.org>: > 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 > 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.
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2022-11-01 09:40 +0000 |
| Message-ID | <tjqpio$i92$1@news2.informatik.uni-stuttgart.de> |
| In reply to | #125850 |
Helmut Waitzmann <nn.throttle@xoxy.net> wrote: > printf '%s\n' 'vm.overcommit_memory=2' | sysctl -p - Warum kein einfaches echo vm.overcommit_memory=2 | sysctl -p - -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2022-11-01 12:19 +0100 |
| Message-ID | <slrntm206s.5ghs.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #125858 |
On 2022-11-01 09:40, Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
> Helmut Waitzmann <nn.throttle@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
Ich habe in meinem Leben schon einigen bizarr umständlichen Code
gesehen, aber Helmuts Zeile hat einen Ehrenplatz verdient.
hp
[toc] | [prev] | [next] | [standalone]
| From | Helmut Waitzmann <nn.throttle@xoxy.net> |
|---|---|
| Date | 2022-11-01 18:23 +0100 |
| Message-ID | <83v8nyk2rp.fsf@helmutwaitzmann.news.arcor.de> |
| In reply to | #125868 |
"Peter J. Holzer" <hjp-usenet3@hjp.at>:
> On 2022-11-01 09:40, Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
>
>> Helmut Waitzmann <nn.throttle@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
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.
[toc] | [prev] | [next] | [standalone]
| From | Jens Schüßler <j.schuess@nurfuerspam.de> |
|---|---|
| Date | 2022-11-01 23:50 +0100 |
| Message-ID | <sdk83j-v61.ln1@luEaABwb52.dumb1.com> |
| In reply to | #125887 |
* Helmut Waitzmann <nn.throttle@xoxy.net> [01-11-22 17:23]: > > 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. Sonst noch aktuelle Erkenntnisse, zb. wie das in Win3.11 geregelt wird?
[toc] | [prev] | [next] | [standalone]
| From | Helmut Waitzmann <nn.throttle@xoxy.net> |
|---|---|
| Date | 2022-11-01 17:39 +0100 |
| Message-ID | <83zgdak4rv.fsf@helmutwaitzmann.news.arcor.de> |
| In reply to | #125858 |
Ulli Horlacher <framstag@rus.uni-stuttgart.de>: > Helmut Waitzmann <nn.throttle@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, 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.
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2022-11-01 22:59 +0000 |
| Message-ID | <tjs8bk$j1a$1@news2.informatik.uni-stuttgart.de> |
| In reply to | #125886 |
Helmut Waitzmann <nn.throttle@xoxy.net> wrote: > Ulli Horlacher <framstag@rus.uni-stuttgart.de>: >> Helmut Waitzmann <nn.throttle@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 :-) -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | Helmut Waitzmann <nn.throttle@xoxy.net> |
|---|---|
| Date | 2022-11-02 01:43 +0100 |
| Message-ID | <83bkpqjidw.fsf@helmutwaitzmann.news.arcor.de> |
| In reply to | #125894 |
Ulli Horlacher <framstag@rus.uni-stuttgart.de>: > Helmut Waitzmann <nn.throttle@xoxy.net> wrote: >> Ulli Horlacher <framstag@rus.uni-stuttgart.de>: >>> Helmut Waitzmann <nn.throttle@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 dir das folgende Shell‐Kommando in den dir verfügbaren Shells? ( set -k && printenv variable variable=Wert1 ) variable=Wert2 printenv variable
[toc] | [prev] | [next] | [standalone]
| From | Claus Reibenstein <creibens@gmail.com> |
|---|---|
| Date | 2022-11-02 16:31 +0100 |
| Message-ID | <jsfgqrFs9rlU1@mid.individual.net> |
| In reply to | #125897 |
Helmut Waitzmann schrieb am 02.11.2022 um 01:43:
> ( set -k && printenv variable variable=Wert1 )
¯¯¯¯¯¯
Wer macht denn sowas?
Gruß
Claus
[toc] | [prev] | [next] | [standalone]
| From | Helmut Waitzmann <nn.throttle@xoxy.net> |
|---|---|
| Date | 2022-11-02 18:29 +0100 |
| Message-ID | <83fsf1gt8i.fsf@helmutwaitzmann.news.arcor.de> |
| In reply to | #125920 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Claus Reibenstein <creibens@gmail.com> |
|---|---|
| Date | 2022-11-03 14:38 +0100 |
| Message-ID | <jshui1F94i0U2@mid.individual.net> |
| In reply to | #125927 |
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" :-) Gruß Claus
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web