SAS on Solaris - Installation and Configuration Guidelines

SAS Software on Solaris Installation and Configuration Guidelines

The following is a brief set of guidelines for a Solaris installation and covers the following topics:

• Solaris and SAS Software Installation
• Data Management
• Memory Configuration
• Performance Monitoring and Tuning
• Large File Support

There are a number of different ways in which you can configure the Solaris installation.  A sample installation could configure Solaris in a single partition with a SWAP area configured on the same or different disk.  In general, SWAP should be configured to be 1-2 times the amount of memory you have (more if you have a small memory configuration).  

The SAS software installation is very straightforward- extract the install software from the CD-ROM and then invoke $SASROOT/sasmanager to complete the software and license (setinit) installation. $SASROOT represents the SAS system installation directory. Typically, there are no kernel configuration parameters that need to be made nor changes to system files.  The exception would be changes to files required by individual add on products.  For example, SAS/SHARE software uses TCP services and requires changes to /etc/services to define the associated port number and service name.

Note,  relational data base products typically require kernel parameter changes  (such as shared memory allocations) specified in /etc/system.  If you are running other applications on the same hardware configuration, be careful about noting if these changes affect the SAS applications.

Typcally, this is an area of greatest flexibility and choice.  The hardware, software and configuration of attached storage can vary tremendously depending on a number of factors such as the storage platform, the volume management software (ie: Enterprise Volume Manager vs. Solstice Disk Suite), choice of RAID levels (mirroring (RAID-1), striping(RAID-0), striping+mirroring (RAID-0+1), mirroring+striping (RAID-1+0) or parity (RAID-5)). The choice of RAID level depends on your needs to balance volume availability, cost, criticality of downtime, and performance.

For the SASWORK area specified in $SASROOT/config.sas612, consider using a simple striped volume (RAID-0).    Since this is a temporary work area, redundancy of data is not critical under normal circumstances.  In this case, don't use a RAID-5 volume for the SASWORK area since several I/Os are required for a single write operation when using RAID-5 ( Storage products such as the Sun Array 2000 support hardware RAID-5 which addresses this issue).

 Note that users can override the SASWORK area specification so be sure to notify them of appropriate areas.

In the data warehousing environment where the typical access scenario is READ-ONLY,  RAID-5 should provide a good balance of availability, performance and cost.  Mirroring or RAID-1 provides for the best availability and perhaps the best READ performance since either side of a mirror can satisfy a read request.

Several tasks in the SAS system  (such as Sorting, Summarization, heavy modeling, MDDB creation) typically use a large amount of memory  The amount on a per job basis is specified in the system wide $SASROOT/config.sas612 file but can be overridden on an application basis.  SAS applications  will use up to the MEMSIZE specifiation and page data in and out of this system/user defined area.  Application performance greatly depends on the dynamics of SAS paging in conjunction with Solaris paging.   In general, let SAS do the paging or Solaris do the paging but avoid both having to page.  To determine the amount of memory that a particular SAS application uses, run the application with the fullstimer option.  The log file will show you how much memory was used (remember that only up to MEMSIZE will be used).  The memory usage should be summed for all applications and all users and balanced against the amount of physical memory on the system.  On a system with many users, MEMSIZE/SORTSIZE  should be lowered to the point where performance is acceptable such that one job does not consume an unfair share of memory. Some procs such as MDDB require that MEMSIZE be large enough for the entire n-way table.  This is an example of where MEMSIZE might be required to be set greater than the amount of physical memory.  In general though, setting MEMSIZE  to be greater than physical memory could cause both Solaris and the SAS software to page.

 Memory is one area of the hardware configuration that should not be economized if at all possible.

Note, that if you are running a relational data base on the same system, you will have to take into account those resources required.  Relational data bases often require a large system global area to run optimally.

A memory based file system (TMPFS) may be specified for the WORK directory.  In general, this could be a big performance win.  However, the opposite affect could be seen if the size of the WORK files created exceed the amount of available memory by such a large amount that performance could be worse than if WORK been specified on an UFS file system.

Command line tools such as vmstat(1M), iostat(1M), netstat(1M), sar(1), ps(1) are bundled with Solaris for performance and resource  monitoring.  For example, vmstat provides virtual memory utilization information.  Additionally, the scan rate (labelled "sr") column could indicate a system memory shortage if consistently showing 200-300 pages per second. If the CPU complex columns show no idle time, this could indicate CPU bound processes.

When performance issues are at hand, all aspects must be considered from the application, number of users, number of CPUs, I/O subsystem, network, memory, etc.  Since Solaris 2.x provides a fully multi-threaded kernel, excellent scalability can be achieved in distributing user loads and I/O throughput over multiple CPUs, I/O controllers and network interfaces.  Additional information on Solaris performance monitoring is available here.

There are several visual interfaces to the performance monitoring tools such as Solstice SYMON and proctool (Note: versions are specific to a particular Solaris release)

 For SAS specific optimizations, refer to the Optimizing SAS Systems performance on Solaris paper.

With Solaris 2.6 and the SAS System, Release 6.12, large files (files >2GB) can be natively supported.  This requires the sasvlfs binary (available as a patch to Release 6.12 from the SAS Institute technical support department) to be installed in $SASROOT/sasexe/base and an invocation option (ie: sas -LARGEFILE sasvlfs) on the command line.

Large data sets can be used in a partition format with any version of Solaris 2.x that SAS System, Release 6.12 supports.  More info on using partitioned data sets as well as native large data sets can be found in the Solaris large file paper.

Copyright (c) 2000 SAS Institute Inc. Cary, NC, USA. All rights reserved.
Date last modified: Fri Jan 28, 2000 18:40 UT