We have a process that in recent weeks had a once-off memory leak that resulted in it consuming all memory on our RHEL 7 box
We now wish to set limits around this such that it will never take any more than a certain amount
We are using the ulimit -v setting to set this amount (as the -m setting does not work)
Therefore, I'm wondering if this is sufficient or do we also need a way to limit physical memory as well? IF so, what is the best way to go about this?
If virtual memory always grows with phyiscal memory then perhaps -v by itself is sufficient
Some description about how ulimit
works:
ulimit
has deal with setrlimit
and getrlimit
system calls. It's easy to ensure by strace
-ing of bash process (ulimit
is component of the bash
). I set 1024kb of max memory size
:
$ ulimit -m 1024
In another console:
$ strace -p <my_bash_pid>
. . .
getrlimit(RLIMIT_RSS, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
setrlimit(RLIMIT_RSS, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
. . .
setrlimit
man page write next about RLIMIT_RSS
:
RLIMIT_RSS Specifies the limit (in pages) of the process's resident set (the number of virtual pages resident in RAM). This limit only has effect in Linux 2.4.x, x < 30, and there only affects calls to madvise(2) specifying MADV_WILLNEED.
madvice
syscall is just advice to kernel and kernel may ignore this advice. Even bash
man page about ulimit
write following:
-m The maximum resident set size (many systems do not honor this limit)
That is the reason why -m
doesn't work.
About -v
option:
I set 1024 kb of virtual memory:
$ ulimit -v 1024
In another console:
$ strace -p <my_bash_pid>
. . .
getrlimit(RLIMIT_AS, {rlim_cur=RLIM64_INFINITY, rlim_max=RLIM64_INFINITY}) = 0
setrlimit(RLIMIT_AS, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
. . .
setrlimit
man page write next about RLIMIT_AS
:
RLIMIT_AS The maximum size of the process's virtual memory (address space) in bytes. This limit affects calls to brk(2), mmap(2) and mremap(2), which fail with the error ENOMEM upon exceeding this limit. Also automatic stack expansion will fail (and generate a SIGSEGV that kills the process if no alternate stack has been made available via sigaltstack(2)). Since the value is a long, on machines with a 32-bit long either this limit is at most 2 GiB, or this resource is unlimited.
Program consist of 3 segments (data, code, stack) compose virtual program memory space.
Code segment is const and contain program instructions.
Data segment is controlled by following:
brk
syscall adjusts size of data segment (part of virtual memory) of the program.
mmap
syscall maps file or device to virtual memory of process.
Many programs allocates memory (direct or indirect) by calling standard function from C Library (malloc
) which allocates memory from heap (part of data segment). malloc
adjust size of data segment by calling brk
syscall.
Stack stores functions variables (variable takes memory during allocation from stack).
So, that's why the -v
option is works for you.
If -v
is sufficient for your task, then there is no reasons to do something else and it's sufficient.
If you want to take control about huge count of specific memory features for process (memory pressure, swap usage, RSS limit, OOM and so on) I suggest to you to use cgroups memory capabilities.
If your application is a service I suggest to you to use systemd slice features, as the most convenient for controlling and limiting resources of service or group of services (also it easy to configure instead of configuring cgroups
directly) which is managed by systemd
.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments