Getting `druid.server.maxSize` out of the way

[KenjiTakahashi]

Currently, configuration needs to consist of something like this:

druid.segmentCache.locations=[{"path": "/home/indexCache", "maxSize": 100000000000}]
druid.server.maxSize=100000000000

As I understand, server.maxSize is usually (if not always) equal the sum of maxSize's inside locations. Perhaps it can be set to this sum by default, then?
Most people would then probably not have to set twice the same thing and if, for some reason, somebody wants a different value there, they can still override it manually.

If this makes sense, I think I could bake a PR to implement it.

[Having support for units other than bytes would be nice to have, as well. A separate change, though, I guess.]

[QiuMM]

+1

[gianm]

There is a use case for having it be different than the sums of the location sizes: let's say you have 3 locations, and each could hold up to 1TB, but you don't want to store more than 2TB on the entire server. This is pretty niche though. So I do think it makes sense for the default druid.server.maxSize to be the sum of the locations, and maybe a small set of people will use a different value.

[drcrallen]

One use case I can see some issues is if you have multiple disks which in aggregate have enough free space, but none individually does.

For example, lets say the free spaces for 10 disks were:

100MB, 100MB, 100MB, 100MB, 100MB, 100MB, 100MB, 100MB, 100MB, 100MB

The coordinator might think it can hold 1GB worth of segments, when in reality it can't hold any segment larger than 100MB.

((This might actually be a problem even in the current implementation))

I know I've been bitten by the "disk space has to be set twice" problem a few times. That and the kilobyte vs kibibyte... As this is designed, please be sure to call out any corner cases that may arise. Suggest limiting scope to "sum of disks" problem for now, and leaving measurement in bytes. Anything that is "not worse than current and better in at least these cases" is very welcome.

[FrankChen021]

This problem has been here so long :)

Since #10105 forces the configuration of druid.server.maxSize, I think it's better to eliminate this property.

@gianm In your example, if user wants limits the total size to 2TB, I think he should achieve that by reducing the size of locations.

@drcrallen in your example, whether druid.server.maxSize is dropped or not, the problem still exists. I think this is another problem. To solve that, maybe coordinator needs to know the max file size a historical can save a file. And that max file size is not a configured property but a dynamic runtime value depending on the left size of each locations

[gianm]

@gianm In your example, if user wants limits the total size to 2TB, I think he should achieve that by reducing the size of locations.

I think that's fair.

@drcrallen in your example, whether druid.server.maxSize is dropped or not, the problem still exists. I think this is another problem. To solve that, maybe coordinator needs to know the max file size a historical can save a file. And that max file size is not a configured property but a dynamic runtime value depending on the left size of each locations

It would have to be dynamically changing even within a single coordinator run. That level of communication between coordinators and historicals might end up being a lot of overhead. Maybe instead the historical could directly tell the coordinator about the size of each of its locations; then the coordinator would know on its own what max file size is supported. Alternatively we could do a hack like set maxsize to sum(locations) - (count(locations) - 1) * 5GB.

I do agree it is a separate problem, though, that we don't necessarily need to solve at the same time as getting rid of the need for druid.server.maxSize.