Riley Williams wrote:
>
> Hi Brian.
>
> Alan: Can you comment on this please?
:o)
>
> >>>>> Oh! The cobol-applications are usually run during night when
> >>>>> nobody uses the servers - so no 'bash', 'ps' or the like are in
> >>>>> the cache. The next morning when somebody tries to login (s)he
> >>>>> will be denied access ....
>
> >>>> What about limiting memory using ulimit()?
>
> >>> With clever usage it could be used - but I am not sure how ;o)
>
> >> The obvious fix here, assuming the current program is called PROG
> >> and is in the current directory, would be something along the
> >> lines of:
>
> >> Q> mv PROG PROG.1
> >> Q> cat > PROG <<.EOF
> >> Q> #!/bin/bash
> >> Q> FM="\`free | grep '^[MS]' | tr -s ' ' | cut -d ' ' -f 4\`"
> >> Q> FM=\$[\`echo -n \$FM | tr ' ' '+'\`]
> >> Q> ulimit -l \`echo \$FM '3*4096/p' | dc\`
> >> Q> PROG.1 \$\*
> >> Q> .EOF
> >> Q> chmod 700 PROG
>
> >> Of course, change the mode in the last line to suit...the above
> >> should limit that process to 75% of the [combined real and swap]
> >> memory free when the program was first run...
>
> > I don't think that's the way to do it - it would mean that one
> > would have to write a wrapper for each program one suspect of being
> > able to eat all memory.
>
> A simple variant thereof would make it work similar to the 'time'
> command, in that it takes the command to run as parameters...
Correct - but it doesn't "feel" right ... ;o) (A simple matter of
taste ...)
>
> > NEWSFLASH! I just tried your script - I had to modify it a bit
> > (hopefully I didn't break anything ...):
>
> 8-) You obviously didn't realise that if you typed each line as
> listed at the bash prompt, you'd get the intended script - certain
> characters had to be escaped that way to get the correct characters in
> the target script...
No, I didn't realise that. Now I've got something else to play with -
scriptediting using 'cat' ;o)
>
> > #!/bin/bash
> > FM="$(free | grep '^[MS]' | tr -s ' ' | cut -d ' ' -f 4)"
> > FM=$[$(echo $FM | tr ' ' '+')]
> > ulimit -l $(echo $FM '3*4096/p' | dc)
> > ulimit -l
> > read an
> > eat
>
> Take the second 'ulimit' line out - it reverses the effect of the
> first line...
Nope. I just prints the current setting for that flag:
bsc@cryo:/home/bsc > ulimit -l 2048
bsc@cryo:/home/bsc > ulimit -l
2048
bsc@cryo:/home/bsc > ulimit -l
2048
bsc@cryo:/home/bsc > ulimit -l
2048
bsc@cryo:/home/bsc > ulimit -l
2048
bsc@cryo:/home/bsc > ulimit -l
2048
>
> Also, try the following variant thereof...
>
> Q> #!/bin/bash
> Q> FM="`free | grep '^[MS]' | tr -s ' ' | cut -d ' ' -f 4`"
> Q> FM=$[`echo $FM | tr ' ' '+'`]
> Q> ulimit -l `echo $FM '3*4096/p' | dc`
> Q> exec $*
>
> Then feed that the relevant command as a parameter and advise re the
> result...
Ok. Here's what I did:
1) Saved this mail (as 'script').
2) Cut lines before and after the inlined script
3) Removed the Q> prefix from all lines
4) chmod 755 script
5) On tty2 I executed:
free -mtos 1 | tee free.log
6) On tty3 I executed:
./script ./eat
This is the last couple of lines from 'free.log' (the last 3 seconds
...):
total used free shared buffers
cached
Mem: 38 37 0 0 1
0
Swap: 64 64 0
Total: 103 102 0
total used free shared buffers
cached
Mem: 38 37 0 0 1
0
Swap: 64 64 0
Total: 103 102 0
total used free shared buffers
cached
Mem: 38 37
(I've attached the complete 'free.log' - gzipped)
As you can see, I run out of memory. Afterwards I can't login (INIT:
respawning too fast, disabling .....) ... So that's what spawned the
'rootpages' idea.
Furthermore, even though I stopped the memory-eating process my system
became very slow - windows in X opens very slowly and so on. While
typing this mail everything slowly reverted back to normal. Isn't
there a way to speed up the process which merges the elements of the
free-pages list (or whatever technique is used) even tough it means that
it means an rise in loadavg?
Anyone?
>
> > 'eat' is the program I supplied in my initial mail .... And it does
> > what it is asked to do: eat all available memory (ulimit -l
> > couldn't stop it ....)
>
> > I've even tried to play around with ulimit:
>
> > bsc@cryo:/home/bsc > ulimit -l 2048 # max size any prog can get in this
> > shell
> > # is 2Mb (hopefully)
> > bsc@cryo:/home/bsc > ./eat # goodbye available memory
>
> > ... it might be I who uses the ulimit command wrongly ...
>
> I don't think so - if that is indeed true, there would appear to be a
> kernel bug in the MM subsystem...
I hope not!
>
> Best wishes from Riley.
BTW: I use 2.1.127 kernel without any patches (except my own ;o)
--------------823AEAA41D8D3BAD2507B61E
Content-Type: application/x-gzip; name="free.log.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="free.log.gz"
H4sICP31RTYAA2ZyZWUubG9nAO2YTW7CMBCF9zlFjhDbYxP3Dl21F0ghiEWrVvyI67eliHlI
4VEksENrVk/WYPvzxPMmqWv4rd/X3eteb1b9bC/ny77fidWiW/6Mvmzm83652o1Ou+min1WP
/dsDTuZa1Spdo6N2UJrqadt94FRBVMeD8lI9f+9XI03jVOuSrVQVbqxgFsyCWTALZsEcN6ZR
ChvOYdqrYFqdsTWJMJ0uX8OWb4kpKn1MhTnRYTPIBqOOYcJz4S3FhPNwGTCH7+avMVX6hmF6
i4EjxPQU0x+kRIqJic2LCTcWMAPF1JlkQjE9Bo4wmy3F1CsnnmJqRZcwRszIMK0GiqOYurqk
8s1LMA1tD8AOhVZaD2nPUWnNGWmob1qoLIZhBj3Or/NIhAmtz1/G/CfZvKQEcUz1CUd9M8Al
ztweDPumUEx9/F1LMQUD09/NE29f8D+KqQXUUd8MkPZRtgcU02mgo74Z4DyS+eZwNk9UI4pp
QVJMWD1zezCMybMJkr6hTCwGZvXNQWJuKB7aW4oZj/qqe6u00MPVtARFONlkrfsFXRD3TXD9
mn4kiXCyfoQPbd1QTMHA05imOSpqWZu9m2IefRLNejcL5lUxM/e0BfOOMT8BzbgURgAgAAA=
--------------823AEAA41D8D3BAD2507B61E--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/