use threadlocal random generator to avoid contention#359
Conversation
|
@eivanov89 Nice! I will take a look |
|
@apavlo |
apavlo
left a comment
There was a problem hiding this comment.
I am trying to decide if we should just drop com.oltpbenchmark.util.RandomGenerator and replace it with ThreadLocalRandomGenerator. We can just replace that implementation with the new one (using the same name).
I don't think there will be an non-determinism issue...
|
@apavlo it seems that we need your approval to run the workflow. |
|
@apavlo ping |
|
@eivanov89 Thanks for poking me. I will look at this in more detail later this week. |
|
@eivanov89 Let's have your RNG class replace the existing one. Can you do this? |
@apavlo Sure, I can try to do it next week. |
@apavlo I'm sorry for a long delay. Here is the updated pull request. |
Hi,
I noticed a very high CPU consumption, when import initial TPC-C data. According the attached flamegraph all threads are in
TPCCUtil:::randomStr. Because of util.RandomGenerator there is a contention. This patch uses thread local random generator, which helps to avoid contention and dramatically reduces CPU consumption.