Every time we complete a SAS installation, there are some options in the SAS configuration file that we adjust based on the client site. These options control the memory usage, CPU usage, and the SAS WORK library locations. Each installation has different thresholds, but the options remain the same.
If you incorrectly set your performance options this can lead to performance problems when you are working with large datasets. By configuring performance options based on your environment and needs, you can improve the general performance of the SAS server. As always, check with your SAS administrator to see what capabilities exist and how you can maximize these options if you have any doubts. (Also, consider how SAS for containers can transform your SAS administration.)
In this post, we show you how to find the configuration files and give you five performance options you can adjust to help you get the most out of SAS.
Reviewing the Current Performance Options
If you want to see your current system performance options, run this code in the SAS editor.
proc options group=performance; run;
The results, listed in the log file, will show you your current settings.
Updating the SAS Configuration Files
There are multiple configuration files within the SAS CONFIG and SAS HOME directories for the Linux operating system. Here are the two files that contain configuration settings:
- [SAS CONFIG]/Lev1/SASApp/sasv9_usermods.cfg
- [SAS HOME]/SASFoundation/9.4/sasv9_local.cfg
Always add your options to the _usermods version of configuration files. If you modify that file, you can prevent the changes from being overwritten during a software upgrade.
Additionally, you should keep a backup copy of the original file. This practice helps keep you safe from yourself! Sometimes you might make a change that doesn’t produce a great result. To return the system to its previous state, you can restore the original file.
If you are curious about how the system calls the configuration files, you can review the order of precedence for SAS configuration files.
The 5 System Options
Here are the options we suggest adjusting for optimal performance.
Setting the SAS WORK Library Location and Default Permissions
If you have the option of mounting additional hard disks for your SAS WORK library, you can set the library location using this parameter. The SAS WORK location is one of the most intense areas of activity of IO throughput. Almost all the SAS processes use the WORK library for temporary data needs. Segmenting this activity on a dedicated mount point is ideal for maximum WORK library performance.
We are directing the SASWORK library to a file mount called “/saswork.”
In some cases, it may be necessary to set the default file system permissions for the SAS WORK library. Use the WORKPERMS option to configure the settings to where the SAS system has permission to write the data. This example is for a Linux system, so the 777 indicates everyone has read and write privileges to the new storage location.
Setting the Utility File Location
Just as it is beneficial to segment hard disk IO for the SAS WORK library location, the same principle applies to the utility files location. During heavy data processing using SQL operations, this system area is heavily used. In this example, we created a file mount called ‘/sasutil’ and redirected the storage to that location.
You can learn more about this setting in the SAS documentation located here: UTILLOC system option at SAS Support.
Setting the Number of CPU Cores and Enabling Threading
Another good practice is to let the SAS system know how many CPU processors exist in your environment and if these processors support multi-threading. For large production environments, it is better to limit how many CPU cores SAS uses, especially if threading is enabled, to prevent overloading the system. It’s a conservative approach, but it is better to be safe and scale up from there.
For example, you can generally limit the number of cores to 25-50% of the actual number of cores. Otherwise, as the load increased, SAS can potentially consume all available CPU cores and impact overall performance for other users. If you are the only user on the environment, then you can safely allow access to all CPU cores, as shown in this example.
Setting Memory Options for the SAS Processes
There are three memory options that you should configure to limit the amount of memory available to SAS per process. A best practice is to set the REALMEMSIZE, SUMSIZE, and SORTSIZE to approximately 75% of the total MEMSIZE. Here is an example of how that would look for a smaller system.
Check out SAS Support for more documentation on configuring memory options. SAS Support also suggests the proper context on MEMSIZE and UTILLOC in this usage note.
Setting Buffer Size for Writing SAS Datasets
The last option you can set is the buffer size for writing your SAS datasets. You want this size to be greater than or equal to the file system block size for where the system writes the SAS datasets. The larger the buffer size for SAS datasets, the less SAS has to read or write to the physical storage device.
However, this practice comes at the cost of consuming more physical memory. Larger buffer sizes should be in multiples of the file system block size to minimize how many times SAS has to access the file system. We suggest you select a value between 4K to 256K depending on your environment and the hardware configuration. A good bet is to collaborate with your IT systems administrator.
The key to success for these performance options is to test the changes. Doing so can help you understand what, if any, differences the change made. In some cases, an older server, or an overload of users, or overload of data will not provide the desired outcome. In these instances, it is time to review modernization options, such as SAS Grid computing environment, SAS Viya, or even running SAS Viya in a container.