To all who attended the first SUGA virtual meeting, we thank you. My presentation showed users how to tune their operating system and their SAS environment. I answered some questions during the event, but wasn’t able to cover them all. So, I’ve provided the Q&A here for all those who attended..
Q: How do you determine the file size to use with sasiotest.exe to get meaningful output?
A: The sasiotest.exe is available for SAS users on Windows. There is a SAS note that discusses how to use this tool. If you want to test the IO subsystem on your computer, you need to make sure that the files you are creating are larger than physical RAM in the computer. If they are not, you will be testing how fast your memory can do IO.
Q: Any tool that monitors at a user level?
A: The SAS Environment Manager is the best tool to do this. More information on this tool can be found here.
Q: Can you monitor IO throughput with a tool? If so, which item is it exactly, is it is a tool like Solarwinds?
A: Yes, this can be done with a tool from SAS called iotest.sh or with any hardware monitor tool. I am not familiar with Solarwinds, but if it can tell you the MB/second and if there are any WAIT times, then this will be fine.
Q: How do you monitor users live?
A: The SAS Environment Manager is the best tool to do this. More information on this tool can be found here.
Q: How busy ARE the cpu's, how can I tell at any given time without custom code and growing datasets?
A: The SAS Environment Manager is a tool to do this. More information on this tool can be found here. There are other hardware monitor tools like nmon from IBM or PerfMon from Microsoft. More details on using nmon (for AIX or Linus) can be found here. Are you wanting to just do spot checking of CPU utilization? If so, the tools like top or taskmanager can be used.
Q: Would there be any performance benefit in switching off journaling on the ext4 saswork filesystem and would it be wise/beneficial to split saswork and sasworkutil on different luns?
A: For SAS WORK, there is no need to have journaling turned on. Please note we have never seen a huge benefit in turning it off. If you do, please let us know.
Q: What are common baselines you suggest?
A: By baselines, I meant to gather hardware monitor information for a long period of time, preferably 24 hours. You can use nmon or PerfMon or some other hardware monitor tool to gather snapshots of your hardware infrastructure (each system) every 5 minutes for 24 hours. Keep this information to use to compare with similar collections over time to do a comparison to see how busy the various hardware components are.
Q: How do you tell if SAS Workspace server is orphaned?
A: Besides letting SAS do it for you, it would be to do a ps command to determine if the PPID value for the SAS Workspace server is not 1. I will chase to see if there is a tool you can run.
Q: How to delete orphaned SAS workspace servers?
A: there is another tool that can be run on a regular basis to detect (and terminate) these orphaned sessions for you. For more information about this tool, see SAS Usage Note 45627.
Q: With SAS 9.4 are the orphaned workspace servers deleted nightly or more frequently?
A: When using the tool that is part of SAS 9.4 and documented here can set the timeout value. Once this value has occurred, the SAS workspace server is terminated.
Q: cleanwork has been really useful. Is there a similar utility to monitor Datasets which are lock and most importantly by whom?
A: There is no utility per se, but there was an excellent discussion on this topic on one of the SAS Communities on this topic. Please review the discussion on this topic here.
Q: Is there a "translation link" we can use to determine what these lgs are trying to tell us? It is pretty convoluted.
A: There are so many logs associated with SAS, can you let us know which ones you are referring to? If you are referring to the SAS log produced by a SAS job, here is a paper (it is a bit dated) that discusses the most important information created with the F....
Q: Have you used Veritas Cluster File systems? We have 3xSAS GRID nodes.
A: Yes, we have several SAS customers using Veritas’ CFS with SAS Grid and they are very happy with it. My team is in the process of doing some testing with folks from Veritas and will be publishing a tuning guide later this quarter. We will announce its availability via the Administration Community and Administration Blog.
Q: Where can we get tuning suggestions for the ZOS environment?
A: I am currently looking for ZOS tuning suggestions.
Q: How about SAS data files over NFS on a shared NAS device?
A: We support SAS data files (permanent ones) in mostly READ mode to be stored on NFS. However, we strongly advise you never use NFS on a NAS device for SAS WORK or SAS UTILLOC – unless you SAS data files are small (less than 500 MB in size).
Q: What is the best way to quickly get an idea of current/live server activity and usage over time, for example a list of jobs and their run times?
A: The SAS Environment Manager is the best tool to do this. More information on this tool can be found here.
Q: Not sure if this is appropriate but: How do we connect Tableau to the SAS Grid?
A: SAS recommends the use of Visual Analytics and Visual Statistics in place of Tableau. These are highly scalable and full-featured products that can interact with data held in SAS.
Q: Is SAS developing data collectors for xymon, specifically for things like SAS license expiry and license errors (CPU mismatch, etc)
A: Yes we are. More details can be found on the SAS Environment Manager focus area which is located here.
Q: How much from installation to authenticating and authorizing users in group can be scripted from something like OpenStack, Chef, Puppet?
A: TBD
Q: How do I setup alerts on file system from within SAS?
A: The SAS Environment Manager is the best tool to do this. More information on using this tool to set up alerts can be found here. You can also use other tools (like the ones for Tivoli) to send alerts when file systems are xx% full. I discussed this in this SAS Global Forum paper.
Q: Which parameters we have under our control when trying to use SAS in the Cloud (Amazon, Azur,...)?
A: I am not sure what you mean by this question. Here is a paper my team put out last year talking about running SAS Grid in the Amazon cloud. You install SAS the same way in the Cloud as you do on hardware in your data center, you are just now restricted to how Amazon allows you to configure your systems.
Q: For Margaret: do we need to have 1 volume group for Work area and Util area. Isn’t it good to have 2 storages for Util area?
A: In the past, we strongly recommended you create separate file systems for SAS WORK and SAS UTILLOC, each with their own dedicated disks. However, with today’s new “striped everything” storage arrays, the ability to do this is not available. Since separate file systems for SAS WORK and SAS UTILLOC are accessing the same disks (because of the “striped everything” nature) there really is not performance advantage to having separate file systems. Of course, if you are using local SSD/Flash drives, then please continue to separate the file systems provided you can get the IO throughput required for each one.
Q: How to determine on hard and soft limit for SAS user?
A: I am not sure what limit you are referring to here. Many of these are set via user limits on Linux and UNIX systems. You can see what they are using the ulimit command.
Q: Can we set size limit for user or group on Linux?
A: Not from within SAS. This could possibly be done via your operating system and user limits. Please ask your System Administrator for help with this.
Q: Does dataset compression improve performance if you are not operating near CPU capacity? Are the compression/decompression processes piped with the basic SAS I/O to get parallel processing?
A: It does on computer systems that have less than ideal IO throughput AND the data file has been reduced by over 50%. At that time, the cost of the decompression is negated by the smaller amount of IO that has to be transferred from disks. So areas to watch for are SAS procedures that have to see the entire SAS data file in an uncompressed state, like PROC SORT.
Q: When setting SAS swap space it is generally recommended to set a swap space up to 1.5 times the size of the physical memory available to SAS. Why?
A: Depending on the operating system, if you use all available memory (physical RAM and swap space) in a system, then the operating system will start deleting active processes. If you swap file is always greater than physical RAM, you will not run into this issue.
Q: Not a technical question: is there or will be an informative site for SUGA, besides the Communities? Could not see any, nor on Communities
A: Right now the Administration and Deployment Community will be the site for SUGA. Once a steering committee has been established, there may be additional resources. If you'd like to be a part of the committee, please feel free to email Natasha.Collins@sas.com
Q: How many SAS users have you supported? Business users? Power users?
A: I am not sure what you mean by this question.
Q: Can we limit the no. of workspace sessions for the users?
A: You can enable load balancing to enforce a limit on the total number of workspace servers launched and running at any given time. This is not enabled out of the box for workspace servers.
Q: Are there any infrastructure tuning for SAS solutions (ie: SAS CPM)?
A: For the most part, they are the same as for SAS Grid systems. You need to make sure the backend compute tiers have the computer resources required to meet your SAS users’ needs.
Q: Can you set size limits for sas WORK? Limit the amount of space a user takes up in work? 150G ? 200G?
A: Not from within SAS. This could possibly be done via your operating system and user limits. Please ask your System Administrator for help with this.
Q: Is there a way to prevent malformed or poorly written SAS code from chewing up all or most all of the system CPU resources to the point it makes it unresponsive for other users?
A: Other than training all the users in proper and efficient programming techniques, not really. A recent trend is moving from a single SMP system to house all the SAS users, but multiple SMP systems – managed by SAS Grid Manager – where you can have a several SAS Grid nodes be dedicated to production only SAS jobs and the rest be for adhoc users where a “poorly written” SAS job will not affect production SAS jobs.
Q: If you have handful of (ab)users, being able to limit those individual users would preserve integrity of system and prevent SASWork filling up for all users
A: Here is a good example of when having multiple SAS WORK areas makes sense. You can have one for well-behaved SAS users, and another one for the handful of (ab)users to prevent them from filling up SAS WORK. In addition, the answer to question 33 addresses how to “corral” these users to their own SAS compute node so that they do not take over more computer resources than they are allowed.
