LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (August 2006, week 1)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Mon, 7 Aug 2006 22:21:55 -0500
Reply-To:   "A. Michielsen" <amichielsen@COMCAST.NET>
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   "A. Michielsen" <amichielsen@COMCAST.NET>
Organization:   Your Company
Subject:   Re: How large should the UNIX machine have to be?
Comments:   To: sas-l@uga.edu

[posted and mailed] We currently support about the same size user group with SAS and SAS EG, mostly with large volumes of data from Oracle. With the old IBM 6 - 650Mhz PowerPC4 CPUs. The new P5 Series (P550/P570) have 1.9Ghz PowerPC5 CPUs. The Power5 chips are also Dual Core while the Power4's aren't. So, besides clock speed, the Power5 chips are substantially better. I just updgraded another (nonSAS) box from the PowerPC4 to the new PowerPC5 (P570) - and the new boxes rock. It's knocked hours off large Oracle Warehouse Export, Compress & TSM Jobs. I wouldn't hesitate to start with 6 CPU's - with a backup plan to be able to add CPU's up to the System max, like 16 CPUs on the P570. The large issues is the total amount of memory and I/O speed. You really don't want to be short on memory. If you decide to LPAR, you lose nearly 5GB of ram to the AIX memory manager, so if you figure that between a LPAR memory manager, and Webservices only 50% of installed memory will be available for SAS Programs. So, to maintain a minimum of 256MB per user, that's upwards of 32GB of Ram. If the WebServices will include JAVA services, we see pretty substantial memory leaks that basically require a reboot to recover. You may need to be on a weekly reboot depending on your JAVA Memory leakage. As others have suggesterd, you may consider a seperate LPAR for the WebServices - perhaps with additional CPUs. That would allow for much easier WebServices Reboots to recover Memory without impacting the SAS Server. The importance of I/O speed for the Disk Storage can't be stressed enough. Our typical Unix/Storage folks can't understand that SASWORK shouldn't be mirrored at the expense of I/O speed. I assume you'll be using SAN type storage. Plenty of SAN Adapters for 'various' mount points is pretty important to keep from throttling the I/O thru a single SAN Adapter. You can get a 'perfect' mount point disk layout - but if all (or conflicting) mount points share the same SAN Adapter or the connection in the Storage Array, you'll lose I/O (speed) either getting stuck at the SAN Adapter or at the Cache in the Storage Array. The I/O Cache needs to be HUGE - we run constantly over the Storage Array Cache.

"elfrabo" <f.boekamp@planet.nl> wrote in news:1154714509.678213.163330@p79g2000cwp.googlegroups.com:

> minion schreef: > >> elfrabo wrote: >> > We expect about 40 to 50 endusers concurrently using dynamic >> > queries with parameters through the Information Delivery Portal. >> > All processing, including the webportal itself will be done on the >> > same UNIX machine (an IBM type 570). >> > >> > Any idea how many processors we might need to handle this request? >> >> Your local SAS Office generally provide this service but they tend to >> be be very conservative i.e. sub-second response times. They would >> also recommend spliting the Metadata and Web server onto a separate 2 >> processor machine (Windows is fine) and keeping unix for pure >> processing. Plan for 4 CPUs but make sure that you can add more. > > Thanks for your answer. > > We received a questionair from SI for our sizing request. The > questions are very detailed and some only can be answered by an > educated guess. So we concluded that the advice can not be more > reliable than our educated guesses. Furthermore we also estimated that > the advice of SI would be oversized: they would never take a chance to > advice too little processing power. So our final conclusion was that > we better make an educated guess ourselves. > > I got a similar advice from a collegue: 4 processors to start with > should be fine. He pointed out that internal memory though is > essential in performance. Any ideas how many GB's We should plugin > into the machine? > >


Back to: Top of message | Previous page | Main SAS-L page