SAS 9.4 Middle Tier UNIX ulimit settings

Reply
Occasional Contributor
Posts: 5

SAS 9.4 Middle Tier UNIX ulimit settings

Based on the SAS support web site, installations of the SAS 9.4 Middle Tier on a UNIX server require that "the soft limit on number of open file descriptors be at least 20480..." (see Pre-Installation Steps for SAS 9.4 Middle Tier)

We use a Solaris UNIX server, and the UNIX administrators are perplexed by this request... not how to do it, but why it is recommended.

Is there a reason it is so high?

Is there any significance to the number "20480" in this case?

Can this be solved permanently with a .profile change for the user "sas" or does each individual profile that connects to SAS need this change?

Alternatively, can this be a command in the SAS component startup scripts or configuration files?

We manage SAS services using VCS, so the sas.servers script is not an option.  If we put this setting in a script, what individual startup scripts require this ulimit setting?

Any information on this topic would be helpful to our understanding of the SAS 9.4 Middle Tier and hopefully help resolve the concerns of our UNIX system administrators.

Thank you for your input.

Shaun

Valued Guide
Posts: 3,208

Re: SAS 9.4 Middle Tier UNIX ulimit settings

Shaun I am worried on the reaction of your Unix sys-admins as they should be worried on this SAS recommendations.

These kind of settings/adjustments  are very common to middleware that is some more advanced as a notepad executable.

Let us take some rather simple middleware application as Oracle. 11.2. Limiting Maximum Number of Processes Available for the Oracle User and Chapter 11. Setting Shell Limits for the Oracle User there you have you file and process limits.

there is system max Chapter 9. Setting File Handles and a user max. The system should at least being capable to support it all.

As a relative simple tool like Oracle is having that kind of setting than you should get expect and accepted a SAS environment is asking for more of that. SAS should be capable to do far more than Oracle.

The midtier is build with a java-container and many many java applications.

There you another issue SAS and Oracle are middleware applications call them tools or whatever, they are not business applications. If they are understood in the wrong context  like: "sas is a business application" you have a failure on your project to be expected as highly confident prediction. I could wish SAS-institute would promote that in the same way as positioned "middleware".

The system wide limits cannot be set on a per user approach. After that you have your hard-limit only able to decrease not increase.

Home - VCS Software is for scheduling used with an in house department as operations. The goal for the sas.servers is easy manual operation not automated. In fact you have a quite different question to be asked.

What will your operational support and monitoring by your in house department. As a pitty the standard SAS approach is ignoring these common in-house requirements. However, you can adjust a lot to get that aligned.       

---->-- ja karman --<-----
Occasional Contributor
Posts: 5

Re: SAS 9.4 Middle Tier UNIX ulimit settings

Hi Jaap,

Thank you for your comments as always.

My question did fail to address the difference between hard/system limits and soft/user-process limits.  Our environment has a hard/system limit that is high enough to handle this, but the default soft limits are 256... well below the SAS recommendation.  So my questions are specific to the soft limits that are required by the middleware of SAS.

(As a side note, we also have an Oracle database that is being managed on a similar UNIX server, but I have been told that the soft limits required for that are much lower.)

The links that you sent only refer to changing the soft limits for a specific user (in this case "oracle").  This brings me back to one of my questions "Can this be solved permanently with a .profile change for the user "sas" or does each individual profile that connects to SAS need this change?"  If the "sas" user is the only one that is required to have these higher limits, then I can parallel the changes outlined by the link you provided

Chapter 11. Setting Shell Limits for the Oracle User.

Tangentially, yesterday we manually set the soft limit for open files to 20480 as stated in the SAS documentation and then manually ran the sas.servers script.  This "brought the server to its knees" and the systems administrators were getting all sorts of memory and processor usage warnings.  This was on a 64-bit quad-core 64GB memory Solaris server.  We stopped all the SAS processes and set the ulimit to 2048 (10% of recommended) and was able to successfully bring up the SAS services via the sas.servers script.  This issue is definitely something that we plan to bring up with SAS support.

Thank you again for your comments and suggestions.  I am curious what others on Solaris servers have done for this soft limit requirement.

Shaun

Valued Guide
Posts: 3,208

Re: SAS 9.4 Middle Tier UNIX ulimit settings

Hi shaun,

Yep you are right to have it by the hardlimits allowable to set each user accordingly at startup of the process. That is a approach sys-admins are more likely to accept.

Letting the default soft-limit low will set up limits to unknown processes doing unwanted things.

This is the area I found a lot of issues in the approach of the SAS technical adjustments.

They do a lot advanced things on those (Margaret Crevar) and  then with sales promoting get root type setup that is it. In no way aligned to existing IT policies.     

The inheritance and setuid (starting new processes). That ones are not using the expected user standard OS settings but sometimes that of original user or the system default.
That took me a lot of time to get it to the root-cause (years ago). Nice to see you have the same experience, not nice it is still there.

It could be set in some scripts I think but as there that many I cannot be sure which ones and whether that are all of them. That is the designer/builder of this.

Let us hear if someone has more information.     

---->-- ja karman --<-----
Ask a Question
Discussion stats
  • 3 replies
  • 931 views
  • 0 likes
  • 2 in conversation