Hi! Gibt es in C/C++ eine Möglichkeit, den noch verfügbaren RAM-Speicher abzufragen (es soll nicht geswapt werden)? Ich würde damit gerne den Speicher begrenzen, den ich dynamisch durech mein Programm anfordere. Rein rechnerisch könnte ich das zwar einschränken, in dem ich z.B. nur 256 MB Speicher anfordere (also quasi eine Art Mindestanforderung). Hat mein User allerdings nebenbei noch drei andere Programme am Laufen, reicht das wieder nicht und das geswappe geht wieder los. CU und schonmal danke für Eure Antworten Martin
Hi, On 6 Aug 2002, Martin Oehler wrote:
Gibt es in C/C++ eine Möglichkeit, den noch verfügbaren RAM-Speicher abzufragen (es soll nicht geswapt werden)?
Sowas gibt's eigentlich per Design nicht (eben weil wegen swapping ja immer genug Speicher da ist). Du kannst es also entweder an einen vom User anzugebenden Parameter koppeln, oder, wenn du linux-spezifisch bleiben willst, und ueble Hacks nicht scheust, einfach /proc/meminfo auslesen. Ich wuerde sagen (MemFree + Buffers + Cached) * 0.9 oder 0.8 ist ein recht guter Wert fuer freien Speicher, und laesst noch etwas ueber fuer Puffer und andere Prozesse. Ciao, Micha.
Am Die, 2002-08-06 um 16.44 schrieb Michael Matz:
Hi,
On 6 Aug 2002, Martin Oehler wrote:
Gibt es in C/C++ eine Möglichkeit, den noch verfügbaren RAM-Speicher abzufragen (es soll nicht geswapt werden)?
Sowas gibt's eigentlich per Design nicht (eben weil wegen swapping ja immer genug Speicher da ist). ACK. Drum immer schön mallocs auf NULL checken ;)
Du kannst es also entweder an einen vom User anzugebenden Parameter koppeln, oder, wenn du linux-spezifisch bleiben willst, und ueble Hacks nicht scheust, einfach /proc/meminfo auslesen. Ich würde beides lassen ;)
So banal es klingen mal, wenn Dein Progi regelmässig derart viel Speicher wirklich benötigt (d.h. dauerhaft im Zugriff haben muss) und Du mit Swapping nicht leben kannst, ist dein Specher unterdimensioniert. Wenn der Speicher allerdings nicht wirklich dauerhaft im Zugriff steht, sollest Du mal über das interne Design deines Programmes nachdenken (Wo kann Speicher gespart werden, muss wirklich immer alles im Speicher hängen, wo/wie kann ich Daten auslagern usw. usf).
Ich wuerde sagen (MemFree + Buffers + Cached) * 0.9 oder 0.8 ist ein recht guter Wert fuer freien Speicher, und laesst noch etwas ueber fuer Puffer und andere Prozesse. Nur ist das für Apps praktisch ohne Belang: Zwischen phys. und virt. Memory bzw. Addressbereich funken noch ulimits u.Co. hinein (man getrlimits, man ulimit)
Ralf
Hi, On 6 Aug 2002, Ralf Corsepius wrote:
[... wer sowas braucht hat zuwenig Speicher, oder ein falsch designtes Programm ...]
Klar, nur werden derlei Antworten von Leuten mit diesen Fragen ueblicherweise nicht gern gehoert ;-) "Wie kann ich dass mit wenig Aufwand machen?" - "Designe einfach dein Programm komplett um" ;-)
Ich wuerde sagen (MemFree + Buffers + Cached) * 0.9 oder 0.8 ist ein recht guter Wert fuer freien Speicher, und laesst noch etwas ueber fuer Puffer und andere Prozesse. Nur ist das für Apps praktisch ohne Belang: Zwischen phys. und virt. Memory bzw. Addressbereich funken noch ulimits u.Co. hinein (man getrlimits, man ulimit)
Er fragte nach freiem Speicher, also gab ich ihn ihm ;) Ob ulimits das begrenzen (ist naemlich bei SuSE per default ehh nicht der Fall), der Benutzer diese limits groesser machen muss, oder es nur solange gilt, wie nicht irgendwer mozilla startet :), ist doch egal. Dass ein Programm, welches sowas braucht, meist unklug designed ist, versteht sich von selbst, zumal obiges nicht mal ne Loesung ist, da natuerlich immer noch geswappt wird, wenn der Kernel dies vernuenftig findet. Ich sag jetzt lieber nicht, wie man das verhindert, sowas waere erschiessungswuerdig. Abgesehen davon: Ein Programm, was seinen eigenen Speicherverbrauch heuristisch an den RAM-Vorrat anpasst, ist nicht von vornherein schlecht. Wenn die Algorithmen im Hintergrund halt schneller/besser werden, wenn man mehr Speicher reinwirft, dann will man das wohl tun, ohne allerdings mit allzu hoher Wahrscheinlichkeit ins Swap zu muessen. Ciao, Micha.
Hi! Am Die, 2002-08-06 um 17.47 schrieb Michael Matz:
On 6 Aug 2002, Ralf Corsepius wrote:
[... wer sowas braucht hat zuwenig Speicher, oder ein falsch designtes Programm ...]
Klar, nur werden derlei Antworten von Leuten mit diesen Fragen ueblicherweise nicht gern gehoert ;-) "Wie kann ich dass mit wenig Aufwand machen?" - "Designe einfach dein Programm komplett um" ;-)
Die Antwort ist brutal, aber vielleicht nicht verkehrt. Die Größe der Datensätze auf denen die Software arbeitet, ist eigentlich für einen PC noch in Ordnung. Doch mit den Verfahren wirds wohl zu viel. Letztenendes wird auf kurz oder lang wohl eine Strategie her müssen, um Daten effizient von der Platte zu laden. Bis dahin wollte ich eine SW-mäßige Begrenzung einbauen.
Abgesehen davon: Ein Programm, was seinen eigenen Speicherverbrauch heuristisch an den RAM-Vorrat anpasst, ist nicht von vornherein schlecht. Wenn die Algorithmen im Hintergrund halt schneller/besser werden, wenn man mehr Speicher reinwirft, dann will man das wohl tun, ohne allerdings mit allzu hoher Wahrscheinlichkeit ins Swap zu muessen.
Mein Gedanke :) CU und vielen Dank! Martin
On Dienstag, 6. August 2002 18:48, Martin Oehler wrote:
Am Die, 2002-08-06 um 17.47 schrieb Michael Matz:
On 6 Aug 2002, Ralf Corsepius wrote:
[... wer sowas braucht hat zuwenig Speicher, oder ein falsch designtes Programm ...]
Klar, nur werden derlei Antworten von Leuten mit diesen Fragen ueblicherweise nicht gern gehoert ;-) "Wie kann ich dass mit wenig Aufwand machen?" - "Designe einfach dein Programm komplett um" ;-)
Die Antwort ist brutal, aber vielleicht nicht verkehrt. Die Größe der Datensätze auf denen die Software arbeitet, ist eigentlich für einen PC noch in Ordnung. Doch mit den Verfahren wirds wohl zu viel. Letztenendes wird auf kurz oder lang wohl eine Strategie her müssen, um Daten effizient von der Platte zu laden. Bis dahin wollte ich eine SW-mäßige Begrenzung einbauen.
Wenn Du hauptsächlich Daten effizient lesen mußt:
Versuch's doch mal mit mmap() - dann kannst Du die Vorteile des virtuellen
Speichers gleich mehrfach nutzen: Einfacher Zugriff (einfach wie im
Speicher), trotzdem wird ein File gelesen - und zwar exakt die Teile davon,
die Du auch wirklich brauchst.
CU
--
Stefan Hundhammer
Hi! Am Die, 2002-08-06 um 19.29 schrieb Stefan Hundhammer:
Wenn Du hauptsächlich Daten effizient lesen mußt:
Versuch's doch mal mit mmap() - dann kannst Du die Vorteile des virtuellen Speichers gleich mehrfach nutzen: Einfacher Zugriff (einfach wie im Speicher), trotzdem wird ein File gelesen - und zwar exakt die Teile davon, die Du auch wirklich brauchst.
Das kannte ich auch noch nicht, thanks. Für Verfahren mit Lokalität kann man da denke ich eine Menge herausholen (gleich mal ausprobieren). CU Martin
Hi! Am Die, 2002-08-06 um 17.04 schrieb Ralf Corsepius:
Am Die, 2002-08-06 um 16.44 schrieb Michael Matz: So banal es klingen mal, wenn Dein Progi regelmässig derart viel Speicher wirklich benötigt (d.h. dauerhaft im Zugriff haben muss) und Du mit Swapping nicht leben kannst, ist dein Specher unterdimensioniert. Wenn der Speicher allerdings nicht wirklich dauerhaft im Zugriff steht, sollest Du mal über das interne Design deines Programmes nachdenken (Wo kann Speicher gespart werden, muss wirklich immer alles im Speicher hängen, wo/wie kann ich Daten auslagern usw. usf).
Ja, das ist mir klar. Doch alles was ich, wie effizient auch immer, von der Platte laden muß, bremst mich. Ich muß nunmal einen Mindest- satz an Daten im Speicher halten (das ist meine Mindestanforderung), und je nach dem wie gut ich diese organisieren kann, desto schneller läuft mein Programm, desto mehr Speicher brauche ich allerdings auch. Da die Software nicht immer auf RAM-mäßig gleich ausgestatteten Rechnern läuft, dachte ich, würde ich das am besten vom Speicher anhängig machen.
Ich wuerde sagen (MemFree + Buffers + Cached) * 0.9 oder 0.8 ist ein recht guter Wert fuer freien Speicher, und laesst noch etwas ueber fuer Puffer und andere Prozesse. Nur ist das für Apps praktisch ohne Belang: Zwischen phys. und virt. Memory bzw. Addressbereich funken noch ulimits u.Co. hinein (man getrlimits, man ulimit)
Hmmm. man ulimit habe ich gelesen, man getrlimits habe ich irgendwie nicht gefunden, da fehlt wohl was auf meinem Rechner. CU Martin
Am Die, 2002-08-06 um 18.26 schrieb Martin Oehler:
Hi!
Am Die, 2002-08-06 um 17.04 schrieb Ralf Corsepius:
Am Die, 2002-08-06 um 16.44 schrieb Michael Matz: So banal es klingen mal, wenn Dein Progi regelmässig derart viel Speicher wirklich benötigt (d.h. dauerhaft im Zugriff haben muss) und Du mit Swapping nicht leben kannst, ist dein Specher unterdimensioniert. Wenn der Speicher allerdings nicht wirklich dauerhaft im Zugriff steht, sollest Du mal über das interne Design deines Programmes nachdenken (Wo kann Speicher gespart werden, muss wirklich immer alles im Speicher hängen, wo/wie kann ich Daten auslagern usw. usf).
Ja, das ist mir klar. Doch alles was ich, wie effizient auch immer, von der Platte laden muß, bremst mich. Ich muß nunmal einen Mindest- satz an Daten im Speicher halten (das ist meine Mindestanforderung), und je nach dem wie gut ich diese organisieren kann, desto schneller läuft mein Programm, desto mehr Speicher brauche ich allerdings auch.
Auch das ist klar, nur sind es oft schon einfache Dinge, mit denen sich Speicher sparen lässt, z.B. * GUIs dynamisch statt statisch erzeugen, + Bei grossen Datenmengen mit Originaldaten arbeiten, statt temporäre Kopien verwenden. * Statische Arrays/Arrays konstanter Grösse (In C++: Vorsicht bei vector<t>) vermeiden. * float statt double verwenden (braucht man wirklich double Genauigkeit?) * Schlecht durchdachte Datenstrukturen, die sich in Folge von "Alignmentproblemen" mit "Pad-Bytes" aufblähen. (struct my { char a; int b; }; struct my c[100000];); ..
Da die Software nicht immer auf RAM-mäßig gleich ausgestatteten Rechnern läuft, dachte ich, würde ich das am besten vom Speicher anhängig machen. Keine gute Idee, IHMO. Unix/Linux-Systeme sind Multiusersysteme, der freie Speicher liegt nicht in deinem Einflussbereich.
Wenn überhaupt, dann würde ich eine Command-Line Option verwenden (myprogi --mem=512MB), nur .. wie schon angedeutet, mehr als einen recht zweifelhaften Hinweis an dein Programm kann das auch nicht liefern. [Nichts hindert einen anderen User im Hintergrund speicherintensive Programme zu starten.]
Ich wuerde sagen (MemFree + Buffers + Cached) * 0.9 oder 0.8 ist ein recht guter Wert fuer freien Speicher, und laesst noch etwas ueber fuer Puffer und andere Prozesse. Nur ist das für Apps praktisch ohne Belang: Zwischen phys. und virt. Memory bzw. Addressbereich funken noch ulimits u.Co. hinein (man getrlimits, man ulimit)
Hmmm. man ulimit habe ich gelesen, man getrlimits habe ich irgendwie nicht gefunden, da fehlt wohl was auf meinem Rechner. Typo meinerseits: man getrlimit (ohne s).
Ralf
Hi! Am Mit, 2002-08-07 um 07.33 schrieb Ralf Corsepius:
Auch das ist klar, nur sind es oft schon einfache Dinge, mit denen sich Speicher sparen lässt, z.B. * GUIs dynamisch statt statisch erzeugen,
Ist qt und erledigt sich wohl damit.
+ Bei grossen Datenmengen mit Originaldaten arbeiten, statt temporäre Kopien verwenden. * Statische Arrays/Arrays konstanter Grösse (In C++: Vorsicht bei vector<t>) vermeiden. * float statt double verwenden (braucht man wirklich double Genauigkeit?)
Ja.
* Schlecht durchdachte Datenstrukturen, die sich in Folge von "Alignmentproblemen" mit "Pad-Bytes" aufblähen. (struct my { char a; int b; }; struct my c[100000];);
Alles Schlamperei, ist zwar gut das in so einem Thread zu erwähnen, hilft mir aber konkret wenig (okok, keine SW ist perfekt und sauber programmiert schon gar nicht und in großen SW-Projekten kriegt man pro Mann eh' nur ein Dutzend Zeilen Code sauber programmiert... jetzt habe ich glaube ich alle Kalauer des modernen SW-Engineering zusammen ;) ), aber an solchen Fehlern hängts inzwischen nicht mehr.
[Nichts hindert einen anderen User im Hintergrund speicherintensive Programme zu starten.]
Hehe, wenn die Software schnell genug reagiert und der Benutzer nicht ein paar Minuten auf seine Ergebnisse warten muß, kommt er auch nicht auf solche Ideen. ;)
Typo meinerseits: man getrlimit (ohne s).
habs :) CU Martin
On Mittwoch, 7. August 2002 08:36, Martin Oehler wrote:
Am Mit, 2002-08-07 um 07.33 schrieb Ralf Corsepius:
Auch das ist klar, nur sind es oft schon einfache Dinge, mit denen sich Speicher sparen lässt, z.B. * GUIs dynamisch statt statisch erzeugen,
Ist qt und erledigt sich wohl damit.
Nein, so etwas geht natürlich auch mit Qt: Anstatt gleich beim Programmstart
alle Dialoge in voller Schönheit zu erzeugen, erzeugt man jeden Dialog erst
dann, wenn er auch aufgehen soll. Wenn man besonders Speicher sparen will /
muß, kann man ihn auch beim Schließen wieder zerstören (obwohl das in der
Praxis wohl kaum jemand wirklich tut).
CU
--
Stefan Hundhammer
Am Mit, 2002-08-07 um 11.18 schrieb Stefan Hundhammer:
On Mittwoch, 7. August 2002 08:36, Martin Oehler wrote:
Am Mit, 2002-08-07 um 07.33 schrieb Ralf Corsepius:
Auch das ist klar, nur sind es oft schon einfache Dinge, mit denen sich Speicher sparen lässt, z.B. * GUIs dynamisch statt statisch erzeugen,
Ist qt und erledigt sich wohl damit.
Nein, so etwas geht natürlich auch mit Qt: Anstatt gleich beim Programmstart alle Dialoge in voller Schönheit zu erzeugen, erzeugt man jeden Dialog erst dann, wenn er auch aufgehen soll. Wenn man besonders Speicher sparen will / muß, kann man ihn auch beim Schließen wieder zerstören (obwohl das in der Praxis wohl kaum jemand wirklich tut).
Ich meinte mit erledigt, dass das so gemacht wird. Ist unter Leuten, die viel mit qt arbeiten, AFAIK Standard. Ich muß aber gestehen, dass weder die GUI noch die graphic engine zu meinen Aufgaben gehören. CU Martin
Am Mit, 2002-08-07 um 11.18 schrieb Stefan Hundhammer:
On Mittwoch, 7. August 2002 08:36, Martin Oehler wrote:
Am Mit, 2002-08-07 um 07.33 schrieb Ralf Corsepius:
Auch das ist klar, nur sind es oft schon einfache Dinge, mit denen sich Speicher sparen lässt, z.B. * GUIs dynamisch statt statisch erzeugen,
Ist qt und erledigt sich wohl damit.
Nein, so etwas geht natürlich auch mit Qt: Anstatt gleich beim Programmstart alle Dialoge in voller Schönheit zu erzeugen, erzeugt man jeden Dialog erst dann, wenn er auch aufgehen soll. Wenn man besonders Speicher sparen will / muß, kann man ihn auch beim Schließen wieder zerstören (obwohl das in der Praxis wohl kaum jemand wirklich tut).
Nun, es kommt darauf an, wie speicherintensiv "Dialoge"/"Windows" sind. Bei "einfachen Dialogen" (Konfigurationsdialoge, Fileselectoren u.ä.) wäre der Gewinn nicht übermässig, bei Widgets die komplexe Dinge/Daten visualisieren (Insb. Grapheneditoren, Browser, 3D-Views u.ä.) oder auch prall gefüllte "Notebook" Widgets können schnell eine nicht mehr zu vernachlässigende Grösse erreichen ... ... da kommen schnell mal mehrere hundert Widgets/Gadgets (Je nach GUI) innerhalb eines anderen Widgets zusammen. Diese dann nicht dynamisch zu erzeugen und sie statisch, quasi auf Vorrat, im Hintergrund zu halten, sollte sich eigentlich verbieten. Ralf
Am Dienstag, 6. August 2002 11:06 schrieb Martin Oehler:
Gibt es in C/C++ eine Möglichkeit, den noch verfügbaren RAM-Speicher abzufragen (es soll nicht geswapt werden)?
Mal abgesehen von allen Philosophischen und Praktischen Diskussionen die hier zu dem Thema schon laufen, würd ich mir einfach mal den Sourcecode von 'free' anschaun, ger gibt doch alle die hübschen daten aus, muss sie also auch ermittelt haben.
Ich würde damit gerne den Speicher begrenzen, den ich dynamisch durech mein Programm anfordere. Rein rechnerisch könnte ich das zwar einschränken, in dem ich z.B. nur 256 MB Speicher anfordere (also quasi eine Art Mindestanforderung).
Jetzt muß ich doch noch eine Bemerkung loslassen: Die Vorgehensweise scheint mir auf einem Multitasking + Multiuser-Betriebssystem nur bedingt sinnvoll. So das wars aber auch schon. -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ Manfred | http://www.knightsoft-net.de
participants (5)
-
Manfred Tremmel -
Martin Oehler -
Michael Matz -
Ralf Corsepius -
Stefan Hundhammer