https://linen.dev logo
Join Slack
Powered by
This message was deleted.
# troubleshooting
s
This message was deleted.
a
If you can stack traces or flame graph, while this is happening, those stack traces will be useful.
there is also this trick to find out which java thread is consuming high CPU - https://backstage.forgerock.com/knowledge/kb/article/a48313100
o
Ok thanks, I will have a look. Base on your experience, is it a normal CPU usage for a coordinator ??
r
for my very small cluster, it's usually (< 100m) I think it will matter how many segments you have publising/unpublishing at the same time
d
It is not normal to be consuming that much CPU. It is likely that some of Coordinator’s background threads are spinning. I have seen that before. We usually just kill the leader when that happened.
o
After investigation, it seems to be due to a request from Brokers to get the list of segments... We have ~100k segments on the system but a very large number of columns in each (3000).
Is there any way to optimize that ? It seems that the Brokers is always asking to the coordinators the list of segments...
I didn't see any poll duration/frequency that can be configure
a
druid.sql.planner.metadataSegmentPollPeriod
can be used to control the frequency of polling
default is a minute
how many brokers do you have btw?
o
we have 4 brokers
you mean that each brokers will do the same ? We can try to reduce the number of broker if yes
Yes it is 1m if 
metadataSegmentCacheEnable
is enable but by default no. Is it recommended to activate that
a
oh. yes. I think you should enable this.
d
question, is this cache stored in RAM or disk?
a
RAM
o
Good seems to be very better... Both Brokers and Coordinators CPU usage decrease a lot
Open in Slack
PreviousNext
Powered by