I had a conversation with @ChrisNZ a while back where we discussed MEMSIZE and related tunables at length. Here is a snippet of that conversation where I shared some of my thoughts on the topic at hand.
With modern machines I'd say this (memory allocator limits and related tunables) is mattering less and less. When your computer had 32Kb of memory you'd invest in the software to make smart decisions with memory to get your problem solved. With so little memory in the machines of the time it was easy to have your working set of data be orders of magnitude larger than the available memory you could physically fit in a machine. On top of this the ISA for most CPUs only supported addressing up to a maximum of 4GB of virtual memory. When this options was added into SAS I'm sure they didn't even consider that one day we'd need to have a new set of instructions for CPUs and entirely new CPUs to address more than 4GB of memory. For a lot of computing problems now if you don't have enough memory you just buy more (or cluster machines i.e. the SAS LASR Analytics Server). This is also likely reflected in the SAS procedures too. I'm sure its only the older procedures that have the smarts to dynamically pick algorithms based on the actual amount of memory in the system.
With the Linux kernels control groups feature getting quite mature now this is the route I'd likely take to solve the issue of users taking all the memory on a box if the issue arose. The MEMSIZE tunable inside SAS is great but it has got some obvious short comings. It only track memory allocated by the SAS session's memory management subsystem. Memory allocated by third party software (like database client drivers) isn't accounted for. Another problem is that a user can simple spawn multiple processes and easily consume more memory than you expected them to take. With control groups you can set resource limits on all of the users processes as a whole. This includes memory allocated by their SAS processes, loaded third party libraries (e.g. database client libraries), even processes spawned by their SAS session which would get a whole new address space (eg. bulkloaders, X statements, etc).
For @gothaggis the simplest answer I'd give you is to set it high enough that users don't complain, re-evaluate the situation if you see the oom-killer invoked and the box is running out of memory.
... View more
