At my workplace we have a heavily used SAS server, but its workload is such that obtaining 1 minute of CPU time often takes 10 minutes of real time. This isn't just due to an I/O or network bottleneck - the CPU load averages are always very high during office hours, and lots of analysts have to wait a long time for their queries to run.
There are two options I'd like to compare:
- Set up a sas grid environment (link)
- Build a server cluster using ScaleMP and run a single SAS instance on it (link)
Option 1 is definitely feasible, but I suspect that the licensing would be extremely costly. On the other hand, option 2 looks like it involves some very fancy networking hardware. Is option 2:
- At all feasible?
- Potentially better value for money?
I think SAS should be able to run on one of the Linux variants supported by ScaleMP - the existing SAS server uses SunOS 5.10, which I don't think is supported, so presumably we'd have to move our database over to a new installation of sas.
Another factor to consider is that we have a very substantial codebase, which would require quite a bit of reworking to take full advantage of a SAS grid.
I'm still trying to find out more about the existing hardware, but I expect it dates from around 2005, i.e. roughly the same era as SunOS 5.10.
Update: hardware information
From the output of /usr/sbin/psrinfo -v it appears that the existing server has 32 sparcv9 cores, of which 8 run at 1.5GHz and the other 24 run at 1.8GHz. Based on the rated speeds from Wikipedia's table of sparc processors and the 2005 date of the OS I presume these are UltraSPARC_IV processors, or something fairly similar.
From prstat, the load averages during office lunch hour are around 32, i.e. just about saturated. During peak working hours this usually rises to around 45, but it has been known to reach 110 on Monday mornings, when weekend batch jobs overrun. So I'd conclude that there's a bit a of CPU bottleneck, but it might not be as bad as I thought - the bulk of the delay in obtaining server CPU time may well be down to waiting for disk I/O rather than waiting in the thread queue.
According to the output of
# /usr/platform/`uname -m`/sbin/prtdiag -v
, it seems that the server has 256GB of ram.