I don't know exactly how the local solr stuff currently works (it's not currently part of Solr), but it's possible to get worse memory performance if you're not careful. Solr and Lucene now do per-segment searching and sorting in a single index... and that means fieldcache entries populated at the segment level instead of the top level multireader. It's possible/probably that some elements of LocalSolr use a top-level reader and other elements use per-segment (via Lucene or Solr) for geo fields, thus doubling the memory footprint from before.
-Yonik http://www.lucidimagination.com On Mon, Aug 31, 2009 at 3:24 AM, Ilan Rabinovitch<i...@fonz.net> wrote: > Hello, > > We recently began migrating a few of our applications from 1.3 to 1.4 in > order to take advantage of the replication and performance improvements. > > > In practice however, we are noticing that our instances which make use of > LocalSolr have experienced some performance degradation from 1.3 to 1.4. > This mostly appears to be due to some dramatically different GC patterns > between the two despite using the same JDK, data set, and GC parameters, and > solr cache sizes. > > > Versions > ========== > LocalSolr: HEAD as of August 27 > Solr: 1.4-DEV from 6/10/09 > JDK: Sun Hotspot 1.6.0_14 > > > Has anyone else seen this type of behavior with Solr/LocalSolr queries? > > Some graphs of our results (transactions per second) between both versions > are available at the following link. While performance is relatively > similar when using UseParallelGC rather than UseConcMarkSweepGC, we do still > notice some relatively long pause times in 1.4 when compared with 1.3 during > GC windows. > > > https://dl.getdropbox.com/u/162474/performance.png > > > The queries run for this test make use of LocalSolr sorting and filtering > based on distances between 2 sets of lat/long coordinates. > > > We are currently using LocalSolr HEAD with 6/10/09 revision of Solr 1.4. > The reason we selected that revision was due to it being the revision that > LocalSolr was last released against. We do however plan to spend some time > this week testing newer builds of Solr 1.4 to see if similar behavior > exists. > > > > Regards, > Ilan > > > > > > -- > Ilan Rabinovitch > i...@fonz.net > >
