Overriding Passed Options

[pflickner]

Hi.  We have moved to a new Linux box with serious hardware to support SAS and other process-intensive software. We have a situation where some users passed a very large memsize (-memsize 30G) due to old hardware/os constraints just so they could run their jobs; however, those are not necessary with the new hardware and is actually impacting both the jobs they submit (processing is not faster for these jobs while it is for all other SAS jobs) and it is also impacting other processes and SAS jobs.  We understand that there is a danger in adding memsize to the restricted options, so we'd rather just override it with our own.

Is there a way to reset or override memsize to our current setting regardless of what the user sets?  This may alleviate a couple of our current headaches right now.  Thanks very much.

[ballardw]

There are two procedures that may help: OPTSAVE and OPTLOAD.

OPTSAVE will save options to a data set and OPTLOAD will load saved options. General usage is to OPTSAVE the standard options before running a process that needs modified options and then use OPTLOAD at the end to restore them.

If you have a standard default set you could save it to a permanent data set and then have that available for running with OPTLOAD anytime.

[pflickner]

I know about these options, but they will not work as memsize is a system option executed at startup.

[jag_SAS]

Hi there. You want to set "Restricted Options" either by group or user as described in Chapter 2 of this doc here, http://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/66380/PDF/default/config.pdf. More details on how you or a user can check what options are set in their environment is covered here, SAS(R) 9.4 System Options: Reference, Third Edition

And if you have a Metadata Server you might want to be aware of this note,

43280 - Setting MEMSIZE as a restricted option overrides the MEMSIZE setting used by the Metadata se...

Cheers!

[pflickner]

Again, as I stated, I do NOT want to set it as a restricted option for the very reason stated in 43280.  I've already read this information.  I'm looking for a way to override what a user passes so that regardless of what they pass, it is ignored.

[SASKiwi]

How are your users applying the MEMSIZE override? Through a Unix script, command line or both. Do they apply it to batch jobs, interactive sessions or in other ways?

The only way I can think of doing what you want is to restrict the invocation of SAS to using a custom script which strips out any MEMSIZE options above a permitted limit. Maybe the cure is worse than the disease?   

[jakarman · Accepted solution]

You are overcomplicating things. Setting the me size will not harm things as the code needed to run Neede this as an upper limit. When the code changes removing that requirement you can remove that setting with the script that called that code.

The memsize setting is only a constraint that is checked by SAS internally. As long it is not reached nothing will happen. A process that is using very little memory just does that.

Serious Linux implementation that is about being in control with ulimits and Cgroups where you control those resources. Sas session internal settings are not valid with those.

[pflickner]

Thanks, Jaap.  The documentation suggested that it could be responsible for the problems we're experiencing, and it is just as possible that many of these jobs are actually taking and using those huge chunks of memory.  I will pass on this information.  Thanks very much.

[jakarman]

Ok you have seen a memory usage problem (paging swapping memory manager)  as of your last post.
As none of the Linux processes get the umlimits set, the process running seen at the OS level can use far too much. The internal sas memsize is the internal sas usage not all or the os process. You could have a problem as of this difference. Having big datasets to IO is buffered/cached. It must use memory at the os level for that. When that is used in the useradress space you could have your root-case. In this case the problem is going along with the sizing of the data. The sizing of the data can be checked.

You could set the umlit by running the spawners by a dedicate key (not the generic shared sassrv) as the user processed inherit those settings and not the user-account registered one.