[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Limiting the amount of memory an application can allocate
- From: Rigoberto Corujo <rcorujo yahoo com>
- To: "Red Hat Enterprise Linux 4 \(Nahant\) Discussion List" <nahant-list redhat com>
- Subject: Re: Limiting the amount of memory an application can allocate
- Date: Tue, 18 Sep 2007 04:57:06 -0700 (PDT)
Thank you for the clarification.
> I was going to test this, but at least on F7 x86_64,
ulimit -m doesn't actually have any effect.
This is an interesting comment. I was getting hung up
on trying to figure out why "ulimit -m" didn't seem to
do anything, but I think you've just confirmed that it
doesn't do anything. Seems like "ulimit -v" is what I
should be focusing on.
Thanks to everyone who responded.
Rigoberto Corujo
--- John Haxby <jch scalix com> wrote:
> Rigoberto Corujo wrote:
> >
> >> The resident set size, rss, is the maximum amount
> of
> >> virtual memory resident in real memory.
> >>
> >
> > Would you be able to explain what "maximum amount
> of
> > virtual memory resident in real memory" means?
> >
> >
> Hmm. Not had to explain this one for a while ...
>
> You know what virtual memory is, right? Each
> process on the system
> believes that is has all the memory allocated to it
> that it's asked
> for. If you do "malloc(1024*1024*1024)" then as
> far as the process is
> concerned it has 1GB memory allocated to it.
> However, unless you start
> trying to use that allocated memory, the kernel
> doesn't actually map its
> pages to real memory.
>
> The number of pages currently mapped to real memory
> is called the
> resident set size, rss. The resident set size
> depends on several
> things: the virtual size of the process (duh), the
> working set size of
> the process, the amount of memory in the machine and
> how much other
> processes want to use that memory.
>
> If you artificially limit the resident set size to
> something less than
> the working set size of the process then you'll just
> cause lots of
> paging and the process will run very very slowly.
> In fact the whole
> system will tend to run slowly because the disk will
> be thrashing its
> silly self to death.
>
> I was going to test this, but at least on F7 x86_64,
> ulimit -m doesn't
> actually have any effect. That's probably a good
> thing. I do use
> ulimit -v though -- I use xlhtml to convert excel
> spreadsheets to ascii,
> but occasionally it trips over a bad spreadsheet and
> goes mad allocating
> memory so it's limited to 100Mb to stop it grabbing
> all the allocatable
> memory and forcing the oomkiller to step in.
>
> jch
>
> jch
>
> --
> nahant-list mailing list
> nahant-list redhat com
> https://www.redhat.com/mailman/listinfo/nahant-list
>
____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]