RAM für einen Prozess begrenzen
Florian Lohoff
flo at rfc822.org
Sat Aug 20 00:24:29 CEST 2005
On Fri, Aug 19, 2005 at 09:26:44AM +0200, Mirko Werneke wrote:
> Kann ich aber auch nicht laufen lassen. Ist nämlich eigentlich nicht
> meine Baustelle. Aber wozu auch? Man würde halt sehen, daß ein SMB
> Prozess sich in kurzer Zeit immer mehr Speicher genehmigt (so wurde es
> mir gesagt) bis die faktisch Kiste steht.
Das ist nicht normal - Es scheint also immer ein und die selbe datei bzw
der selbe user sein. Es waere interessant also ein abbild des samba
prozesses zu haben bzw zu wissen was der macht. lsof wenn der sich den
speicher geschnappt hat.
> Da wie gesagt die Kiste nicht geupdatet werden kann/darf soll das
> Speicherlimit im wesentlichen sicherstellen, daß die Kiste im Falle des
> Falles noch benutzbar bleibt. Samba kann man dann zur Not neu starten.
Wenn du nichts updaten kanns/darfst fang gar nicht erst an sondern lehne
die verantwortung ab. So kann man doch keinen serverbetrieb machen.
Zum Problem: Was du willst ist die prozessgroesse begrenzen so das der
prozess dann auf eine "brk" also malloc einen fehler bekommt.
Was du willst ist "ulimit -v 500000" - ulimit ist ein bash internal
also "man bash"
flo at audiobooks:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
flo at audiobooks:~$ ulimit -v 30
flo at audiobooks:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) 30
flo at audiobooks:~$ vi
Killed
Ich halte deinen weg aber fuer grundfalsch. Du kurierst an symptomen und
nicht an dem problem. Und damit wird nur irgendein Nutzer dann schreiben
das sein share immer wegfliegt. Und mit dem wegfliegenden share gehen
die offenen dateien kaputt was dann wieder hoffentlich aus einer
funktionierenden datensicherung wiedergeholt werden muss.
Flo
--
Florian Lohoff flo at rfc822.org +49-171-2280134
Heisenberg may have been here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20050820/a95ef2a9/attachment.sig>
More information about the Linux
mailing list