capistrant edited a comment on pull request #10287:
URL: https://github.com/apache/druid/pull/10287#issuecomment-732506253
> slightly surprised by `~10 secs` taken up by ... (snippet from
LogUsedSegments.java)
>
> ```
> public DruidCoordinatorRuntimeParams run(DruidCoordinatorRuntimeParams
params)
> {
> log.debug("Starting coordination. Getting used segments.");
>
> DataSourcesSnapshot dataSourcesSnapshot =
params.getDataSourcesSnapshot();
> for (DataSegment segment :
dataSourcesSnapshot.iterateAllUsedSegmentsInSnapshot()) {
> if (segment.getSize() < 0) {
> log.makeAlert("No size on a segment")
> .addData("segment", segment)
> .emit();
> }
> }
>
> // Log info about all used segments
> if (log.isDebugEnabled()) {
> log.debug("Used Segments");
> for (DataSegment dataSegment :
dataSourcesSnapshot.iterateAllUsedSegmentsInSnapshot()) {
> log.debug(" %s", dataSegment);
> }
> }
>
> log.info("Found [%,d] used segments.",
params.getUsedSegments().size());
>
> return params;
> }
> ```
>
> I am assuming DEBUG is already not enabled, so 10 secs are going in just
iterating over the segments and checking the size to print alert.
>
> I wonder if the slowness comes from use of `Stream` to create a flat list
of segments in ...
>
> ```
> public Iterable<DataSegment> iterateAllUsedSegmentsInSnapshot()
> {
> return () -> dataSourcesWithAllUsedSegments
> .values()
> .stream()
> .flatMap(dataSource -> dataSource.getSegments().stream())
> .iterator();
> }
> ```
>
> can you try to change the code to iterate over segments using simply
nested for loops in LogUsedSegments.java , e.g.
>
> ```
> for (ImmutableDruidDataSource ds :
snapshot.getDataSourcesWithAllUsedSegments()) {
> for (DataSegment segment : ds.getSegments()) {
> ......
> }
> }
> ```
>
> and see if it still takes `~10 secs` ? I am curious because if nested
for-loops fix the perf issue then we need to fix that as `
iterateAllUsedSegmentsInSnapshot()` is used in other places as well and could
be contributing extra `~10 secs` on each of those invocations.
I'm not sure if I will be able to test at same scale as our prod cluster
that is taking 10 seconds. but I can try in a lower env that has about 1/2 the
segments as prod to see what that looks like. will try tomorrow. Also, the
javadoc calls out that this will be knowingly slower than simple iteration of a
list. The use of this method is not that wide so it is probably not drastically
hurting perf across the coordinator. still worth taking a look at though.
`ImmutableDruidServer` has a similar method
`ImmutableDruidServer#iterateAllSegments`
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
