In MarkLogic, what could cause an XDMP-EXPNTREECACHEFULL exception when reading a single document?

Viewed 55

Although I'm aware it is very much not best practice, we have a document in our MarkLogic database that represents a fairly large table of records: c. 15,000 sibling elements, each of which has ten attributes. Total size as XML is less than 5MB.

<table id="large-table">
  <entry id="1" col1="a" col2="b"/>
  <entry id="2" col1="c" col2="d"/>
  ...
</table>

We're not doing anything complicated with this data, just reading it in and out as a whole document, quite infrequently, and have not yet got around to splitting it out. This has been working fine for several months. In one environment, this is still working totally fine. In a second environment, after a recent update to the document, we are finding that any time ML tries to read it once or twice, we get an XDMP-EXPNTREECACHEFULL error. Any read seems to have the same effect, whether it's the whole document doc("large-table.xml"), or some part of it /table[@id="large-table"]/@id, or getting it via a REST endpoint (which internally comes down to a cts:search)

I have read in the documentation that the expanded version of the data which ML works with is often several times the size of the raw XML, but we have 4GB 8GB of tree cache (over 6 partitions, automatic cache sizing is enabled), and this is only a 5MB file. It seems like we should have enough cache, even if ML has to replace some of what is currently there.

We have tried deleting and reloading the document, clearing the cache at each stage.

  • What configuration (or indexing?) details should we be looking at to work out why this document can be read in one environment and not another?
  • Is this simply an unreasonable number of nodes in a document?


Edited: our expanded tree cache is 8GB, not 4GB

1 Answers

If you're using 6 partitions (quite a high number for such a small memory system) then the cache partition in which that document must fit is only 666 MB.

The expanded tree cache is used not just for holding the document but also holding the response you're building. Are you simply returning the document or doing some processing and construction based on the document which might also be filling the cache?

Concurrent requests will also each require their space in the cache. This may be why one environment is running out of cache space more than another.

What happens if you change your partition count to 1 or 2?

Related