Sun T2000 and mpstat, mostly idle

Question

I am running a test on the Sun T2000
mpstat shows that most of the cores are idle.
I have run my test with both writes to disk as well as running completely in memory and the %idle stays about the same.
I had read in Charles Lamb's blog, that he had been able to get a benchmark called JESearchRate, running at 100% utilization.
http://blogs.oracle.com/charleslamb/discuss/msgReader$11
I searched for this benchmark but could not find it. Is it available, so that I can see if it is something about the T2000 or the test of my BDB JE application?

Answer 1

A few ideas come to mind; as always, whether they result in improvement for you is application dependent. They're in roughly the order that I'd try.
You mention that you are using txnWriteNoSync mode. This means that that the JE will issue a system write call for each write operation, but won't execute the fsync. Switching over to txnNoSync mode should show another level of improvement, because operations will not issue the write call, but there will be a corresponding decrease in durability.
Along the theme of trading off durability for performance, you may want to investigate the deferred-write mode that can be set through DatabaseConfig.setDeferredWrite. However, deferred-write mode doesn't support transactional use, and it seems that you are using transactions.
Even in txnNoSync mode, JE still issues write calls as the log write buffer fills up, and fsync calls as the log flips over to a new file. If writes and fsyncs are a bottleneck, you can increase throughput by increasing the log write buffer size and the log file size. Log write buffer size can be manipulated through adjusting je.log.bufferSize, je.log.totalBufferBytes, and je.log.numBuffers. Be sure to verify that you indeed made them larger by dumping environment stats and looking at EnvironmentStats.getNLogBuffers and getNBufferBytes().
Log file size is more straightforward to increase, through je.log.fileMax. You can inspect your logs to verify that the size configuration change took effect.
At the moment, we don't have much to offer for write operations if the bottleneck is latch contention on the btree rather than on the logging system. As you observed, the shared latch setting doesn't do anything for writes. We know that we could do more tuning work to use shared latches in more write paths, especially for operations such as deletes and modifies, but we haven't gotten to that work yet.
Another route to go to reduce contention points is to use multiple environments, if it suits your application. That runs afoul of some other issues, such as the fact that currently a cache is configured per environment, and the use of multiple environments in a single process requires some static division of memory that may not be optimal. (We're paying attention to the fact that we've heard this use case from an increasing number of users!).
Regards,
Linda