How does Pinot, and specially server, behave diffe...
# troubleshooting
p
How does Pinot, and specially server, behave differently between online v/s offline tables?
m
Only difference is realtime tables also ingest data, apart from serving.
p
Do you think we might be running into OOM because we are not able to handle the rate at which we are ingesting data for the offline table as the inverted index are getting built in memory while we download the segment from S3?
m
If you are OOM, then then you didn’t do the capacity planning correctly
p
We scaled up the servers to have 8 cores, 64 GB memory and 32 GB heap. At the same time we disabled inverted index for now. We are now seeing much less segments getting into ERROR state. Even that is happening because servers failed to download the segment from S3. Is there any property with which we can configure the retries for downloading segments from S3?
I see this in the code
Copy code
public static final String RETRY_COUNT_CONFIG_KEY = "retry.count";
  public static final String RETRY_WAIT_MS_CONFIG_KEY = "<http://retry.wait.ms|retry.wait.ms>";
  public static final String RETRY_DELAY_SCALE_FACTOR_CONFIG_KEY = "retry.delay.scale.factor";
  public static final int DEFAULT_RETRY_COUNT = 3;
  public static final int DEFAULT_RETRY_WAIT_MS = 100;
  public static final int DEFAULT_RETRY_DELAY_SCALE_FACTOR = 5;
So do we just use
retry.count
or is there a prefix that needs to be added? Also do I need to add these to server conf or to the table config? I have not been able to figure out that part yet.
I think I figured it out. Would be great if someone with the knowledge can confirm it. I need to add prefix
pinot.server.segment.fetcher
to these properties, and they need to be added to the server config.
Ah forgot to add the
${protocol}
to the prefix as well. Since we are using s3, the correct prefix would be
pinot.server.segment.fetcher.s3.
We are able to bring a segment in Error state to Online state by using the reset segment api.