[
https://issues.apache.org/jira/browse/HBASE-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969806#action_12969806
]
stack commented on HBASE-3322:
------------------------------
This JVM has -XX:+UseMembar set to get around lost notifications on outstanding
waits (default is false, XX:-UseMembar, I believe -- can't find the random page
written by a random russian that says this at the mo). I went looking for
corresponding SUN bug. I found this
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6822370 which suggests the
workaround of +UseMembar though the bug is in explicit locations, found on
solaris, for concurrent locks rather than synchronized it seems, and fixed in
u18 (Sun JVM is currently at u23).
I read this interesting note in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6546278, a problem found in
the 'psuedo memory barrier code'.
"We verified this by attempting to use the reinstated -XX:+UseMembar
option. This did appear to clear the problem, however the overall
performance of the system was not acceptable with this option invoked
since it uses a true memory barrier instruction to synchronized the
multiple processors."
> HLog sync slowdown under heavy load with HBASE-2467
> ---------------------------------------------------
>
> Key: HBASE-3322
> URL: https://issues.apache.org/jira/browse/HBASE-3322
> Project: HBase
> Issue Type: Bug
> Components: io, regionserver
> Affects Versions: 0.90.0
> Reporter: Jonathan Gray
> Priority: Blocker
> Fix For: 0.90.0, 0.92.0
>
>
> Testing HBASE-2467 and HDFS-895 on 100 node cluster w/ a heavy increment
> workload we experienced significant slowdown.
> Stack traces show that most threads are on HLog.updateLock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
