08-01-2012 12:09 PM
I have a question regarding server specs necessary to run SAS Enterprise Guide. My company (as well as myself) is pretty new to using SAS. We have Base SAS installed on a server and have Enterprise Guide installed on several computers. At most 5 individuals would be running SAS at a time. Here are the specs for our server: Windows 2008R2 Standard sp1, Intel Xeon E5420 2.5 ghz (quad core), 16 gb memory. We are concerned that we may to need upgrade the server as speed has already become an issue for some of the larger reports we are running. Many of the datasets we import are relatively small (2MB). However, we need to be prepared to be able to import a dataset that is up to 3 GB and run several reports (up to 9000 reports) at a time. Based on my estimation, the largest reports we will be running could total as much as 500 MB. Our system administrator has told me that 25% of the resources are currently being used when I ran reports that total 40 MB. We are running reports that include bar graphs and summary tables. I am creating temporary datasets that I am storing in the work library for these large reports and am attempting to program a macro to run each report. I am not sure how the macro affects the creation of data files, but I am hoping it greatly decreases the amount (as data sets will be overwritten with each iteration of the macro?). Also I have a 450 GB hard drive on my computer.
I apologize for the lengthy message. Any suggestions as to how to "beef up" our server to improve future performance would be greatly appreciated. Thank you!
08-01-2012 01:25 PM
The rate limiting step is not EGuide, it is your server; EGuide just runs on the workstation and passes the programs to the server for execution. These issues all relate to the server. It sounds like you have already determined that your server is not up to the task and are asking how much more you need. You may need to go with a multi-core Linux machines with some sort of parallel processing to get past your bottleneck. You probably also need dedicated bandwidth between your server(s) and your disk storage (a lot of the bottleneck in data intensive reporting can be moving the data between places).
SAS has partnered with a number of third part consultants to help in just this task; talk to your site rep at SAS. Look for someone with experience in the load balancing necessary for the loosely coupled parallel processing; there appears to be a bit of art to configuration of those sorts of systems.
08-01-2012 01:33 PM
Thank you for the quick reply, Doc@Duke. I will contact the consulting company that helped with our installation to see what other recommendations they have, and I am going to pass on your comments to our system administrator. Thanks again!
08-07-2012 11:22 AM
My feeling is that your server is adequately powerful for what you're using is for. Depending on what you're running, your memory might be a bit low; keep an eye on it with PerfMon, and augment if necessary. If you run short of disk, up it as well; 450 GB isn't much for a SAS server, and disk is pretty cheap these days.
Using a 2MB dataset should be absolutely trivial for a server like that. Even a 3GB dataset should be quite doable, although you may notice more of a delay. 5 users is no problem at all; keep in mind, usually they'll just be looking at the screen, and won't actually be running anything, so on a quad-core processor if there's even one SAS process per core I'd be surprised.
One thing that catches my eye is "run several reports (up to 9000 reports) at a time". Is this a typo? If not, 9000 reports being submitted concurrently isn't a few!?!
What kind of reports are you running, and what do you mean when you give a size for them? (40 MB, 500 MB). SAS is very efficient, but rendering reports, particularly in HTML, can be a real headache, nothing to do with SAS. I've had a lot of experience advising users about how to change their requests to get rid of large problem reports.
A couple more suggestions: Doc's suggestion is 100% correct; make sure that what looks like slow response isn't just data passing over the network. Also, make sure you schedule regular use of the SAS utility to clean up work dataset space. And finally, if your Enterprise Guide users are new, they may tend to cancel their EG sessions and leave SAS programs running on the server, which can be a resource suck. You can watch this with Task Manager on the server, and if it's a problem these zombie sessions can be cancelled.
Good luck, and post back to let us know what happens!
08-07-2012 08:26 PM
There are heaps of useful SAS resources on how to configure your Windows SAS Server for optimal performance. If you search the SAS support site with the key words: Windows server performance Crevar, you will find many of these. Margaret Crevar happens to be the SAS guru on this subject and is the author of many useful papers.
If you think performance needs improving then looking at disk IO and storage is usually where you can get the biggest bang for your bucks as SAS is a very IO intensive application. Here's a few tips in this area:
- ensure your SAS WORK and permanent storage are on different file systems.
- configure WORK disk to be RAID 0 or 10
- configure permanent storage to be RAID 5 or 10
- split WORK and permanent storage on different IO channels
There's a lot more to look at - check out Margaret's papers.