Blogs

Blogs

Improving performance: Determine the cause

9
By Topics | SAS Administrators

Thanks for reading my previous post about the importance of understanding your performance issues before trying to determine the cause.   Compiling all the available information about the problem and finding a repeatable SAS process that can be monitored are the first steps toward fixing the issue.   Since we now have that, let’s talk about what needs to be monitored and how.

Which tools to use

As you monitor the SAS process, matching what is happening from both the SAS log and hardware monitor logs will help you understand what needs to be improved.

As a standard practice, my team always starts by assuming the performance issue is coming from a constraint or bottleneck in the hardware infrastructure and then determining where that bottleneck might be.  To do this, we start with the repeatable SAS process that we've documented and add the following SAS statements to the start of the SAS job.  The output from this job will helps us understand more about what is going on with the SAS process and determine which step or steps are taking the most time.

OPTIONS FULLSTIMER SOURCE SOURCE2 MSGLEVEL=I MPRINT NOTES;
PROC OPTIONS GROUP=MEMORY;
PROC OPTIONS GROUP=PERFORMANCE;
RUN;

LIBNAME _ALL_ LIST;
PROC OPTIONS OPTION=WORK;
PROC OPTIONS OPTION=UTILLOC;
RUN;

DATA _NULL_;
%PUT This job started on &sysdate at &systime;
RUN;

OPTIONS SASTRACE=”,,,d” SASTRACELOC=saslog NOSTSUFFIX;

If we run the SAS process (with the above code included) and turn on some free hardware monitoring tools, then we will have lots of data to help us determine if there are any hardware constraints to the computer system where SAS is running.

  • For Windows systems, we turn on PerfMon.
  • For UNIX/Linux systems, we turn on iostat, vmstat, sar and several other monitors.

What metrics to monitor

The areas we look at from the hardware monitor logs are:

  • CPU busy
  • Memory utilization (i.e. did the process completely use all the memory and swapping occurred)
  • IO throughput numbers (including whether or not the disks are busy AND have wait queues).

How to find this information in the hardware monitor logs takes a lot of time to explain, but we have several white papers that you can read to help you start.  Here is a list of them:

When you determine the possible source of the problem, we strongly suggest that if you make a change in your hardware infrastructure, you make only one or two changes at a time.   Test the change by rerunning the SAS process to see if the change has helped or hurt performance.   It may take many changes to the hardware infrastructure before you see a complete resolution to your performance issue.

Stay tuned for Part III:  How to Proactively Prevent Performance Issues. Of course, if you have any questions, please reply to this blog and we will help you out.

Tags performance SAS Administrators
Share

About Author

Margaret Crevar

Manager, SAS R&D Performance Lab

Margaret Crevar has worked at SAS since May 1982. She has held a variety of positions since then, working in sales, marketing and now research and development. In her current role, Crevar manages the SAS Performance Lab in R&D. This lab has two roles: testing future SAS releases while they're still in development to make sure they're performing as expected; and helping SAS customers who are experiencing performance issues overcome their challenges.

9 Comments

  1. Robert Wasicak on

    I find the following when debugging a connection to a database
    OPTIONS SASTRACE=”,,,d” SASTRACELOC=saslog NOSTSUFFIX;

    However, the size of the log will be huge, set your obs to something very small like 5-12 and grow from there.

    I would like to know if SAS has a log parser for SASTRACE and all it's options. Debugging a log from a database connection can be a huge task. An incredible helpful idea would be to have a log parser with options available in SAS Environment Manager.

    Reply

  2. Pingback: SAS FULLSTIMER—turn it on! - SAS Users

  4. Margaret on

    There is now way to make a SAS session that uses single threaded procedures or the DATA step use more than one processor in your system.

    You can however, take the single SAS session and look at breaking it up into multiple SAS sessions, each doing a little of the work. To help you determine if your single SAS session can be broken up, please refer to SAS procedure, SCAPROC (SAS Code Analyzer). Here is a Powerpoint presentation from SAS Global Forum 2010 that discusses how it works http://support.sas.com/rnd/scalability/grid/SGF09_SuperDemo_SCA.pps . along with SAS documentation on the procedure.
    SAS doc is here http://support.sas.com/documentation/cdl/en/proc/64787/HTML/default/viewer.htm#p0sf63lx4fs2m5n14qv1bn8p863v.htm

    Hope this helps.

    Reply
    • Pascal Maurice on

      Thank you Margaret,
      I'm working on the PROC DS2 to convert old style DATA STEP and make them multi-threaded, it is a brand new subject, perhaps create a new stream about it to share experiences ?
      have a good day

      Reply
      • Margaret on

        Thank you for this comment. I have passed it on to the PROC DS2 experts. Hopefully we will see a separate blog from them in the near future.

        Reply
  5. Pascal Maurice on

    Hi Margaret,
    One of the question we have to face at customers site is the following: we have a very powerful multi-CPUs * multi-thread platform, but SAS is not able to use it at its full capacity because all the steps of a sas code are not multi-threaded.
    Have you some advices to be able to better use the servers CPU capacity?
    thank you

    Reply
  6. LeRoy Bessler on

    Here you close with "Stay tuned for Part III".
    Presumably this blog is Part II.
    Where can we find Part I?

    Reply
    • Waynette Tubbs
      Waynette Tubbs on

      Hey LeRoy,
      The link to the previous post is in the first paragraph. Thanks for reading the posts.

      Reply

Leave A Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to Top