Skip to content

Avoid OOM on poison documents #73460

Open
@markharwood

Description

@markharwood

In examining an OOM heap dump from a 7.12 user it was apparent that the culprit was a rogue document that introduced 360k(!) new fields and had a bunch of TextFieldMapper objects held in o.e.index.mapper.ParseContext.InternalParseContext.dynamicMappers that together consumed 1.5GB of RAM of 2GB heap.

I know we have circuit breakers for numbers of fields in mappers but perhaps these objects are allocated during parsing before we test that condition?

Either way seems like we need some added robustness here.

Metadata

Metadata

Assignees

Labels

:Search Foundations/MappingIndex mappings, including merging and defining field types>bugTeam:Search FoundationsMeta label for the Search Foundations team in Elasticsearchpriority:criticalA label for assessing bug priority to be used by ES engineers

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions