[Deploying Sakai] [Building Sakai] Solaris Architecture Affects Performance?

[mizematr at notes.udayton.edu]

That's interesting, we were focused only on the application server, but it 
sounds like you're even planning to change your Oracle servers.  Thanks 
very much for sharing that with me, I will pass it along to our DBA.
---------------------------------------------------------------------------
Matt Mize, Systems Administrator
 - Pay no attention to the man in the back office....
Matt.Mize at notes.udayton.edu
(937) 229-1024

UDit Department, University of Dayton
300 College Park, Dayton, OH, 45469-1302



"R.P. Aditya" <rpaditya at umich.edu> 
Sent by: sakai-dev-bounces at collab.sakaiproject.org
01/27/10 03:44 PM

To
sakai-dev at collab.sakaiproject.org
cc
production at collab.sakaiproject.org
Subject
Re: [Building Sakai] Solaris Architecture Affects Performance?






Hi Matt,

On 2010-01-26, mizematr at notes.udayton.edu <mizematr at notes.udayton.edu> 
wrote:
> When we bought a box for our Sakai installation, we bought one of the 
> latest and greatest Solaris machines at the time, a Sun Blade T6300 and 
we 
> think this is the problem.  One of our Solaris admins found a report 
that 
> some applications cannot leverage the architecture of the T6300 and will 

> in fact run slower on the new architecture over the older architecture. 
We 
> setup two test machines on the older architectures and repeatedly loaded 
a 
> gradebook with 50 students and 44 columns, with these findings:
...
> Has anyone else seen behavior like this?
> Are we just missing a setting for Java on the sun4v chipset?
> Solaris schools, what kind of architecture are you running?

We (U of Michigan at Ann Arbor) use Sun CMT architecture machines for
just our Oracle DB servers (second generation now, T2000 to T5120). The
original motivation for CMT machines was that we were moving from Sun
v-series machines (so had to be 64-bit Sparc -- predates my being here
so I'm unclear on the original decision making) and our primary data
center was short on power, plus Sakai behaviour was essentially
OLTP. However single query response times on the Oracle on CMT machines
is proportional to clock speed (1.4Ghz processors vs. 3Ghz typically on
x86_64), but the DB portion of an "average" Sakai request represents
less than 1/6th of the total time so it is acceptable (for now).

Our application servers (running Apache and Tomcat) are x86_64 (Redhat
Linux) and were purchased based on the low price and having easy spares
on hand.

If we were to start from scratch, we would probably have chosen Oracle
on Linux on x86_64 is what is most used around here (the campus has a
site-wide license for Oracle so MySQL was not considered).

That said, some of the ways we manage with Oracle on the CMT machines is
to relagate long running queries to off-times or on "offline" copies and
make backups on the physical standby.

The slow single-thread performance of the CMT machines is a source of
frustration to our DBA to be sure, but the ops per watt (throughput)
performance of CMT is outstanding.

FWIW, we will likely see an architecture change as part of some DB
consolidation projects here, so CMT's days here are numbered too.

Hope that helps,
Adi

_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to 
sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of 
"unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20100128/2b65eab5/attachment.html