[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Limiting the amount of memory an application can allocate

Rigoberto Corujo wrote:
If my crude method for estimating the physical memory
used is reasonably correct, you can see that 1 Gig of
memory was allocated even though I had set "rss" in
"limits.conf" to 10 Meg.

The resident set size, rss, is the maximum amount of virtual memory resident in real memory. If you started writing to that 1G buffer (eg with memset()) you'd notice a few things: it runs very, very slowly; "top" will report an RSS of 10M; the system will be running at 100% iowait and it will mostly likely be very unresponsive.

VMS used to (and maybe still does) play silly buggers with allocating only a small amount of physical memory for process's working set size -- which should immediately tell you where they went wrong :-) I used to get much better overall system performance by bumping up the maximum working set size and leaving the quota quite low. Ahhh ... takes me back ... The upshot is that if you limit the rss of a user's processes then you may well wind up making the system performance much worse.

One thing I can't figure out is why the call to
getrlimit is saying that RLIMIT_DATA is unlimited when
"ulimit -m" is telling me that it is set to 10 Meg.
RLIMIT_DATA corresponds to ulimit -v, I believe. But note that this is a per-process setting. If you're trying to stop some user eating all the physical memory in some huge emacs process, for example, he (or she) can still eat all the physical memory by running lots of not-quite-so-huge emacs processes. You're probably better off going round with a Big Stick and "persuading" him (or her) to behave.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]