By charles.lamb on September 2, 2009 2:38 PM
I've added a new entry to the BDB JE FAQ regarding JVM parameters for large cache sizes.
Here's the text of it:
What JVM parameters should I consider when tuning an application with a large cache size?
If your application has a large cache size, tuning the Java GC may be necessary. You will almost certainly be using a 64b JVM (i.e. -d64), the -server option, and setting your heap and stack sizes with -Xmx and -Xms. Be sure that you don't set the cache size too close to the heap size so that your application has plenty of room for its data and to avoided excessive full GC's. We have found that the Concurrent Mark Sweep GC is generally the best in this environment since it yields more predictable GC results. This can be enabled with -XX:+UseConcMarkSweepGC.
Best practices dictates that you disable System.gc() calls with -XX:-DisableExplicitGC.
Other JVM options which may prove useful are -XX:NewSize (start with 512m or 1024m as a value), -XX:MaxNewSize (try 1024m as a value), and -XX:CMSInitiatingOccupancyFraction=55. NewSize is typically tuned in relationship to the overall heap size so if you specify this parameter you will also need to provide a -Xmx value. A convenient way of specifying this in relative terms is to use -XX:NewRatio. The values we've suggested are only starting points. The actual values will vary depending on the runtime characteristics of the application.
You may also want to refer to the following articles:
* Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning
* The most complete list of -XX options for Java 6 JVM
* My Favorite Hotspot JVM Flags
By charles.lamb on September 2, 2009 6:41 PM
A user has seen an IOException("Incorrect function") while performing an fsync in Windows 7 (as yet, unreleased) using JE 3.3.x. We have good reason to believe that this is a bug, or at least a change in behavior, in Windows 7's IO as the same program does not exhibit this behavior under Windows XP. In fact, we have never seen this exception ("Incorrect function") before.
We know of a workaround for the bug which we can give you if you run into this under Windows 7.
If you do run into this, we'd be grateful if you could give us your test case so that we could try to reproduce it on our own machines.
You can contact us on the OTN forum or via email (charles.lamb @ 0racle.com)
Thanks.
Charles Lamb
By charles.lamb on September 14, 2009 11:57 AM
Here is the press release for the latest BDB ("core") and BDB XML releases.
eWeek also has an article about this.
By charles.lamb on September 17, 2009 12:33 PM
My colleague Tao Zhang has been working on a
jconsole plugin which will let you monitor Berkeley DB Java Edition stats in real time. This will be especially useful for helping our customers debug performance issues. We're all really excited about this new feature which will be available in JE 4.0 (the corporate lawyers will only let me say "GA in CY 10"). I want to share some screen shots of this.
Here's a picture of the plugin. Note the two new tabs ("JE Statistics" and "JE Replicated Statistics").
The plugin allows you to log statistics to a csv file at a specified interval. It also lets you graph stats in real time:
By charles.lamb on September 22, 2009 7:10 AM
Three of us were working on a customer crisis late last night. The customer had a running environment which had some sort of transient state "issues". We were able to debug this live because they had the foresight to incorporate BeanShell into their system. This allowed us to look at lots of state and get a pretty good idea of what was going on. I strongly recommend taking a look at this library for use as a debugging tool, especially for deployed systems.
By charles.lamb on September 30, 2009 11:10 AM
In a previous blog entry I wrote that JE worked on Android but that the DPL didn't work because of a lack of support for various methods (e.g. Class.getAnnotations()) in the Dalvik JVM.
I have verified that the Android 1.5 (and presumably recently released 1.6) SDK supports JE and DPL. JE/DPL on Android adds a major chunk of infrastructure to the Android platform in that a pure Java transactional POJO datastore is now available.
You can expect to see stepped up support of JE on Android in the near future. For instance, we plan on making je-android.jar libraries available so that developers won't have to compile the JE src under Dalvik.
