On Mon, Jun 26, 2000 at 12:06:02PM +0200, Andre Schulze wrote:
genau: der prozess, der amok laeuft, sollte gekillt oder gestoppt werden. das ist das was man eigentlich erwartet.
Da ist leider aus Kernelsicht nicht so einfach feststellbar. Ich habe mir mal den Code angeschaut aber nicht komplett kapiert. Immerhin stellt er sicher dass nicht der init gekillt wird. Besser ware es, wenn es zu dieser Situation gar nicht(oder deutlich seltener) kommen wuerde. Dazu unten mehr.
wenig, normalerweise ist mein swap ja auch fast leer. bloed ist nur, das die anwendung spaeter auf bsd laufen soll. bsd ist sicher noch duemmer bei der handhabung von virtuellem speicher.
Wieso sollten die duemmer sein? Zumindest in dem Beispiel weiter unten verhält sich FreeBSD wie Solaris.
Es scheint noch keine sinnvoll funktionierende Lösung fuer diese Problem zu geben, die nicht massenhaft swap benötigt oder pessimistisch bei jedem fork() schon ein ENOMEM liefert, wenn der doppelte Platz fuer den Prozess nicht da ist.
der mysqld prozess ist ja auch schon da. ein fork() wird da nicht vom parent daemon gemacht.
Es geht darum, dass fork() noch gut geht, dem neuen Prozess beim Schreiben der Seiten aber der Speicher ausgeht, da dieser erst dann wirklich belegt wird. Ein Beispiel: (sorry fuer das ueberflussige Zeugs drin):
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <sys/types.h>
int main() { void *p; pid_t pid; int size=200; /* in MB */
if ((p=malloc(size*1024*1024)) == 0) { perror("malloc()"); exit(-1); } if ( ((pid=fork()) == -1) ) { perror("fork()"); exit -2; } else if (pid == 0) { printf("child with %i MB\n", size); sleep(3); exit(0); } /* parent */ wait(); printf("free()\n"); free(p); return 0; }
Solaris 128MB + 200 MB freiem swap sagt: rf11@rncmm10:~> ./a.out fork(): Not enough space free() rf11@rncmm10:~> Aha. Er denkt sich was dabei. Nett.
Solaris 128MB + 480MB freiem swap laesst den fork dann zu.
So - nun zuLinux: Linux-2.2, 128MB + 180MB freier swap: rf11@rncmm11:~> free total used free shared buffers cached Mem: 127964 25616 102348 14728 1764 16580 -/+ buffers/cache: 7272 120692 Swap: 184708 0 184708 rf11@rncmm11:~> ./a.out child with 200 MB free() rf11@rncmm11:~> Er macht fork() problemlos, gibt also 400MB Speicher raus, obwohl nur ca. 300MB da sind. Wenn ich nun anfange die 400MB zu beschreiben gehen Prozesse flöten wie bei Andre der nfsd.
Genau dieses Verhalten stört mich bei Linux. Das MM arbeitet einfach zu optimistisch und faellt deshalb öfters auf die Knie als andere Systeme. Meiner Meinung nach sollte man bei fork() gleich den Platz im swap reservieren und geht so bestimmt 99% der Out-Of-Memory-Situationen in Linux aus dem Weg. Mit Optimierung hat das IMO nix zu tun. Und das alles uebrigens mit rf11@rncmm11:~> cat /proc/sys/vm/overcommit_memory 0 rf11@rncmm11:~> Das Flag ist sogar per default auf 0, scheint allerdings bei fork() völlig völlig sinnlos zu sein. Stell ich das Flag auf 1 kann ich sogar per malloc gleich mal 500MB auf o.g. Rechner ausfassen (siehe vm_enough_memory()). Die Stelle fuer fork() habe ich im Kernel noch nicht entdeckt.
Reinhard
Am Mon, 26 Jun 2000 schrieb Reinhard Foerster:
On Mon, Jun 26, 2000 at 12:06:02PM +0200, Andre Schulze wrote: Solaris 128MB + 200 MB freiem swap sagt: fork(): Not enough space Aha. Er denkt sich was dabei. Nett.
Linux-2.2, 128MB + 180MB freier swap: child with 200 MB Er macht fork() problemlos, gibt also 400MB Speicher raus, obwohl nur ca. 300MB da sind. Wenn ich nun anfange die 400MB zu beschreiben gehen Prozesse flöten wie bei Andre der nfsd.
Genau dieses Verhalten stört mich bei Linux. Das MM arbeitet einfach zu optimistisch und faellt deshalb öfters auf die Knie als andere Systeme. Meiner Meinung nach sollte man bei fork() gleich den Platz im swap reservieren und geht so bestimmt 99% der Out-Of-Memory-Situationen in Linux aus dem Weg. Mit Optimierung hat das IMO nix zu tun.
Den Platz gleich im SWAP zu reservieren macht Solaris sicherlich auch nicht.
Die Frage ist, soll fork() so intelligent sein und rausfinden ob, im schlechtesteten Fall, genug Speicher frei ist oder nicht. Das ist sicher 'ne Frage für einen Statistiker, Dr. Hamann oder ?
Oft macht man nach dem fork() nämlich ein exec(). Bei einem 200 MB Prozess ist das zwar ziemlich blöd programmiert, aber theoretisch unter Linux möglich, unter Solaris anscheinend nicht.
Der Sinn der Sache mit dem warten auf einen Schreibzugriff/Lesezugriff ist ja, daß das fork() dann wesentlich schneller ist, als wenn erst alles kopiert/reserviert wird.
Dahingehend ist dein fork()-Beispiel eher schlecht gewählt und unrealistisch.
Bye, Stephan
On Mon, Jun 26, 2000 at 06:16:58PM +0200, Stephan Goetter wrote:
Meiner Meinung nach sollte man bei fork() gleich den Platz im swap reservieren und geht so bestimmt 99% der Out-Of-Memory-Situationen in Linux aus dem Weg. Mit Optimierung hat das IMO nix zu tun.
Den Platz gleich im SWAP zu reservieren macht Solaris sicherlich auch nicht.
Wieso nicht. Reservieren heisst nur, von der Zahl eine freien Seiten etwas zu subtrahieren. Das kostest nix.
Die Frage ist, soll fork() so intelligent sein und rausfinden ob, im schlechtesteten Fall, genug Speicher frei ist oder nicht.
Ich finde das sollte er. Wie gross der aktuelle Prozess ist, ist wahrscheinlich leicht herauszufinden und dann die obige Differenz auszufuehren. Was ist so schrecklich daran, etwas mehr swap anzulegen wenn man mit groesseren Programmen hantieren will?
Das ist sicher 'ne Frage für einen Statistiker, Dr. Hamann oder ?
Statistik ist gut zum optimieren. Wenn
Oft macht man nach dem fork() nämlich ein exec(). Bei einem 200 MB Prozess ist das zwar ziemlich blöd programmiert, aber theoretisch unter Linux möglich, unter Solaris anscheinend nicht.
Beim exec werden die 200MB (in meinem Beispiel) wieder zum freien Speicher hinzugerechnet und gut ist. Ich bin mir fast sicher, dass andere Systeme das genauso machen. Apropos blöd programmiert; Angenommen du hast ein grosses CAD-Programm und willst drucken. Wie wuerdest du den lpr starten?
Der Sinn der Sache mit dem warten auf einen Schreibzugriff/Lesezugriff ist ja, daß das fork() dann wesentlich schneller ist, als wenn erst alles kopiert/reserviert wird.
Völlig richtig. Ich will doch auch nicht saemtliche Seiten sofort beim fork kopieren. Das macht kein Mensch mehr da das System damit fuer heutige Ansprueche unbenutzbar lahm wäre. Ich will nur die Zahl der Seiten, die im Schreibfall (worst case) von der Speicherverwaltung bereitzustellen sind, schon zum Zeitpunkt des forks von den freien Seiten wegrechen. Deshalb gab es auch die alte regel, den swap 2-3 mal so gross wie den Hauptspeicher zu machen. Dann hat man mit Prozessen bi zu einer fuer das System normalen Groesse (=Groesse des HS) keine Probleme. Groessere Brocken bekommmen eben ENOMEM beim fork und gut. Dieser Returnwert ist schon nicht ganz sinnlos.
Das ist sonst wie mit ueberbuchten Hotels: 80 Betten habe ich, 100 verkaufe ich in der Hoffnung dass 20 Leute nicht anreisen. Kommen dann doch 85 muessen 5 mit anderen Hotels vertröstet werden. Auf Linux uebertragen wuerden 5 der 85 Gaeste erschossen. Dabei nimmt man nicht die zuletzt angereisten 5, sondern waehlt sich die Opfer zufaellig aus. Während billige Hotels das so machen, wird das in edlen Hütten nicht passieren. Diese lassen lieber mal eine Nacht 10 Betten frei als zu überbuchen. Wie so eine edles Hotel mit den betten sollte Linux mit dem Speicher umgehen. Die 10 freien Betten entspechen dort dann eine paar MB swap mehr auf der Platte.
Dahingehend ist dein fork()-Beispiel eher schlecht gewählt und unrealistisch.
Es ist *der* Hauptgrund, der zu den out_of_memory Situatioen fuehrt und diese bescheuerten kills beliebiger Prozesse nach sich zieht, die es fast nur in Linux gibt. Es gibt noch andere Varianten (Stack) um sich Speicher zu besorgen, der u.U. nicht wirklich da ist. Diese spielen aber nicht die grosse Rolle.
Reinhard
Am Mon, 26 Jun 2000 schrieb Reinhard Foerster:
Wieso nicht. Reservieren heisst nur, von der Zahl eine freien Seiten etwas zu subtrahieren. Das kostest nix.
Weiß nich, ob das nur 'ne Subtraktion ist und ohne Plattenzugriff geht. Wenn's mit Plattenzugriff ist, ist das jedenfalls blöd.
Apropos blöd programmiert; Angenommen du hast ein grosses CAD-Programm und willst drucken. Wie wuerdest du den lpr starten?
Wie gesagt, bei großen Programmen sollte man von fork() absehen, und Threads benutzen.
<snip> Vergleich zw. Hotels und Betriebssystemen... <snip>
Im Prinzip hast du ja recht.
Der Vorteil von der Art wie es Linux macht ist, das du mit weniger SWAP Programme ausführen/benutzen kannst, die relativ viel Speicher benötigen.
Ich habe z.B. keine 400 MB Swap sondern nur 64 MB SWAP und 128 RAM.
Wogen du diese Programm bei Solaris mit derselben Menge SWAP von vornherein nicht funktionieren, da es schon bei fork() mit 'nem Fehler zurückkommt.
Die teuren Hotels können sich halt leisten ein paar Zimmer leer stehen zu lassen, da die genug Geld mit den restlichen vollen Zimmern verdienen. Wogegen sich die "preiswerten", nicht billigen, Hotels darum kümmern müssen, das alles voll ausgelastet ist, um genügend Gewinn zu machen.
Das beste wäre wenn man das irgendwo im Proc einstellen könnte, wie sich fork() verhält, je nachdem ob man ein teures Serverhotel hat oder eine preiswerte Clientabsteige ;)
Bye, Stephan
On Mon, Jun 26, 2000 at 09:31:40PM +0200, Stephan Goetter wrote:
Am Mon, 26 Jun 2000 schrieb Reinhard Foerster:
Wieso nicht. Reservieren heisst nur, von der Zahl eine freien Seiten etwas zu subtrahieren. Das kostest nix.
Weiß nich, ob das nur 'ne Subtraktion ist und ohne Plattenzugriff geht. Wenn's mit Plattenzugriff ist, ist das jedenfalls blöd.
Zum a-b rechnen braucht man sicher keine Platte.
Apropos blöd programmiert; Angenommen du hast ein grosses CAD-Programm und willst drucken. Wie wuerdest du den lpr starten?
Wie gesagt, bei großen Programmen sollte man von fork() absehen, und Threads benutzen.
Und wie startest du nun den lpr wenn du threads zu Verfügung hast? Ich kenn mich damit nicht aus, kann mir allerdings nicht vorstellen, wie das ohne fork gehen soll.
Das beste wäre wenn man das irgendwo im Proc einstellen könnte, wie sich fork() verhält, je nachdem ob man ein teures Serverhotel hat oder eine preiswerte Clientabsteige ;)
Das waere nett.
Bis heute abend !?! Reinhard
Reinhard Foerster wrote:
Hallo LUG,
[fork und Speicher]
Das ist sonst wie mit ueberbuchten Hotels: 80 Betten habe ich, 100 verkaufe ich in der Hoffnung dass 20 Leute nicht anreisen. Kommen dann doch 85 muessen 5 mit anderen Hotels vertröstet werden. Auf Linux uebertragen wuerden 5 der 85 Gaeste erschossen. Dabei nimmt man nicht die zuletzt angereisten 5, sondern waehlt sich die Opfer zufaellig aus. Während billige Hotels das so machen, wird das in edlen Hütten nicht passieren. Diese lassen lieber mal eine Nacht 10 Betten frei als zu überbuchen. Wie so eine edles Hotel mit den betten sollte Linux mit dem Speicher umgehen. Die 10 freien Betten entspechen dort dann eine paar MB swap mehr auf der Platte.
IMHO ist das doch ein Statistik-Problem. Wie du oben selbst sagst, laesst ein edles Hotel auch mal ein paar Betten frei ... Die Frage ist halt nur, wieviele freie Betten man sich leisten kann (um mal beim Hotel-Bild zu bleiben). Auch wenn der Speicher heutzutage eher billig ist, ist doch ein maximale Ausnutzung erstrebenswert.
Dazu muesste man einfach mal fuer eine sehr grosse Anzahl Prozesse feststellen, wieviel ihres Speichers nach einem fork() veraendert wird. Und dann kannst du mit der Statistik berechnen wieviel mehr als vorhandenen Speicher ein fork() vergeben darf (bei einer bestimmten, von Dir frei waehlbaren Wahrscheinlichkeit, dass das dann doch noch schiefgeht). Ich habe das mal mit ueberbuchten Fluglinien gerechnet, sollte sich aber leicht auf Hotels und Speicher anpassen lassen ...
Dahingehend ist dein fork()-Beispiel eher schlecht gewählt und unrealistisch.
Es ist *der* Hauptgrund, der zu den out_of_memory Situatioen fuehrt und diese bescheuerten kills beliebiger Prozesse nach sich zieht, die es fast nur in Linux gibt.
Hm. Ich wuerde den Prozess killen, der zuviel haben wollte ...
Bye.
Jens
On Mon, Jun 26, 2000 at 10:10:50PM +0200, Jens Lorenz wrote: Hallo Jens, Hallo *,
[fork und Speicher]
[Hotel <-> Linux]Das ist sonst wie mit ueberbuchten Hotels: 80 Betten habe ich, 100
IMHO ist das doch ein Statistik-Problem. Wie du oben selbst sagst, laesst [...] Dazu muesste man einfach mal fuer eine sehr grosse Anzahl Prozesse feststellen, wieviel ihres Speichers nach einem fork() veraendert wird. Und dann kannst du mit der Statistik berechnen wieviel mehr als vorhandenen Speicher ein fork() vergeben darf (bei einer bestimmten, von Dir frei waehlbaren Wahrscheinlichkeit, dass das dann doch noch schiefgeht).
Ich finde nicht, dass man in solchen Faellen mit Statistk sehr weit kommt. Einfaches Analogon: Frag man 1000 Leute, wieviel % ihrer Festplatte maximal belegt sind. Nehmen wir mal an 80%. Nun rechnen wir noch einen grossen Sicherheitsfaktor mit ein und bauen ab heute Festplatten, die behaupten 10 GB zu speichern, real aber nur 9.5 GB Platz fassen. Wer die letzten 500MB benötigt verliert eben ein paar Daten. Was solls? Das wuerde kein Mensch machen, oder? Warum bist du dann bei deinem Betriebssystem so anspruchslos?
Ich habe das mal mit ueberbuchten Fluglinien gerechnet, sollte sich aber leicht auf Hotels und Speicher anpassen lassen ...
Klaro, das geht, nur a) ist die Ueberbuchung im Fehlerfall Kunden- bzw. Prozesssicht ziemlich aetzend b) sind unbelegte Betten/Flugzeuge vergleichsweise teuer als ein paar MB swap.
Reinhard
On Tue, 27 Jun 2000, Reinhard Foerster wrote:
On Mon, Jun 26, 2000 at 10:10:50PM +0200, Jens Lorenz wrote: Hallo Jens, Hallo *,
[fork und Speicher]
[Hotel <-> Linux]Das ist sonst wie mit ueberbuchten Hotels: 80 Betten habe ich, 100
IMHO ist das doch ein Statistik-Problem. Wie du oben selbst sagst, laesst [...] Dazu muesste man einfach mal fuer eine sehr grosse Anzahl Prozesse feststellen, wieviel ihres Speichers nach einem fork() veraendert wird. Und dann kannst du mit der Statistik berechnen wieviel mehr als vorhandenen Speicher ein fork() vergeben darf (bei einer bestimmten, von Dir frei waehlbaren Wahrscheinlichkeit, dass das dann doch noch schiefgeht).
Ich finde nicht, dass man in solchen Faellen mit Statistk sehr weit kommt. Einfaches Analogon: Frag man 1000 Leute, wieviel % ihrer Festplatte maximal belegt sind. Nehmen wir mal an 80%. Nun rechnen wir noch einen grossen Sicherheitsfaktor mit ein und bauen ab heute Festplatten, die behaupten 10 GB zu speichern, real aber nur 9.5 GB Platz fassen. Wer die letzten 500MB benötigt verliert eben ein paar Daten. Was solls? Das wuerde kein Mensch machen, oder? Warum bist du dann bei deinem Betriebssystem so anspruchslos?
Bitte nicht Aepfel und Pflaumen vergleichen! Statistisch sind das zwei voellig unterschiedliche Systeme.
Da ein Betriebssystem sowieso schon sehr langsam ist, wenn sich der Swap fuellt stoert dort ein abgeschmierter Prozess auch nicht mehr. Ausserdem trifft es in 99% der Faelle den Verursacher, da er noch mehr Speicher zieht.
Mit pessimistischen Strategien waere ausserdem der ganze Performance- und Effektivitaets-gewinn von Linux futsch.
Ein guter Admin wird also genug RAM/Swap einbauen, damit das nicht zum Flaschenhals des Systems wird. Ist der Swap voll und schmiert ein Prozess ab, war das System sowieso ueberlastet und sollte ins Maintenance-Runlevel gehen und gewartet werden.
Ich habe das mal mit ueberbuchten Fluglinien gerechnet, sollte sich aber leicht auf Hotels und Speicher anpassen lassen ...
Klaro, das geht, nur a) ist die Ueberbuchung im Fehlerfall Kunden- bzw. Prozesssicht ziemlich aetzend b) sind unbelegte Betten/Flugzeuge vergleichsweise teuer als ein paar MB swap.
ich erinnere mich da an einige aetzende Stunden BWL, Mathe und Statismus... Das Gleichungssystem ist in beiden Faellen identisch, nur die Konstanten sind anders (siehe Lagerhaltungs-theorie):
Ki=Ku*Nu Ku=Kn*Nn K=Ki+Ku -> Min
Ki=Image-Schaden Ku=Kosten einer einzelnen Ueberbelegung Nu=Anzahl Ueberbelegungen Ku=Kosten Unterbelegung Kn=Unterhaltskosten eines leeren Zimmers Nn=Anzahl Nichtbelegungen
Ku/Ki ist fuer Hotels heute so hoch, dass man Ku in Kauf nimmt. Bei Fluglienien und Programmabstuerzen sieht das ganz anders aus.
Konrad
Am Montag, dem 26. Juni 2000 um 21:15:29, schrieb Reinhard Foerster:
Es gibt noch andere Varianten (Stack) um sich Speicher zu besorgen, der u.U. nicht wirklich da ist.
Das Thema ist ziemlich ausgeleiert, so dass es sich kaum lohnt, darueber zu streiten. Auch ich halte das Solarisverhalten fuer kaputt. Vielen Dank fuer den Tip mit dem overcommit_memory im /proc-Verzeichnis. Ich hatte mich schon gewundert, warum manche Programme nicht mehr so funktionieren, wie sie es frueher einmal unter Linux taten. Ich werde heute auf unseren Rechnern overcommit_memory wieder generell auf 1 stellen, so wie es sich gehoert. ;-)
Diese spielen aber nicht die grosse Rolle.
Es gibt eine neue Statistik, die besagt, dass 95% aller Statistiken falsch sind. Auf welcher Untersuchung beruht den Deine? :) Meines Wissens gibt es keine perfekte Loesung, weswegen auch Linux sie nicht implementieren kann. Einige Fallbeispiele (siehe Solaris) abzufangen ist relativ zweckfrei bzw. dann kann man sich mit ulimit und Serverrestart behelfen.
Torsten
On Tue, Jun 27, 2000 at 05:32:45AM +0200, twerner@intercomm.de wrote:
Am Montag, dem 26. Juni 2000 um 21:15:29, schrieb Reinhard Foerster:
Es gibt noch andere Varianten (Stack) um sich Speicher zu besorgen, der u.U. nicht wirklich da ist.
Das Thema ist ziemlich ausgeleiert, so dass es sich kaum lohnt, darueber
Gut, das wird meine letzte Meldung zum Thema sein. Versprochen!
zu streiten. Auch ich halte das Solarisverhalten fuer kaputt. Vielen
Aha.Du solltest dich mal an eine Solariskiste und eine Linuxkiste setzen, die an ihre Speichergrenze kommen. Bei Linux kann du von "Verhalten" an der Stelle gar nicht mehr sprechen. Der Scheduler dreht Kreise in Erwartung mal wieder von einer Task eine freie Seite zu bekommen und loggt bei jedem erfolglosen Versuch ins syslog. Entweder hat der Kernel Glück und kommt nach einigen Minuten zum Normalbetrieb oder er macht diese fiesen Kills.
Es gibt eine neue Statistik, die besagt, dass 95% aller Statistiken falsch sind. Auf welcher Untersuchung beruht den Deine? :) Meines
Nur Annahmen. Die Zahlen habe ich so gewaehlt, dass ich auf der sicheren Seite liege. Wenn ich z.B. sage "Die CDU erhaelt in Sachsen bei der naechsten Wahl sehr viele Stimmen, naehmlich 25%." und rechne dann mit dieser 'grossen' Zahl 25 weiter wird auch keiner Fragen, wie ich auf die Idee mit den 25% komme, oder?
Wissens gibt es keine perfekte Loesung, weswegen auch Linux sie nicht implementieren kann.
Ack. Die 100%-Variante ist prinzipbedingt nicht drin. Nur empfinde ich die Linuxlösung als vergleichsweise krückig. Solaris stand dabei nur als Beispiel fuer *alle* mir bekannten unix(-artige) Systeme.
Reinhard
On Tue, Jun 27, 2000 at 10:15:30AM +0200, Reinhard Foerster wrote:
Ack. Die 100%-Variante ist prinzipbedingt nicht drin. Nur empfinde ich die Linuxloesung als vergleichsweise krueckig. Solaris stand dabei nur als Beispiel fuer *alle* mir bekannten unix(-artige) Systeme.
Es waere schoen, wenn es mehr Moeglichkeiten fuer den Admin gaebe, die Strategie zu waehlen. Selber programmieren ist dann unter Linux das Motto. Gibt es denn unter anderen Unixen die Moeglichkeit, den grundlegenden Algorithmus bei Speicherknappheit auszuwaehlen?
Ich habe hier ein Programm, welchen in ganz seltenen Faellen sehr viel Speicher braucht, meistens aber nur ganz wenig. Unter Linux kann ich das Programm in fast allen Faellen auch auf schwachbruestigen Rechnern starten sogar mehrmals, wenn ich will. Wenige Sekunden nach Programmstart (ev. sogar vorher) kann ich den baldigen Speicherverbrauch abschaetzen und zur Not ^C betaetigen. Unter Solaris koennte ich es ueberhaupt nicht starten, wegen der Swappreallocation, obwohl der Speicher fast immer ausreichen wuerde.
Diese Entscheidung sollte nicht das Betriebssystem fuer mich treffen. Wenn ich ein Programm starte, soll es auch ausgefuehrt werden, solange die aktuellen Resourcen reichen. In meinen Augen ist der Solaris-Algorithmus krueckig, zumal er sowieso nicht alle denkbaren Faellen abdeckt. Uebrigens wurde das Thema erst im Maerz auf der Kernel-Mailing-Liste ausgewaelzt. Ein Nachlesen im Archiv lohnt sich.
Torsten
Am Die den 27 Jun 2000 um 10:43:32 +0200 schrieb Torsten Werner:
On Tue, Jun 27, 2000 at 10:15:30AM +0200, Reinhard Foerster wrote:
Ack. Die 100%-Variante ist prinzipbedingt nicht drin. Nur empfinde ich die Linuxloesung als vergleichsweise krueckig. Solaris stand dabei nur als Beispiel fuer *alle* mir bekannten unix(-artige) Systeme.
Es waere schoen, wenn es mehr Moeglichkeiten fuer den Admin gaebe, die Strategie zu waehlen. Selber programmieren ist dann unter Linux das Motto. Gibt es denn unter anderen Unixen die Moeglichkeit, den grundlegenden Algorithmus bei Speicherknappheit auszuwaehlen?
das argument ist doch recht primitiv: blos weil man bei linux theoretisch die moeglichkeit hat, am kernel herumzupfuschen, so mindert das noch nicht die unterlegenheit des kernels in diesem falle.
Ich habe hier ein Programm, welchen in ganz seltenen Faellen sehr viel Speicher braucht, meistens aber nur ganz wenig. Unter Linux kann ich das Programm in fast allen Faellen auch auf schwachbruestigen Rechnern starten sogar mehrmals, wenn ich will. Wenige Sekunden nach
hier ist doch was in dem thread kaputt: weil man ein dummes programm mit einem (in dieser hinsicht) kaputtem kernel noch betreiben kann, so kann ich darin ja nun wirklich keinen vorteil sehen.
Programmstart (ev. sogar vorher) kann ich den baldigen Speicherverbrauch abschaetzen und zur Not ^C betaetigen. Unter Solaris koennte ich es
gegenvorschlag: ich stelle dich ein, damit du dich neben die kiste setzt und immer top beobachtest um den datenbankserver rechtzeitig zu killen.
ueberhaupt nicht starten, wegen der Swappreallocation, obwohl der Speicher fast immer ausreichen wuerde.
und wenn er mal nicht reicht, geht das grosse gemetzel los ;-) probier das einfach mal mit einem anderen programm, als dem deinen aus. es war wirklich traurig zu zu sehen, wie ein prozess nach dem anderen stirbt. das ist doch kanibalismus. stell' dir mal vor, windows wuerde so was machen, da wuerden doch alle unixer sich vor lachen kruemmen.
Diese Entscheidung sollte nicht das Betriebssystem fuer mich treffen.
das ist wie mit geld: entweder man kann sich etwas leisten, oder nicht. im letzteren falle sollte man die haende davon lassen, sonst landet man in der schuldenfalle.
es geht in diesem thread doch nicht um die glaubensfrage: linux ist toll oder nicht. man hat hier eben etwas platz fuer verbesserung frei gelassen,
andre
On Tue, 27 Jun 2000, Andre Schulze wrote:
Am Die den 27 Jun 2000 um 10:43:32 +0200 schrieb Torsten Werner:
ueberhaupt nicht starten, wegen der Swappreallocation, obwohl der Speicher fast immer ausreichen wuerde.
und wenn er mal nicht reicht, geht das grosse gemetzel los ;-) probier das einfach mal mit einem anderen programm, als dem deinen aus. es war wirklich traurig zu zu sehen, wie ein prozess nach dem anderen stirbt. das ist doch kanibalismus. stell' dir mal vor, windows wuerde so was machen, da wuerden doch alle unixer sich vor lachen kruemmen.
1. Zitat: StarGate "Die Saat des Verrats", Thor zu O'Neill: "Um es mal ganz klar zu sagen, das ist keine perfekte Galaxie." (nicht suchen, kam noch nicht auf RTL II)
2. Statement: es gibt einen kleinen Unterschied zwischen einfachen, guten und kritischen Programmen.
einfache: siehe auch simple Tools, Testversionen, Alpha und miese Programmierer (z.B. die meisten meiner einfachen kleinen Tools, denen es egal ist, ob sie abschmieren)
gute: machen immerhin Checks, ob malloc Speicher gebracht hat oder ein SIGSEGV angekommen ist (Simulatoren, einfache Datenbanken usw.)
kritische: init, Security-Monitore, wichtige Daemonen; die Programmierer dieser Teile haben die Pflicht(!!!) den Copy-On-Write Algorithmus zu ueberlisten, indem direkt nach dem fork() alle Datenseiten angefasst werden.
Kurzgefasst: das System faehrt eine Strategie, die fuer alle guten Programme ok ist (schmiert kpanel halt ab, starten wir's neu). Die kritischen Programme kuemmern sich gefaelligst selbst.
Diese Entscheidung sollte nicht das Betriebssystem fuer mich treffen.
das ist wie mit geld: entweder man kann sich etwas leisten, oder nicht. im letzteren falle sollte man die haende davon lassen, sonst landet man in der schuldenfalle.
Schonmal was von Ueberziehungskrediten gehoert? Oder auch Dispo?
Motto: wer nicht wagt, der nicht performanced. ;-)
es geht in diesem thread doch nicht um die glaubensfrage: linux ist toll oder nicht. man hat hier eben etwas platz fuer verbesserung frei gelassen,
...und was genau wuerdest Du implementieren wollen? Ich sehe jedenfalls kein Problem: wenn man den Rechner zum rummetzeln kriegt ist das eigentlich nur ein Symptom an dem man nicht rumdoktern sollte:
a) es ist ein WebServer unter einer DOS-Attacke -> runterfahren, Security-Updates, hochfahren b) ein User-Rechner mit zu grossen gimp-Bildern oder einem ausgeflipptem StarOffice -> das Programm schmiert schon irgendwann selbst ab, Truemmer aufraeumen, Sponsor suchen (Eltern, Oma, Frau/Mann, eigenes Konto) und Speicher kaufen oder sich abgewoehnen zu viele Programme gleichzeitig laufen zu haben - ist eh' nicht gesund fuer die Performance c) ein unterdimensionierter DB-Server: entweder auf mehrere verteilen oder die DB neu designen bzw. aufraeumen(reorganisieren) oder Speicher kaufen d) irgendein anderer ueberlasteter Server: siehe c
Wenn 90% des Swap voll sind ist das System eindeutig ueberlastet. Da sollte man nicht den Kernel anschreien, sondern ihm zusaetzliche Ressourcen geben, damit er nicht mehr ueberlastet ist. (Man muss ja nicht unbeding teure RamBus Module einsetzen.)
Konrad
Hallo!
- Zitat: StarGate "Die Saat des Verrats", Thor zu O'Neill: "Um es mal ganz
klar zu sagen, das ist keine perfekte Galaxie." (nicht suchen, kam noch nicht auf RTL II)
Nette Ausrede, muß ich mir für meinen Chef merken...
- Statement: es gibt einen kleinen Unterschied zwischen einfachen, guten und
kritischen Programmen.
einfache: siehe auch simple Tools, Testversionen, Alpha und miese Programmierer (z.B. die meisten meiner einfachen kleinen Tools, denen es egal ist, ob sie abschmieren)
Auf einem Produktionsserver würde ich weder Test- noch Alphaversionen verwenden. Simple Tools die nicht mal die üblichen Fehlermeldungen abfangen sind durchaus auch von miesen Programmierern geschrieben worden (ich schau niemanden an...)
gute: machen immerhin Checks, ob malloc Speicher gebracht hat oder ein SIGSEGV angekommen ist (Simulatoren, einfache Datenbanken usw.)
kritische: init, Security-Monitore, wichtige Daemonen; die Programmierer dieser Teile haben die Pflicht(!!!) den Copy-On-Write Algorithmus zu ueberlisten, indem direkt nach dem fork() alle Datenseiten angefasst werden.
Was nicht heißt, das es nicht doch wegen Speichermangels abgeschossen wird.
Kurzgefasst: das System faehrt eine Strategie, die fuer alle guten Programme ok ist (schmiert kpanel halt ab, starten wir's neu). Die kritischen Programme kuemmern sich gefaelligst selbst.
Oh Mann, damit schießt Du den Vogel ab. Warum brauche ich dann überhaupt ein Betriebssystem. Hmm, ich geh dann mal zu Prof. Härtig und sage Ihm Bescheid, daß er seinen Lehrstuhl (OS) zumachen kann, da wir alle wieder DOS benutzen und die ganzen fancy OS-features nicht brauchen.
Motto: wer nicht wagt, der nicht performanced. ;-)
Ich glaube die Betreiber von richtig wichtigen Rechnern wagen lieber nicht...
a) es ist ein WebServer unter einer DOS-Attacke -> runterfahren, Security-Updates, hochfahren b) ein User-Rechner mit zu grossen gimp-Bildern oder einem ausgeflipptem StarOffice -> das Programm schmiert schon irgendwann selbst ab, Truemmer aufraeumen, Sponsor suchen (Eltern, Oma, Frau/Mann, eigenes Konto) und Speicher kaufen oder sich abgewoehnen zu viele Programme gleichzeitig laufen zu haben - ist eh' nicht gesund fuer die Performance
Das klingt nach MSDOS-Evangelist. Wozu brauch ich mehrere Programme gleichzeitig? Wenn was kaputt geht mach ich es eben wieder ganz? So ein Scheiß. Kann es sein, daß Du in Redmond einer Gehirnwäsche unterzogen worden bist?
c) ein unterdimensionierter DB-Server: entweder auf mehrere verteilen oder die DB neu designen bzw. aufraeumen(reorganisieren) oder Speicher kaufen d) irgendein anderer ueberlasteter Server: siehe c
Wenn 90% des Swap voll sind ist das System eindeutig ueberlastet. Da sollte man nicht den Kernel anschreien, sondern ihm zusaetzliche Ressourcen geben, damit er nicht mehr ueberlastet ist. (Man muss ja nicht unbeding teure RamBus Module einsetzen.)
Folgender Fall: Ein Server wickelt Kundentransaktionen ab (Datenbank). Plötzlich gibt es kurzzeitigen Ansturm von Kunden. Sollten dann einige Kunden auf später vertröstet werden oder lieber der Server alle Viere von sich strecken und damit alle Kunden vergrault werden? Auch ein "Home-user" will nicht das irgendein beliebiges Programm undefiniert abschmiert, weil ein Anderes den Speicher vollmüllt, besonders da man nicht gleich merken muß, daß da was abgeschossen wurde. Wenn ich eine saubere "out-of-memory" Meldung bekomme, weiß ich woran ich bin.
Vielleicht solltest Du lieber erst mal nachdenken, bevor Du sowas schreibst.
Eric
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 28 Jun 2000, did Eric Schaefer mean: [cut]
Das klingt nach MSDOS-Evangelist. Wozu brauch ich mehrere Programme gleichzeitig? Wenn was kaputt geht mach ich es eben wieder ganz? So ein Scheiß. Kann es sein, daß Du in Redmond einer Gehirnwäsche unterzogen worden bist?
[cut]
muessen wir wirklich auf das Niveau persoenlicher Beleidigungen ausweichen?
Weiss hier jemand _wirklich_ _exakt_ wie der Kernel sich bei vollem Speicher verhaelt? Und warum?
Wenn ja: bitte mal posten, dann koennen wir sachlich weitermachen. Wenn nein: betrachte ich diesen Thread als beendet. - -> ja, das ist drastisch, aber ein halbes dutzend Flamewars ist genug fuer mich, hier ist Schluss.
Konrad
On Tue, Jun 27, 2000 at 05:40:10PM +0200, Andre Schulze wrote:
Am Die den 27 Jun 2000 um 10:43:32 +0200 schrieb Torsten Werner:
Selber programmieren ist dann unter Linux das Motto.
das argument ist doch recht primitiv: blos weil man bei linux theoretisch die moeglichkeit hat, am kernel herumzupfuschen, so mindert das noch nicht die unterlegenheit des kernels in diesem falle.
Wieso Unterlegenheit des Kernels? Unter Linux kann ein Prozess, der 60% des virtuellen Speichers belegt, ein fork() gefolgt von einem exec("/bin/ls") ausfuehren, auch wenn ein gewisses Risiko darin liegt. Solaris erlaubt das nicht, weil es meint, es waere gar nicht genug Speicher da, wobei es trotzdem noch moeglich ist, Solaris mit anderen Sachen in Bedraengnis zu bringen (Bsp.: gesamter virtueller Speicher ist preallocated aber 40% sind noch unangetastet und ein nun folgendes malloc im wichtigsten Daemon des Systems schlaegt fehlt).
Ich sehe die Sache so, dass Linux immer die Schiene maximaler Performance waehlt, waehrend Solaris einen faulen Kompromiss zwischen Stabilitaet in Einzelfaellen und den nicht abfangbaren Faellen waehlt, der am Ende nur ein marginal stabileres System mit schlechter Performance hervorbringt. Ich kann nicht erkennen, wieso Linux hier prinzipell als schlechter bezeichnet wird.
Torsten
Am Tue den 27 Jun 2000 um 05:32:45AM +0200 schrieb twerner@intercomm.de:
Das Thema ist ziemlich ausgeleiert, so dass es sich kaum lohnt, darueber zu streiten. Auch ich halte das Solarisverhalten fuer kaputt. Vielen Dank fuer den Tip mit dem overcommit_memory im /proc-Verzeichnis.
ich verstehe die welt nicht mehr.
Ich hatte mich schon gewundert, warum manche Programme nicht mehr so funktionieren, wie sie es frueher einmal unter Linux taten. Ich werde heute auf unseren Rechnern overcommit_memory wieder generell auf 1 stellen, so wie es sich gehoert. ;-)
ok, damit sollte man einen "netzwerk speicher allokalisierungs dienst" implementieren. ich schreibe ein daemon, der speicher fuer clients auf der linux kiste reserviert und speicher i/o ueber das netz macht. sehen wir mal von der performance ab, dann loest dies alle speicherknappheit dieser welt.
sorry, das war nicht produktiv, verdeutlicht doch, wie kaputt eure meinung ist. ich verspreche, nix mehr zu dem thema zu posten.
andre
lug-dd@mailman.schlittermann.de
-
Andre Schulze -
Eric Schaefer -
Jens Lorenz -
Konrad Rosenbaum -
Reinhard Foerster -
Stephan Goetter -
Torsten Werner -
twerner＠intercomm.de