[Deploying Sakai] database load in 2.9

[Matthew Jones]

Hi Omer,

That Java option was added about a year ago to Michigan production, I
believe that they were still running with it, at least when I left they
were. I did a good amount of research and found that the newer Oracle
drivers used /dev/random by default, but couldn't find why they changed.
The /dev/random is 'more random' but relies on a constant source of entropy
being generated by the system. On a active desktop this is generated by
mouse movements, microphone, keyboard but it is unlikely on a headless
server unless you have some processes or hardware setup to gather entropy.
The /dev/urandom is 'pseudo random' because it could potentially be
predicted. Though if someone is in your system and able to predict the
random numbers then you've got more problems. :)

The /dev/urandom is both fast and non-blocking (won't wait if there is no
entropy). I don't believe we were able replicate in load a difference with
or without the option, /dev/urandom was better overall, the default option
in previous drivers, recommended by the linux man page for everything other
than GPG/SSH keys [1], and recommended on oracle guides for weblogic [2] so
we just went with it. :)

[1] http://linux.die.net/man/4/urandom
[2] http://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmrand.html

On Thu, Sep 13, 2012 at 10:40 PM, Omer A Piperdi <omer at rice.edu> wrote:

>  We have disabled portal chat. We are recently seeing connection timed out
> error like below..
>
> java.sql.SQLRecoverableException: IO Error: Connection timed out
>         at
> oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1065)
>         at
> oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1329)
>         at
> oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3584)
>         at
> oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3665)
>         at
> oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper.java:1352)
>         at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:102)
>         at
> org.sakaiproject.db.impl.BasicSqlService.dbWriteCount(BasicSqlService.java:1247)
>         at
> org.sakaiproject.db.impl.BasicSqlService.dbWrite(BasicSqlService.java:1143)
>         at
> org.sakaiproject.db.impl.BasicSqlService.dbWrite(BasicSqlService.java:1059)
>         at
> org.sakaiproject.event.impl.UsageSessionServiceAdaptor$ClusterStorage.closeSession(UsageSessionServiceAdaptor.java:981)
>
> Also we have seen one of our app. server starts closing the sessions on
> other servers as orphan sessions and it stopped writing to sakai_event
> table.. We are not sure whether it is an issue with /dev/random on app.
> server. We plan to add '-Djava.security.egd=file:/dev/urandom' option at
> Tomcat startup.
>
> Thanks
> Omer
>
>
>
> On 9/13/2012 6:35 PM, Sam Ottenhoff wrote:
>
> Are any other schools on 2.9.x like Rice willing to share info?  Have you
> enabled new features that are disabled by default like portal chat?  My
> assumption is that 2.9 like 2.8 (with optional features disabled) would
> represent continued performance improvement.
>
>  The only major performance improvement that has been merged since
> Rutgers migrated to 2.9.x is KNL-934 (authz query improvements from VT as
> discussed at the conference TCC meeting).
>
>  --Sam
>
> On Wed, Sep 12, 2012 at 8:02 AM, Hedrick Charles <hedrick at rutgers.edu>wrote:
>
>> We had a database performance problem the first week in Sept. Last year
>> our database server ran 10 - 20% load, now and then up to 30%. This year it
>> was doubt that. 60% average indicates we don't have enough to handle peaks,
>> and in fact user performance was bad.
>>
>> This wasn't such a big deal, because I had a new server ready. I just
>> accelerated moving it into production. It's possible that something about
>> our load has changed, but it could also indicate a greater database load
>> for 2.9.
>>
>> _______________________________________________
>> production mailing list
>> production at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/production
>>
>> TO UNSUBSCRIBE: send email to
>> production-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>
>  !DSPAM:2294,50526db4128426909914249!
>
> _______________________________________________
> production mailing listproduction at collab.sakaiproject.orghttp://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org
>  with a subject of "unsubscribe"
>
> !DSPAM:2294,50526db4128426909914249!
>
>
>
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to
> production-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/20120913/31aaa4b2/attachment-0001.html