If your SAS server performance has been lagging, it might seem as if @MaryLeeShark (a 16-ft great white shark with a Twitter account) has taken a bite out of it. Slow system performance can be the result of many issues, such as outdated hardware to even users having poor programming techniques that overwhelm the system.
While there are no known shark attacks on SAS servers, here are a few factors to consider as you diagnose your system performance.
Upgrading SAS Servers with Software
If you have recently installed or upgraded your system, ensure you followed the SAS hardware recommendations. As many experienced administrators know, a server that is more than three years old may have a hard time keeping up with newer applications. The newer servers offer not only speedier performance due to advancements in computer processing but other benefits such as efficient power consumption and better memory management.
In the past few years, commodity hardware has become more popular to use. Commodity hardware generally refers to inexpensive standardized servers that are easy to purchase from a variety of vendors. These servers do not have a specific purpose. You can use them with Windows or Linux based operating systems.
You should periodically benchmark your servers, so you understand when performance issues are occurring. For any benchmarking test, make sure you are simulating what SAS users are doing. Here’s an example benchmark using a SAS macro. Run the benchmarks at different times of the day to better understand the impact users have on the system. If you change any performance options, you should compare performance before and after results of any changes you make.
However, powerful servers are only a small part of the equation. If you install a powerful server without making other changes, then you only enable bloated databases and inefficient programs to run lightning quick!
Tweaking SAS Performance Options
In many situations, increasing the amount of memory available to SAS boosts performance when working with high volumes of data. The SAS option for controlling how much memory a session can use is managed using the MEMSIZE option.
Be careful, though, using more system memory to process data can improve performance but can also impact other processes or even the ability to complete the job at hand. It can be as dangerous as a Caribbean reef shark helping as you spearfish in the Bahamas!
Along with setting the MEMSIZE option, it is a good practice also to restrict the SUMSIZE option. SUMSIZE limits how much memory SAS can consume for data summarization tasks that use class variables. SUMSIZE should always be less than MEMSIZE and REALMEMSIZE to leave spare room for other subtasks within the PROC. If SAS needs more memory to finish the step, it creates a temporary utility file on the filesystem. [Other tips for changing options to get more performance.]
Configuring both MEMSIZE and SUMSIZE is a better practice to follow to ensure the stability of processing data but at the cost of longer build times due to swapping data to hard disk. There are many options available within SAS to manage performance.
It is essential to understand the pros and cons of configuring performance options in SAS and take appropriate steps to balance for the best approach. The SAS Platform Administrator should manage these options in your environment.
Should You Modernize Your SAS Platform?
In some cases, administrators determine the server hardware and software are fully optimized but still as slow at processing data. The issue is how the users move the vast volumes of data around the server during their analysis process. In these cases, you should consider other SAS products, such as SAS Viya or SAS Grid.
SAS Viya Uses In-Memory for Power
The SAS Viya environment is powered by cloud analytics server (CAS). It is composed of an in-memory engine with the ability to overflow to disk to work with tables more extensive than the total available memory and microservices that provide administrators with user and data management capabilities.
CAS has an elastic and scalable design in line with today’s need to perform infrastructural adjustments based on system load and demand. It’s easy to add or remove worker nodes from an existing CAS deployment. This makes it possible to leverage platforms, such as AWS, to spin up new worker virtual machines during times of peak usage and shut them down when the demand for resources decreases.
SAS Grid Supports Multiple Servers for More Power
A SAS Grid computing environment is ideal when multiple users want to access multiple servers. It intelligently uses available computing resources — specifically, it routes jobs to the least “busy” server or node in the grid on behalf of a user. This saves the user time since they no longer need to concern themselves with where a program would execute the fastest.
Also, the overall computing power in a grid can be managed via queues with some queues being given a higher priority over others in terms of resource consumption. Grid computing environments can also be scaled easily. Unlike Hadoop, a grid environment allows for heterogeneous computing resources. In other words, each server or node in the grid does not have to be identical. Servers can have different amounts of RAM and CPUs, which allows an organization to potentially leverage and combine both their legacy and new hardware as Grid nodes.
It Feels Like a Competition
Before you can diagnose system performance issues, you must understand if the system is fully optimized or if your data load is just too vast. As the need for analysis grows, business users compete for system resources.
Many organizations are struggling with finding solutions that are economical but still allow the business to swim with the sharks! These options should give you some ideas to consider the right path forward.