Change Some Common Options to Get More Server Performance
04/02/2019 by Michael Koob Support
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 configured, but the options remain the same.
In some situations not having the performance options correctly set can lead to performance problems when you are working with large datasets. By configuring and tuning options for 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 explain a few of the performance options you can adjust.
If you want to see your current system performance options, run this code in the SAS editor.
proc options group=performance; run; The information appears in the the log file.
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:
Always add your options to the _usermods version of configuration files. If you modify that file, it prevents 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.
Here’s what the sasv9_usermods.cfg file for the Linux system looks like once we updated the file. Let’s review the changes that were made and why.
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 process uses the WORK library for temporary data needs. Segmenting this activity on a dedicated mount point is ideal for maximum WORK library performance.
We are pushing 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.
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.
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.
-cpucount 4 -threads
These are three memory options that you should configure together. Use these options 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.
-memsize 4G -realmemsize 3G -sumsize 3G -sortsize 3G
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.
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 the 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 to understand if the change made a difference. In some cases, an older server, an overload of users, or overload of data will not provide the desired outcome. In these cases, it is time to review modernization options, such as SAS Grid computing environment, SAS Viya, or even running SAS Viya in a container.