Hi Aaron, here there is some information about the "insanity count": http://wiki.apache.org/solr/SolrCaching#The_Lucene_FieldCache
As for the SUBREADER type, the javadocs say: "Indicates an overlap in cache usage on a given field in sub/super readers." 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). Tomás On Wed, Sep 19, 2012 at 3:16 PM, Aaron Daubman <daub...@gmail.com> wrote: > Hi all, > > In reviewing a solr instance with somewhat variable performance, I > noticed that its fieldCache stats show an insanity_count of 1 with the > insanity type SUBREADER: > > ---snip--- > insanity_count : 1 > insanity#0 : SUBREADER: Found caches for descendants of > ReadOnlyDirectoryReader(segments_k > _6h9(3.3):C17198463)+tf_normalizedTotalHotttnesss > 'ReadOnlyDirectoryReader(segments_k > > _6h9(3.3):C17198463)'=>'tf_normalizedTotalHotttnesss',float,org.apache.lucene.search.FieldCache.NUMERIC_UTILS_FLOAT_PARSER=>[F#1965982057 > 'ReadOnlyDirectoryReader(segments_k > > _6h9(3.3):C17198463)'=>'tf_normalizedTotalHotttnesss',float,null=>[F#1965982057 > > 'MMapIndexInput(path="/io01/p/solr/playlist/a/playlist/index/_6h9.frq")'=>'tf_normalizedTotalHotttnesss',float,org.apache.lucene.search.FieldCache.NUMERIC_UTILS_FLOAT_PARSER=>[F#1308116426 > ---snip--- > > How can I decipher what this means and what, if anything, I should do > to fix/improve the "insanity"? > > Thanks, > Aaron >
