Hi Tomás,
> This probably means that you are using the same field for faceting and for
> sorting (tf_normalizedTotalHotttnesss), sorting uses the segment level
> cache and faceting uses by default the global field cache. This can be a
> problem because the field is duplicated in cache, and then it uses twice
> the memory.
>
> One way to solve this would be to change the faceting method on that field
> to 'fcs', which uses segment level cache (but may be a little bit slower).
Thanks for explaining what the sparse wiki and javadoc mean - I had
read them but had no idea what the implications were ;-)
We are not doing any explicit faceting, and this index is also
supposed to be a read-only, already-optimized, single-segment index -
both of these seem to indicate to (very unknowledgeable about this) me
that this could be more of a problem - e.g. what am I doing to cause
this since I don't think I need to be using segment-level anything
(should be a single segment if I understand optimization and RO
indicies) and I am not leveraging faceting?
Any pointers on where else to look for what might be causing this (one
issue I am currently troubleshooting is too-many-pauses caused by
too-frequent GC, so preventing this double-allocation could help)?
Thanks again,
Aaron
