A good starting point would be to post the complete SAS logs of of several queries that run slow. Comparing run times with CPU usage will help. Also what is the performance difference at peak times versus low usage times? If queries run in a reasonable time during periods of low usage it is safe to assume they are running reasonably efficiently and don't necessarily need tuning. If they are still slow then they either need tuning or there are some serious bottlenecks in your SAS infrastructure that need fixing.
You should be monitoring the SAS Environment Manager dashboards as these will help isolate where your SAS performance problems are.
Maxim 2: Read the Log.
Start with inspecting the log(s) and identify the long-running steps. Then see if other techniques to achieve the same result are more efficient.
If no logs are available, have the users send you the code so you can test it yourself.
If code proves to be efficient and no further significant optimization can be done, move the server load to off-business hours by creating batch jobs and running them from the scheduler. Power users who run large scale projects and employ efficient coding techniques may need additional resources (larger MEMSIZE, additional high-speed - SSD! - temporary disk space)
If remote DBMS systems are involved, look to reduce the amount of data transported over the network.
Once you have identified problematic steps and are not sure what to do, run them with FULLSTIMER and show them here.
To further what KurtBremer was saying, see if you can add these statements to the SAS code:
OPTIONS FULLSTIMER SOURCE SOURCE2 MSGLEVEL=I MPRINT NOTES;
PROC OPTIONS GROUP=MEMORY;
PROC OPTIONS GROUP=PERFORMANCE;
LIBNAME _ALL_ LIST;
PROC OPTIONS OPTION=WORK;
PROC OPTIONS OPTION=UTILLOC;
%PUT This job started on &sysdate at &systime;
OPTIONS SASTRACE=”,,,s” SASTRACELOC=saslog NOSTSUFFIX;
The last statement will help with information if the query is going to an external database. It tells you the amount of time spent in the database and the amount of time spent transferring data back to SAS.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.