Speicherverbrauch von Prozessen (l*n*x)

wie begrenze ich den Verbrauch an virtuellem Speicher von Prozessen unter l*n*x?

ulimit -Sv kenne ich, aber bei mir laufen einige Jobs seit mehreren Tagen - die krallen sich bis zu 10 GByte swap und machen das System zähflüssig. Geht die Limitierung auch für laufende Jobs?

und wozu nimmt sich ein Job (eine langwierige Berechnung mit dc in diesem Fall) überhaupt 12 GByte swap, wenn während der Rechnung kaum mehr als 256 Register und ein Stack benötigt werden, was sich bei Zahlenlängen <= 20000 auf < ~10 MByte belaufen dürfte ?

Was stört dich virtueller Speicher? Das ist ein Trick um auf reallocs verzichten zu können, was das Programm etwas schneller macht.

ScottZhang

Wohlmöglich sind das Speicherlecks.

so schlau bin ich auch.

Was ist das für eine Frage, ob mich virtueller Speicher stört? natürlich nicht, aber wenn der Rechenjob nach ein paar -zig Stunden die kompletten 25 GB swap und > 80% vom RAM in Anspruch nimmt, wird mein System unakzeptabel zäh und ruckelig, obwohl es ein 4-Kerner mit 4 GB RAM ist.

hab das Rechenprogramm jetzt nach C++ mit mplib portiert, damit dauert dere job statt vorher > 20 h nur noch 10 Min und belegt < 16 MB Speicher.

SeppJ

großbuchstaben schrieb:

Was ist das für eine Frage, ob mich virtueller Speicher stört? natürlich nicht, aber wenn der Rechenjob nach ein paar -zig Stunden die kompletten 25 GB swap und > 80% vom RAM in Anspruch nimmt, wird mein System unakzeptabel zäh und ruckelig, obwohl es ein 4-Kerner mit 4 GB RAM ist.

Wenn der Speicher in solchen Fällen nicht vom OS zurück geholt wird oder gar geswapped wird, dann ist der Speicher wohl tatsächlich belegt und nicht nur virtuell. Also vermutlich Speicherleck im Programm oder tatsächlicher Bedarf. In beiden Fällen wird dir nichts nützen, am OS herum zu spielen, die Ursache liegt bei der Anwendung.

Schreib nen Bugreport und verwende das nächste mal besser bc, der ist ausgereifter.

nö. Ich brauche das Tempo von dc. oder genauer gesagt: brauchte. In C++ mit GMP laufen die jobs jetzt um Faktoren 10-100 schneller, Problem gelöst.

oops: also zumindest Faktoren bis 10 - wir wollen nicht übertreiben