Rob, An XDMP-LISTCACHEFULL exception means that a term list needed for a given query couldn't fit into a list cache partition on one of the hosts involved in the query.
I would start by upgrading to the latest 4.1-x release (currently 4.1-8.3), since newer releases sometimes improve the efficiency of cache memory utilization. If an upgrade doesn't fix the problem, then you can pursue several options. You can rewrite the query to omit frequently-occuring terms, since these produce the largest term lists. If the exception happens every time, then you could reduce the number of list-cache partitions, increase the list-cache size, or both. If the exception happens only when concurrent load is high, you might consider reducing the number of application server threads. Another point to consider is the use of positions. If position-aware indexes are enabled, terms lists will be larger than otherwise. If you have positions enabled but don't use them, then disabling positions and allowing the database to reindex may resolve the issue. -- Mike On 10 Jan 2011, at 08:43 , Whitby, Rob, Springer Healthcare wrote: > Hi all, > > I've asked this before (way back in 2009) but never got anywhere. > Unfortunately the problem has come back where our cluster is getting > XDMP-LISTCACHEFULL errors (running 4.1-3). After reading "Inside MarkLogic > Server" by Jason Hunter I'm considering altering the cache sizes, but it > doesn't give any detail about how to calculate the optimal sizes and I can't > find any more information elsewhere. > > What are the possible causes of list cache full? > How should cache sizes be calculated for a particular e or d-node instance? > what factors are relevant? > > Thanks for any help or pointers in the right direction! > Rob > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
