Trino Workers OOM: Configurable limit of the number of Iceberg table partitions is needed.

[vburenin]

I had a fun day today figuring out why Trino Workers (220GB of RAM each) are restarting with OOMs...

Well, apparently someone thought that using UUID for partitioning the Iceberg table was a good idea.
It is hard to prevent users from doing it.
Would be great to be able to limit the number of partitions can be written per one write operation or in general.

[raunaqmorarka]

You can lower iceberg.max-partitions-per-writer and task.max-writer-count to help with that.
More importantly, the query.max-memory-per-node limit should have been hit first and failed the query instead of crashing the worker. We shouldn't have to create new mechanisms to prevent OOMs.
Could you provide a heap dump or check yourself from the heap dump what part of the memory allocations is going untracked in the worker memory pools ?

[vburenin]

These values are already reasonable/relatively small. query.max-memory-per-node is set to 30GB.
It is definitely related either to a huge metadata size that Trino can't handle (tens of millions of files), or it is because trino can't initialize a lot of small parquet files.

Heap dump is not available and can't be retrieved :-|

[raunaqmorarka]

Wherever the memory usage comes from, if it is significant then it needs to be tracked in the memory pools.
Can you get a class histogram from JVM (add -XX:+PrintClassHistogram and run jmap -histo:live <pid> just before crash happens) ?

[vburenin]

The easiest way to reproduce is to create an iceberg table and partition it by UUID(just use uuid as a partition id) and put tons of records into it.

Oh and I completely forgot to mention Trino version etc. It is was the latest Trino 477 at the time, I see 478 was released recently.