[
https://issues.apache.org/jira/browse/SOLR-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17777419#comment-17777419
]
Kevin Risden commented on SOLR-17040:
-------------------------------------
I chatted a bit w/ Alex on Slack and found that async profiler with lock has
some contention which is why the profile changes so much.
There are 2 improvements that can be done to make the lock overhead much smaller
* Build async-profiler from main branch -
https://github.com/async-profiler/async-profiler#building due to
https://github.com/async-profiler/async-profiler/issues/805
* use lock=10ms instead of the default for example
{code:java}
./jmh.sh -prof
async:libPath=/Users/risdenk/repos/async-profiler/build/lib/libasyncProfiler.dylib\;output=jfr\;event=cpu\;alloc\;lock=10ms\;dir=/Users/risdenk/Downloads/profile-results-main
-f 1 -r 300s -to 450s CloudIndexing -p nodeCount=1 -p numShards=1 -p
numReplicas=1 -jvmArgsAppend -Dsolr.http1=true
{code}
This gets the same lock screenshot as Alex, but without the overhead. The
results on main were w/ and w/o lock profiling:
without
{code:java}
./jmh.sh -f 1 -r 300s -to 450s CloudIndexing -p nodeCount=1 -p numShards=1 -p
numReplicas=1 -jvmArgsAppend -Dsolr.http1=true
Benchmark (nodeCount) (numReplicas) (numShards) (preGenerate)
(useSmallDocs) Mode Cnt Score Error Units
CloudIndexing.indexDoc 1 1 1 50000
true thrpt 4 28676.469 ± 1536.750 ops/s
CloudIndexing.indexDoc 1 1 1 50000
false thrpt 4 1497.521 ± 531.661 ops/s
{code}
w/ lock profiling lock=10ms and using main async-profiler
{code:java}
./jmh.sh -prof
async:libPath=/Users/risdenk/repos/async-profiler/build/lib/libasyncProfiler.dylib\;output=jfr\;event=cpu\;alloc\;lock=10ms\;dir=/Users/risdenk/Downloads/profile-results
-f 1 -r 300s -to 450s CloudIndexing -p nodeCount=1 -p numShards=1 -p
numReplicas=1 -jvmArgsAppend -Dsolr.http1=true
Benchmark (nodeCount) (numReplicas) (numShards)
(preGenerate) (useSmallDocs) Mode Cnt Score Error Units
CloudIndexing.indexDoc 1 1 1
50000 true thrpt 4 28191.444 ± 1677.095 ops/s
CloudIndexing.indexDoc 1 1 1
50000 false thrpt 4 1458.417 ± 513.807 ops/s
{code}
The locks are the same:
!Screenshot 2023-10-19 at 13.52.22.png!
The interesting one to me is the amount of objects being generated... 1.2TB of
byte[] from FastOutputStream
!Screenshot 2023-10-19 at 13.55.54.png!
> UpdateLog refactor to use read/write locks
> ------------------------------------------
>
> Key: SOLR-17040
> URL: https://issues.apache.org/jira/browse/SOLR-17040
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Alex Deparvu
> Assignee: Alex Deparvu
> Priority: Major
> Attachments: Screenshot 2023-10-19 at 13.52.22.png, Screenshot
> 2023-10-19 at 13.55.54.png, jfr-locks-main.png, jfr-locks-patch.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Proposing a change to refactor the UpdateLog from all `synchronized (this)`
> blocks to read/write locks.
> Will post some benchmark results for evaluation if this is a useful change or
> not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
