Fantastic! I'm sorry I couldn't find that JIRA before and for getting you to track it down.
Yup, I noticed that for the docvalues with the ordinal map and I'm definitely leveraging all that but I'm hitting the terms limit now and that ends up pushing me over. I'll see about giving Zing/Azul a try. From all my readings using theUnsafe seemed a little sketchy ( http://mishadoff.com/blog/java-magic-part-4-sun-dot-misc-dot-unsafe/) so I'm glad that seemed to be the point of contention bringing it in and not anything else. Thank you very much for the info, Phil On Thu, Jun 2, 2016 at 6:14 PM, Erick Erickson <erickerick...@gmail.com> wrote: > Basically it never reached consensus, see the discussion at: > https://issues.apache.org/jira/browse/SOLR-6638 > > If you can afford it I've seen people with very good results > using Zing/Azul, but that can be expensive. > > DocValues can help for fields you facet and sort on, > those essentially move memory into the OS > cache. > > But memory is an ongoing struggle I'm afraid. > > Best, > Erick > > On Wed, Jun 1, 2016 at 12:34 PM, Phillip Peleshok <ppeles...@gmail.com> > wrote: > > Hey everyone, > > > > I've been using Solr for some time now and running into GC issues as most > > others have. Now I've exhausted all the traditional GC settings > > recommended by various individuals (ie Shawn Heisey, etc) but neither > > proved sufficient. The one solution that I've seen that proved useful is > > Heliosearch and the off-heap implementation. > > > > My question is this, why wasn't the off-heap FieldCache implementation ( > > http://yonik.com/hs-solr-off-heap-fieldcache-performance/) ever rolled > into > > Solr when the other HelioSearch improvement were merged? Was there a > > fundamental design problem or just a matter of time/testing that would be > > incurred by the move? > > > > Thanks, > > Phil >
