Speicherbedarf zur Laufzeit ermitteln
Stephan Menzel
ich habe hier ein relativ komplexes Binary mit kurzer Laufzeit (<30sec)
welches anscheinend in gaaanz aeusserst seltenen Faellen eine Art
Speicherfresser ist.
Umgebung ist Linux 2.6.9.
Im kernellog erhalte ich eine Meldung wie:
----
Out of Memory: Killed process 20354 (mytool) using 1820504 kB.
----
Normalerweise bewegt sich der Bedarf so um die 2 Megs.
Nun laeuft dieses Binary so haeufig und diese Meldung ist so extrem selten
dass ich einen solchen Fall bisher nicht nachstellen oder reproduzieren
konnte. Ich seh's halt nur irgendwann in den Logs.
Deswegen will ich an strategisch guenstiger Stelle eine Art Schutz einbauen,
die mir fuer den Fall dass der Speicherbedarf eine gewisse Groesse
uebersteigt (die Art Bedarf die zu obigem fuehren wuerde), zumindest eine
sichere Landung nebst Logmeldung ermoeglicht. Die Frage ist: Wie?
Geht sowas Programmtechnisch? Und auch noch ressourcenschonend (ps rufen und
Ergebnis parsen ist eher keine Option)?
Oder gibt's vielleicht einen Syscall, eine Funktion die mir den aktuellen
Bedarf ausgibt?
Weiterhin frage ich mich, wie es ueberhaupt zu sowas kommen kann.
Normalerweise wird doch neuer Speicher mittels new oder malloc durch
wohldefinierte Rueckgabewerte abgelehnt, wenn keiner mehr da ist und nicht
einfach gewaehrt und der Prozess dann abgeschossen. Und wenn doch, wie kam
der Prozess zu so viel Speicher?
Fragen ueber Fragen...
Hat jemand eine Idee fuer mich?
Vielen Dank und Gruesse...
Stephan
--
Freedom isn't lost in one big step when the storm-troopers
show up at your door. It is lost in little pieces, each
so small that they tend to be ignored.
Richard B. Johnson
Thomas Rachel
> ich habe hier ein relativ komplexes Binary mit kurzer Laufzeit (<30sec)
> welches anscheinend in gaaanz aeusserst seltenen Faellen eine Art
> Speicherfresser ist.
>
> Umgebung ist Linux 2.6.9.
> Im kernellog erhalte ich eine Meldung wie:
>
> ----
> Out of Memory: Killed process 20354 (mytool) using 1820504 kB.
> ----
>
> Normalerweise bewegt sich der Bedarf so um die 2 Megs.
Hm, seltsam.
U. U. hilft Dir aber ulimit weiter (help ulimit / man 3 ulimit)
Damit kannst Du ein Limit einstellen, wie viel das Programm benutzen darf.
> Normalerweise wird doch neuer Speicher mittels new oder malloc durch
> wohldefinierte Rueckgabewerte abgelehnt, wenn keiner mehr da ist und nicht
> einfach gewaehrt und der Prozess dann abgeschossen.
C/C++seitig ist das wohl so, aber der Memory-Manager von Linux gewährt immer
erstmal und knallt erst, wenns zu spät ist.
Das kann man bei Bedarf zwar umstellen, allerdings weiß ich nicht auswendig,
wie das geht. Google mal nach OOM killer...
Thomas
Stephan Menzel
> Hm, seltsam.
>
> U. U. hilft Dir aber ulimit weiter (help ulimit / man 3 ulimit)
Gute Idee.
Auf den betreffenden Kisten steht ziemlich alles auf unlimited. Anscheinend
kann man sich unter diesen Bedingungen if (!(v = malloc(..))) knicken,
weil's eh nie soweit kommt.
Sehr merkwuerdig.
> Das kann man bei Bedarf zwar umstellen, allerdings weiß ich nicht
> auswendig, wie das geht. Google mal nach OOM killer...
Out Of Memory Killer, lese ich gerade. Ziemlich Kernel-esotherisch
allerdings um sich als Normalo damit auszukennen.
Ronny Spiegel
> G'day dcoup,
Good morning,
> Deswegen will ich an strategisch guenstiger Stelle eine Art Schutz einbauen,
> die mir fuer den Fall dass der Speicherbedarf eine gewisse Groesse
> uebersteigt (die Art Bedarf die zu obigem fuehren wuerde), zumindest eine
> sichere Landung nebst Logmeldung ermoeglicht. Die Frage ist: Wie?
> Geht sowas Programmtechnisch? Und auch noch ressourcenschonend (ps rufen und
> Ergebnis parsen ist eher keine Option)?
> Oder gibt's vielleicht einen Syscall, eine Funktion die mir den aktuellen
> Bedarf ausgibt?
Du könntest /proc/self/status auslesen und dort die Vm*-Zeilen auswerten.
Gruss,
RSp
Stephan Menzel
> Good morning,
Indeed.
Und was fuer ein morgen das ist.
> Du könntest /proc/self/status auslesen und dort die Vm*-Zeilen auswerten.
Ja, ebenfalls eine gute Idee.
Im Grunde ist es dann VmSize was mich interessiert, nehme ich an.
Ich hab' jetzt ausserdem eine Loesung mit setrlimit angepeilt, die mir
zumindest eine saubere Auswertung von malloc und new ermoeglichen sollte.
Ronny Spiegel
>>Du könntest /proc/self/status auslesen und dort die Vm*-Zeilen auswerten.
>
>
> Ja, ebenfalls eine gute Idee.
> Im Grunde ist es dann VmSize was mich interessiert, nehme ich an.
vielleicht nicht ganz,hab gerade mal gesucht:
VmSize: Virtual memory usage of entire process
= VmLib + VmExe + VmData + VmStk
VmRSS: Resident Set currently in physical memory including Code, Data, Stack
VmData: Virtual memory usage of Heap
VmStk: Virtual memory usage of Stack
VmExe: Virtual memory usage by executable and statically linked libraries
VmLib: Virtual memory usage by dlls loaded
Greetz,
Rooney
Daniel Roedding
> Deswegen will ich an strategisch guenstiger Stelle eine Art Schutz einbauen,
> die mir fuer den Fall dass der Speicherbedarf eine gewisse Groesse
> uebersteigt (die Art Bedarf die zu obigem fuehren wuerde), zumindest eine
> sichere Landung nebst Logmeldung ermoeglicht. Die Frage ist: Wie?
mallinfo() wurde glaub' ich noch nicht genannt. Liefert Dir eine
struct mallinfo zurück, in der Du die Elemente uordblks (tatsächlich
prozeßseitig allokierter Speicher) und arena (Speichergröße, wie
die lib sie per sbrk() angefordert hat) auswerten kannst.
Daniel
Tibor Pausz
> Weiterhin frage ich mich, wie es ueberhaupt zu sowas kommen kann.
Es ist Linux, da braucht man sich über unsinnige "Performance"
Tuningmaßnahmen nicht zu wundern. Im Zweifelsfall hat man sich bei Linux
immer für die unsicheren Einstellungen als die Vorgabeeinstellung
entschieden, wie sinnvoll das ist kann jeder selbst entscheiden.
"Memory overcommitment" heißt das Problem,
/proc/sys/vm/overcommitment_memory
kann man verändern. Default ist 0, zur Auswahl stehen noch 1
(abgeschaltet) und 2 (anderer Algorithmus). Mit 1 funktionieren C, C++
und alle anderen Programme so wie sie es sollen. Andernfalls wird
erstmal der Speicher zugeteilt und es knallt sobald man auf den Speicher
schreiben will, wenn nicht mehr ausreichend Speicher im RAM + Swap
vorhanden ist.
Rainer Weikusat
> ich habe hier ein relativ komplexes Binary mit kurzer Laufzeit (<30sec)
> welches anscheinend in gaaanz aeusserst seltenen Faellen eine Art
> Speicherfresser ist.
>
> Umgebung ist Linux 2.6.9.
> Im kernellog erhalte ich eine Meldung wie:
>
> ----
> Out of Memory: Killed process 20354 (mytool) using 1820504 kB.
> ----
>
> Normalerweise bewegt sich der Bedarf so um die 2 Megs.
>
> Nun laeuft dieses Binary so haeufig und diese Meldung ist so extrem selten
> dass ich einen solchen Fall bisher nicht nachstellen oder reproduzieren
> konnte. Ich seh's halt nur irgendwann in den Logs.
> Deswegen will ich an strategisch guenstiger Stelle eine Art Schutz einbauen,
> die mir fuer den Fall dass der Speicherbedarf eine gewisse Groesse
> uebersteigt (die Art Bedarf die zu obigem fuehren wuerde), zumindest eine
> sichere Landung nebst Logmeldung ermoeglicht. Die Frage ist: Wie?
Es waere sinnvoller, nach dem Fehler zu suchen, der fuer diese
'unbounded allocation' verwantwortlich ist.
> Geht sowas Programmtechnisch? Und auch noch ressourcenschonend (ps rufen und
> Ergebnis parsen ist eher keine Option)?
'malloc' benutzt als "primitives" unter Linux sbrk (bzw brk) und
mmap. Du koenntest einen wrapper benutzen, der beide ersetzt und Dir.
eine beliebige 'Buchfuehrung' ermoeglicht (und natuerlich letzten
Endes die Original-Routinen aufruft).
NB: Ich weiss, dass das moeglich ist, aber selber gemacht habe ich es
noch nicht, dh ich weiss nicht, wieviel Aufwand das waere.
> Weiterhin frage ich mich, wie es ueberhaupt zu sowas kommen kann.
> Normalerweise wird doch neuer Speicher mittels new oder malloc durch
> wohldefinierte Rueckgabewerte abgelehnt, wenn keiner mehr da ist und nicht
> einfach gewaehrt und der Prozess dann abgeschossen.
Das ist mit "modernen" (C++)-Anwendungunge nicht mehr ganz so einfach,
denn die fordern eben alle viel mehr Speicher an, als sie zu jedem
Zeitpunkt tatsaechlich brauchen, weswegen jemand auf 'genialen'
Einfall gekommen ist, den Allokationsaufruf immer 'Ok' zurueckliefern
zu lassen, was dazu fuehrt, das man solche Programme benutzten kann,
solange sie nicht tatsaechlich mal den von ihnen angeforderten
Speicher benoetigen (respektive soviel davon gleichzeitig, das der
virtuelle Speicher des Systems dafuer nicht mehr ausreicht).
Rainer Weikusat
> Stephan Menzel <stephan...@web.de> wrote:
>
>> Weiterhin frage ich mich, wie es ueberhaupt zu sowas kommen kann.
>
> Es ist Linux, da braucht man sich über unsinnige "Performance"
> Tuningmaßnahmen nicht zu wundern.
Es ist aber gar keine "performance-Tuningmassnahme" und "unsinnig" ist
sie auch nicht: Es ist der Versuch des kernels, dem Benutzer das
benutzen seines Systems zu ermoeglichen, obwohl in diverse von
Minderbemittelten entwickelte Anwendungen moeglichst daran zu hindern
versuchen.
> Im Zweifelsfall hat man sich bei Linux immer für die unsicheren
> Einstellungen als die Vorgabeeinstellung entschieden,
Fuehre doch bitte mal ein paar (wenigstens drei) solcher
'Zweifelsfaelle' an, nebst der Entscheidung, die getroffen wurde, und
begruende, was Du warum anders entschieden haettest. Dann kann sich
jeder selbst ueberlegen, inwiefern er Deinem Urteil zustimmt oder man
koennte vielleicht sogar darueber diskutieren (im de-Usenet generell
unbeliebt), welcher Standppunkt welche relativen Vorzuege oder
Nachteile bezogen auf die anderen hat.
Das Urteil des Kabelfernseh-Abhaengigen, naemlich "das nervt aber"
[Kanalwechsel] ist zu undifferenziert, um verstaendlich zu sein, und
zu oberflaechlich begruendet, als das man ihm zustimmen koennte.
Patrick Schaaf
>> Deswegen will ich an strategisch guenstiger Stelle eine Art Schutz einbauen,
>> die mir fuer den Fall dass der Speicherbedarf eine gewisse Groesse
>> uebersteigt (die Art Bedarf die zu obigem fuehren wuerde), zumindest eine
>> sichere Landung nebst Logmeldung ermoeglicht. Die Frage ist: Wie?
>Es waere sinnvoller, nach dem Fehler zu suchen, der fuer diese
>'unbounded allocation' verwantwortlich ist.
ACK.
>> Geht sowas Programmtechnisch? Und auch noch ressourcenschonend (ps rufen und
>> Ergebnis parsen ist eher keine Option)?
>'malloc' benutzt als "primitives" unter Linux sbrk (bzw brk) und
>mmap. Du koenntest einen wrapper benutzen, der beide ersetzt und Dir.
>eine beliebige 'Buchfuehrung' ermoeglicht (und natuerlich letzten
>Endes die Original-Routinen aufruft).
>NB: Ich weiss, dass das moeglich ist, aber selber gemacht habe ich es
>noch nicht, dh ich weiss nicht, wieviel Aufwand das waere.
Es wird einfacher sein, /proc/net/status zu lesen.
Gruss
Patrick
Thomas Jahns
> Stephan Menzel <stephan...@web.de> writes:
> > Weiterhin frage ich mich, wie es ueberhaupt zu sowas kommen kann.
> > Normalerweise wird doch neuer Speicher mittels new oder malloc durch
> > wohldefinierte Rueckgabewerte abgelehnt, wenn keiner mehr da ist und nicht
> > einfach gewaehrt und der Prozess dann abgeschossen.
>
> Das ist mit "modernen" (C++)-Anwendungunge nicht mehr ganz so einfach,
> denn die fordern eben alle viel mehr Speicher an, als sie zu jedem
> Zeitpunkt tatsaechlich brauchen, weswegen jemand auf 'genialen'
> Einfall gekommen ist, den Allokationsaufruf immer 'Ok' zurueckliefern
> zu lassen, was dazu fuehrt, das man solche Programme benutzten kann,
> solange sie nicht tatsaechlich mal den von ihnen angeforderten
> Speicher benoetigen (respektive soviel davon gleichzeitig, das der
> virtuelle Speicher des Systems dafuer nicht mehr ausreicht).
Ein weiterer Grund war wohl in anderen Systemen als Linux, daß
Fortran77-Programmierer nicht selten Matrizen und andere Strukturen
(mangels einfach funktionierender dynamischer Allozierung) einfach so
groß machen, daß sie für "alle auftretenden Probleme" groß genug sind.
In der Folge mußten alle Benutzer dieser Programme, die kleinere
Probleme bearbeiten, entweder
a) den Speicher bzw. Swap ausbauen,
b) den Code durchforschen, ändern und neu kompilieren oder
c) den Betriebssystemhersteller um eine Lösung anflehen.
Da wohl c) zu verführerisch war, ist mir mindestens ein kommerzielles
Unix bekannt, das virtual swap vor Linux beherrschte. Insofern würde ich
hier weniger von einer wirklich neu getroffenen Entscheidung als eher
der Duplizierung von bereits ausgetretenen Pfaden in Linux sprechen. Da
swap inzwischen aber sehr billig ist, stellt sich mir die Frage, warum
dieser Zustand anhält, vermutlich unterschätze ich einfach die, von
Rainer angesprochenen, C++-Coder.
Thomas Jahns
--
"Computers are good at following instructions,
but not at reading your mind."
D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9
Andreas Pflug
> 'malloc' benutzt als "primitives" unter Linux sbrk (bzw brk) und
> mmap. Du koenntest einen wrapper benutzen, der beide ersetzt und Dir.
> eine beliebige 'Buchfuehrung' ermoeglicht (und natuerlich letzten
> Endes die Original-Routinen aufruft).
>
> NB: Ich weiss, dass das moeglich ist, aber selber gemacht habe ich es
> noch nicht, dh ich weiss nicht, wieviel Aufwand das waere.
ich habe was ähnliches mal für die Operatoren new, delete, new[] und
delete[] gemacht - zu finden z. B. unter Google-Groups und
den Stichwörtern [Pflug "heap_debugging"] bzw.
Message-Id <86ad26b...@node1.haktar>.
Hierbei erzeugt jeder dieser Operatoren einen Log-Eintrag
in einer statisch instanziierten Log-Datei, die anschließend
mit einem Perl-Skript ausgewertet wird.
Das Problem mit den üblichen Tools wie electric fence und dem libc
allocation debugging etc. war, dass diese hauptsächlich auf die
malloc/free-Routinen in der libc gucken. Nutzt man dann hauptsächlich
new/new[]/delete/delete[], so bekommt man bei Memory-Fehlern
immer nur Verweise auf die malloc-Routine in der Implementierung von
operator new, was einen nicht wirklich weiterhilft.
Das ganze sieht auf den ersten Blick etwas umständlich aus, man kann damit
aber tatsächlich auch komplexere C++-Programme faktisch
frei von Memory-Leaks bekommen.
MfG
Andreas