feat: configurable symbols partitioning

[kolesnikovae]

Resolves #3262

The PR adds a configuration option (-pyroscopedb.symbols-partition-label) to control how symbols are partitioned.

Currently, we infer the partition key based on the main binary mapping, aiming to create shared partitions for binaries with the same name. This helps optimize memory usage during writes when the same binary runs in different contexts. As a fallback, the service_name label value is used as the symbols partition key.

However, this approach is quite fragile and may result in poor performance during query or compaction operations.

[korniltsev]

lgtm.

I wonder if this can be a relabeling configuration instead of just one dimension.
it could allow different configurations per tenants
In addition it would allow to merge partitions between similar service_names (cortex-dev-001/compactor, cortext-dev-002/compactor)

[kolesnikovae]

I wonder if this can be a relabeling configuration instead of just one dimension.

Yes, it is supposed to be used in conjunction with relabeling rules. For example, you specify your label as symbols partition – __symbols_partition__ and use rules to build the value from other labels. I don't want to duplicate functionality given the existing mechanism could work fine here as is

it could allow different configurations per tenants

This is a service-level parameter, actually. Use of relabeling rules should allow for that.

In addition it would allow to merge partitions between similar service_names (cortex-dev-001/compactor, cortext-dev-002/compactor)

Yes, this can be solved with relabeling rules.

[korniltsev]

sorry, for some reason I did not think of using an existing relabeling rules

[knylander-grafana]

Should we add some doc for this?

[kolesnikovae]

@knylander-grafana Thanks for the reminder! I completely forgot to update the generated config docs. I think we're good for now and don't need anything more detailed at this point

[kolesnikovae]

I've tested the change in one of the dev environments and can confirm that a strict partition-service mapping will cause an increase in memory usage. This was expected, but I'm not sure if we want to allocate more memory / scale-out ingesters

In the meantime, I cannot say that it fully addresses the compaction performance issue.

[korniltsev]

can we try merging some of the partitions? for example mimir-dev-.* => mimir ?

[kolesnikovae]

can we try merging some of the partitions? for example mimir-dev-.* => mimir ?

That would work, but I'd like to avoid overly specific configurations

In the meantime, I cannot say that it fully addresses the compaction performance issue.

Now I'm sure that the environment was malfunctioning. I'm going to repeat the test under more reliable conditions