See https://builds.apache.org/job/HBase-TRUNK/2362/
Akash:
Take a look at the following two possible replacements for CSLM:
https://github.com/mspiegel/lockfreeskiptree
https://github.com/nbronson/snaptree
About your test, I got advice from other expert:
- the JVM warm-up penalty is being accrued by the CSLM run
- Use thread.yield() to end a
Jonathan, 1000 threads is a bad application design. They will kill you even w/o
contention. In my opinion, over-usage of a *modern* Java concurrent framework
stuff w/o real understanding of a benefits is a major contributor to a poor
performance and poor scalability of a Java application.
I am not sure I would generally agree with this statement.
The linux kernel can easily handle 10.000's of threads (just need to keep
default stack small).
(there were tests done with 1m threads too).
Doing async IO is all the craze today (see node.js and friends), but that also
is not
There is nothing crazy with async I/O. Netty (which I presume is underlying
network library in a latest Hadoop) is totally async.
You can run 1000, 10,000 and may be more threads on Linux but performance
-wise this would sub-optimal decision.
With 20 ms time share, on 8 core CPU some threads
Hi,
Under some scenarios, we use the function of disable/enable HTable. But
currently, enable HTable using the random-assignment. We hope all the regions
show a better distribution, no matter how many regions and how many
regionservers.
So I suggest to add a choice of using round-robin
I think it makes sense.
Do you mind logging a JIRA ?
On Mon, Oct 24, 2011 at 8:15 PM, bijieshan bijies...@huawei.com wrote:
Hi,
Under some scenarios, we use the function of disable/enable HTable. But
currently, enable HTable using the random-assignment. We hope all the
regions show a better
On Mon, Oct 24, 2011 at 4:50 AM, Jonathan Gray jg...@fb.com wrote:
Very nice experiment, Akash. Keep getting your hands dirty and digging!
:)
I think your results might change if you bump the test up to 1000 threads
or so. 100 threads can still perform okay when there's a global lock but