The only entry in the Oracle documentation is found in the Oracle Application Server Performance Guide 10g Release 3 (10.1.3.1.0), Chapter 3 - Top Performance Areas where we say that:
"With the Sun 5.0 JVM, under some circumstances under heavy load, synchronization in an application can result in thread starvation. This may cause some requests for an application to appear hung or to timeout after a long time.
In 10g Release 3 (10.1.3.1.0) the parameter: -XX:AppendRatio=3 is specified by default for managed OC4J. For standalone OC4J, if you believe your installation has this problem, we recommend setting the JDK parameter: -XX:AppendRatio=3 to avoid this problem."
There is also a reference to the Sun JVM Bug Database entry 4985566 that describes the details of the problem.
However, there is a better description of the problem and the purpose in the Sun JVM Bug Database entry 6383015.
Here the purpose of the parameter is described as: "The VM option -XX:AppendRatio=N can be used to control how often an append is done rather than an append. If set to 0 then every enqueue will be an append and the observed behaviour will be 'fair' if desiring FIFO like ordering."
It then continues a bit down with: "In 1.5.0 the monitor queuing policy is 'mostly prepend', which is essentially LIFO except that every N queue additions are done as an append rather than a prepend. Prepending yields better throughput/performance by trying to allow the most recently blocked thread to run next in the expectation that it will still have a warm cache etc."
So, with this is mind we can go to the following conclusions:
- If the XX:AppendRatio parameter is unset in JDK 1.5 then the monitor queuing policy will be LIFO. This might cause some threads to be treated unfair, and lead to starvation.
- If the XX:AppendRatio parameter is set to 0 then the monitor queuing policy will be almost like FIFO, however 100% FIFO is not guaranteed as described in bug 4985566 above.
- If the XX:AppendRatio parameter is set to 3 then each 3:rd queue addition is done as an append rather than a prepend. This will take some advantage of the performance benefits using LIFO, but it will better ensure fairness trying to prevent thread starvation.
So, I hope this have given you a better understanding of what the XX:AppendRatio JVM Parameter does and why it is set by default when installing the Oracle Application Server 10.1.3.1+.
Hej Stellan,
SvaraRaderatack för den här blogartikel.. en klient fungerar jre 1.6 med oc4j 10.1.3.1 men nu kan man inte har AppendRatio för 1.6 (10), se :
http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=f84cce6c968086db981ed8735c3a?bug_id=6721093
- klienten har en fråga : Om man har jre 1.6, kan man ta bort AppendRatio utan ett problem med prestandan ? Jag har skapat en oracle doc-bug:7577385, men vad jad vill gärna kunna är : om AppendRatio existerar inte på 1.6(10) (den senaste) betyder man en andra parameter när man har oc4j , istället för AppendRatio ? - har Sun lagat trådproblemet i 1.6 ?
tack och många hälsningar,
nick.
:-)
Nick,
SvaraRaderaUnfortunately am I not too familiar with the internals of the JVM 6 version, and I haven’t found any good documents on this topic with respect to why the AppendRatio parameter has disappeared. There is a short notice in the Sun bug 6383015 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6383015):
“… The correct fix here is in the application however: if an application requires that different threads are guaranteed to make progress then it must program in those progression guarantees through the protocols that it implements. As noted with 6316090 also consider using some of the facilities in java.util.concurrent locks to achieve fair synchronization.”
Also, with Java SE 6 there are further enhancements in the java.util.concurrent package.
So, my guess (and it is only a guess) is that they put the AppendRatio in as a quick fix to solve some threading issues in the previous versions, but they have now removed it and it is up to each application developer to solve this problem using the java.util.concurrent package instead. For example, we have implemented the internal queues in BPEL 10.1.3.4 using this mechanism (documented in MetaLink note 601507.1).
So, I would say that there is no parameter to be used instead of AppendRatio, instead each developer have to solve threading issues using the java.util.concurrent package.
Cheers,
Stellan
Hi,
SvaraRaderaAfter spending 2 days on finding the parameter that causes the problem, I got to this post and the following comments that were very helpful. Thanks Stellan and Nick.
The referred documents don't seem to answer my question though. Is it better to use 1.6 u6 with AppendRatio, as it is already tested and as suggested by Oracle? Or I should remove the parameter and leave 1.6 u7+ take care of the problem?
Hi,
SvaraRaderaIf you have the option (time) you could do a test using both 1.6u6 and 1.6u7+ and perform a stress test of the application and see if there are any major differences, if not, going for the later version is often a better choice since they contains more bug fixes.
Take care,
Stellan