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 1 of 5 [1] 2 3 4 5 Next page →
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2022-10-29 19:28 -0400 |
| Subject | OOM-Killer konfigurieren |
| Message-ID | <878rky6wh8.fsf@usenet.ankman.de> |
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
[toc] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2022-10-30 08:26 +0100 |
| Message-ID | <tjl8ua$1se15$1@gwaiyur.mb-net.net> |
| In reply to | #125795 |
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. 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
[toc] | [prev] | [next] | [standalone]
| From | Tim Ritberg <tim@server.invalid> |
|---|---|
| Date | 2022-10-30 11:13 +0100 |
| Message-ID | <tjlioe$6s2g$1@tota-refugium.de> |
| In reply to | #125796 |
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
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2022-10-30 20:42 +0100 |
| Message-ID | <20221030204219.e725a44e65fd704b6ff8cc0b@SchS.de> |
| In reply to | #125801 |
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
-----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Tim Ritberg <tim@server.invalid> |
|---|---|
| Date | 2022-10-30 23:02 +0100 |
| Message-ID | <tjmsa3$7ft0$1@tota-refugium.de> |
| In reply to | #125811 |
Am 30.10.22 um 20:42 schrieb Sieghard Schicktanz: > 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. Tim
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2022-10-31 21:27 +0100 |
| Message-ID | <20221031212708.8a2a16eac1025f33a041380e@SchS.de> |
| In reply to | #125812 |
Hallo Tim, 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? 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. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-31 07:54 +0100 |
| Message-ID | <tjnrfi$er06$1@dont-email.me> |
| In reply to | #125801 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Tim Ritberg <tim@server.invalid> |
|---|---|
| Date | 2022-10-31 13:14 +0100 |
| Message-ID | <tjoe6u$873f$1@tota-refugium.de> |
| In reply to | #125817 |
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. Tim
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-31 16:20 +0100 |
| Message-ID | <tjop31$h5du$2@dont-email.me> |
| In reply to | #125820 |
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, bzw. das hab ich so bei Firefox noch nicht erlebt. Außerdem gibt es mehrere Interpretationen von "reservieren" bzw. da bist Du sehr unscharf.
[toc] | [prev] | [next] | [standalone]
| From | Tim Ritberg <tim@server.invalid> |
|---|---|
| Date | 2022-10-31 18:50 +0100 |
| Message-ID | <tjp1tf$8hdm$2@tota-refugium.de> |
| In reply to | #125824 |
Am 31.10.22 um 16:20 schrieb Bonita Montero: > 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, bzw. das hab ich so bei Firefox noch nicht > erlebt. Außerdem gibt es mehrere Interpretationen von "reservieren" > bzw. da bist Du sehr unscharf. > 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
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-01 08:07 +0100 |
| Message-ID | <tjqgij$o12a$2@dont-email.me> |
| In reply to | #125827 |
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. ... 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ß." Klingt genauso un-plausibel.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2022-10-31 23:56 +0100 |
| Message-ID | <slrntm0kkv.42qu.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #125824 |
On 2022-10-31 15:20, Bonita Montero <Bonita.Montero@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:
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.
Vielleicht, weil Du keine Resource-Limits setzt? Wer tut das auf einem
Desktop-System schon?
> Außerdem gibt es mehrere Interpretationen von "reservieren" bzw. da
> bist Du sehr unscharf.
Wenn man ungefähr weiß, wie die Speicherverwaltung von Linux
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
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-11-01 08:09 +0100 |
| Message-ID | <tjqgmq$o12a$3@dont-email.me> |
| In reply to | #125846 |
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 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. Nein. Allein weil die je nach Einstellung unterschiedlich arbeitet.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Dorner <de.comp.os.unix.linux.misc.221101.dorner@spamgourmet.com> |
|---|---|
| Date | 2022-11-01 19:38 +0100 |
| Message-ID | <6eleouwmeb.fsf@th-dorner.de> |
| In reply to | #125846 |
"Peter J. Holzer" <hjp-usenet3@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!
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2022-11-02 01:32 +0100 |
| Message-ID | <slrntm3elg.6ta1.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #125891 |
On 2022-11-01 18:38, Thomas Dorner <de.comp.os.unix.linux.misc.221101.dorner@spamgourmet.com> wrote:
> "Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
>> Auf einem Ubuntu 22.04:
>
> Firefox auf Ubuntu 22.04? Das ist doch dann ein Snap, oder?
Ja.
> Bezieht sich das Limit dann möglicherweise auf Firefox plus alles
> andere im Snap zusammen?
Die Resource-Limits sind pro Prozess (außer RLIMIT_NPROC natürlich).
Das ist auch ein Grund, warum sie in der Praxis wenig hilfreich sind.
hp
[toc] | [prev] | [next] | [standalone]
| From | Friedhelm Waitzmann <usenetf2022.fwnsp@spamgourmet.com> |
|---|---|
| Date | 2022-10-30 15:53 +0000 |
| Message-ID | <tjm6lg$13f2$1@gioia.aioe.org> |
| In reply to | #125796 |
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? >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
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2022-10-30 16:56 +0100 |
| Message-ID | <slrntlt7kt.ouf.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #125807 |
On 2022-10-30 15:53, Friedhelm Waitzmann <usenetf2022.fwnsp@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?
hp
[toc] | [prev] | [next] | [standalone]
| From | Tim Ritberg <tim@server.invalid> |
|---|---|
| Date | 2022-10-30 20:16 +0100 |
| Message-ID | <tjmiio$7clj$1@tota-refugium.de> |
| In reply to | #125807 |
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. Tim
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-31 07:56 +0100 |
| Message-ID | <tjnrj5$er06$2@dont-email.me> |
| In reply to | #125809 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Tim Ritberg <tim@server.invalid> |
|---|---|
| Date | 2022-10-31 13:15 +0100 |
| Message-ID | <tjoe8g$873f$2@tota-refugium.de> |
| In reply to | #125818 |
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. Tim
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web