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?
[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?
>
>
| 
