Warning: 3 Tell-Tale Signs You Need to Upgrade your SAS Platform
08/18/2019 by Jonathan Boase Modernization - Infrastructure
If your organization is risk-averse (as many understandably are), you might be putting off a much-needed upgrade to your SAS environment. After all, “If it ain’t broke, don’t fix it.”
However, you may not realize to what extent things are already broken. Sure, you may have heard rumors, anecdotes, grumblings, or received the occasional angry email, but it’s never risen to a level to force a change. So while you might be okay with how things are in the short term, inevitably a moment arrives where a senior director can’t get her report.
Alternatively, even worse, the business misses a critical regulatory submission deadline. Only then will a lot of (unwanted) attention be paid to these issues that may not have seemed vital as they quietly piled up one-by-one along the way.
Here’s a list of signs that your environment needs help.
If your employees or co-workers are behaving oddly, such as getting up at 2 am to run their SAS jobs, this should be a red flag that the environment is not okay. Environments can become so overloaded that SAS Enterprise Guide sessions struggle to run.
Even the most basic procedures struggle to complete because there are just too many users on the server during regular work hours. So users must adjust their work schedule to accommodate when they can get their work done.
If multiple departments are sharing an environment, users become aware, based solely on their SAS jobs performance, that “Oh, the actuaries must be running their monthly reports right now” or “the data scientists are creating new models.”
If you see users scheduling their work around these recurring activities because “everyone knows you can’t get any work done in SAS during the first week of the month,” then you can be sure you have a problem.
There are four main resource constraints on SAS sessions: IO, memory, storage (to a lesser extent), and CPU.
Even well-tuned environments can be brought to their knees because IO is completely maxed out, and your server cannot give enough data to your CPUs to keep them busy. Often, IO-bound environments can be challenging to improve significantly without re-architecting your environment as there are physical limitations on your hardware.
The impact on users is that their SAS sessions are prolonged at reading and writing data sets even when their code isn’t computationally complex.
If you’ve had to set hard and fast MEMSIZE limits on your users, while it can be considered a good practice, this might also indicate there isn’t enough memory in the environment to meet the demands of the users.
The users’ sessions can, as a result, get out-of-memory errors, or their jobs will start using less efficient means of processing the data (such as relying too much on virtual memory).
If you must closely monitor the SASWORK directory (the temporary storage location for active SAS sessions) so that it does not fill up, then you might have a problem. There is a CLEANWORK process that can be scheduled to delete old, orphaned data from SASWORK, and SASWORK should be sized appropriately for your environment. However, if just the data from numerous active sessions are filling up this area and users’ sessions are dying while trying to write out temporary data sets, this is a clear indication that you have a problem.
Finally, if your users’ sessions are slow due to fully utilized CPU on the server, then congratulations. You have a very efficiently run environment, albeit too small.
If your SAS license allows for it and your hardware is capable, you can add more cores to your Compute server. If not, then you again have a problem.
This may seem a bit counter-intuitive and generally applies to situations where multiple departments are sharing a SAS environment.
It starts with good intentions as team leaders from all departments who use the SAS environment get together to establish data standards, programming practices, and coordinating training.
However, the committee can devolve into protectionism, rationing resources such as new storage and software licenses and allocating them according to priorities weighted by upper management.
“We budgeted for 5TB of new storage for this year, and because this new marketing campaign is an important initiative we are giving the marketing analytics team 3TB of it.”
Getting additional resources for a team becomes a political challenge that must be argued on an ROI or strategic basis. There is merit to that approach, but it does leave a clear pecking order to the relative value of the remaining teams.
I’ve even been a part of weekly committee meetings where every new user request was scrutinized and voted upon with the understanding that each additional new user could cause additional slowness for all other users.
This process led to teams with legitimate needs not being allowed to use the SAS environment for their processes, continuing them down the path of information silos and desktop tools like Excel.
Maybe now you’ve realized that your environment is more broken than it seemed. What can you do about it? Upgrading your SAS environment to SAS Grid can significantly alleviate the issues above along with providing many additional advantages such as workload balancing, job prioritization, job scheduling, and high availability.
With SAS Grid, you can build your SAS Compute tier to meet your organization’s needs with a relatively easy path to continual expansion and growth. Plus there is often a real cost savings of moving to SAS Grid.
If you are looking for additional modernization choices, consider running SAS Analytics from a container. This technology is especially interesting to SAS administrators who need more capacity for the analysis that data scientists are often doing.
And … of course, SAS Viya uses in-memory to provide speed and powerful performance for advanced analytics.
At Zencos, we’d love to hear about your challenges and help you solve them. Contact us for a site assessment.