Linux – How to Limit Memory Usage for a Single Process

Yes, VSZ is virtual memory. As to RLIMIT_AS, where did you find the paragraph quoted above? Since setrlimit(2) is a Linux system call, I do not see how it could possibly monitor malloc(3), a library function. Instead, it can only work with brk(2), sbrk(2), and mmap(2) -- this is also what its manpage (checked of Scientific Linux) suggests. However, the total amount of memory requested via these functions is virtual memory, so RLIMIT_AS indeed limits virtual memory. (This is, again, in accordance with the setrlimit(2) manpage.)

Unfortunately, you cannot limit RSS under Linux (this would be ulimit -m). You can try ulimit -d (RLIMIT_DATA), but this will include mmap(2) only since Linux 4.7, typically used for large allocations. Another possibility would be to limit virtual memory, but with such a large difference between RSS and VSZ, this might be difficult.

The short answer is:

ulimit -m 1000000
ulimit -v 1000000

which will limit each process to 1 GB RAM.

Limiting the memory the "right" way is in practice extremely complicated: Let us say you have 1 GB RAM. You start a process every 10 seconds and each process uses 1 MB more every second. So after 140 seconds you will have something like this:

10██▎                                                          
20██████▍                                                      
30██████████▌                                                  
40██████████████▋                                              
50██████████████████▊                                          
60██████████████████████▉                                      
70███████████████████████████                                  
80███████████████████████████████▏                             
90███████████████████████████████████▎                         
100██████████████████████████████████████▍                     
110██████████████████████████████████████████▌                 
120██████████████████████████████████████████████▋             
130██████████████████████████████████████████████████▊         
140██████████████████████████████████████████████████████▉     

This sums up to 1050 MB RAM, so now you need kill something. What is the right job to kill? Is it 140 (assuming it ran amok)? Is it 10 (because it has run the least amount of time)?

In my experience jobs where memory is an issue are typically very predicable (e.g. transforming a bitmap) or very little predictable. For the very predictable ones you can do the computation beforehand and see how many jobs can be run.

For the unpredictable you ideally want the system to start few jobs that take up a lot of memory, and when they are done, you want the system to start more jobs that take up less memory. But you do not know beforehand which jobs will take a lot, which will take a little, and which ones run amok. Some jobs normal life cycle is to run with little memory for a long time and then balloon to a much bigger size later on. It is very hard to tell the difference between those jobs and jobs that run amok.

When someone points me to a well thought out way to do this in a way that will make sense for many applications, then GNU Parallel will probably be extended with that.