I wonder if you have a explicitly configured merge policy? In Solr 1.4
ie. Lucene 2.9 LogMergePolicy was the default but in 3.5
TieredMergePolicy is used by default. This could explain the
differences segment wise since from what I understand you are indexing
the same data on 1.4 and 3.5?
simon
On Wed, Nov 30, 2011 at 7:42 PM, Mikhail Khludnev
<mkhlud...@griddynamics.com> wrote:
> Hello,
>
> I spot the difference in the number of segments (4 vs 14). For me it
> explains the increased query time, and cpu load, especially because you
> don't use utilize filters via fq=, only q= in your queries.
>
> The first thing you need is make the length of segment chains the same. The
> first clue is try to optimize (I'm sorry. forceMerge() of course) your
> index. If it helps, you'll need to get why your index was optimised but
> isn't optimized now.
>
> And, more statistics from both of your indexes will be really useful:
> num/maxDocs;numTerms;optimized;hasDeletions.
>
> Also I spot that you have deep paging use-case, so you should get some
> benefits from recent 3.5 improvements. Please let me know how it is.
>
>
> On Wed, Nov 30, 2011 at 12:07 PM, Pawel Rog <pawelro...@gmail.com> wrote:
>
>> reader
>> solr 1.4
>> reader : SolrIndexReader{this=8cca36c,r=ReadOnlyDirectoryReader@8cca36c
>> ,refCnt=1,*segments=4*}
>> readerDir : org.apache.lucene.store.NIOFSDirectory@
>> /data/solr_data/itemsfull/index
>>
>> solr 3.5
>> reader : SolrIndexReader{this=3d01e178,r=ReadOnlyDirectoryReader@3d01e178
>> ,refCnt=1,*segments=14*}
>> readerDir : org.apache.lucene.store.MMapDirectory@
>> /data/solr_data_350/itemsfull/index
>>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Developer
> Grid Dynamics
> tel. 1-415-738-8644
> Skype: mkhludnev
> <http://www.griddynamics.com>
> <mkhlud...@griddynamics.com>
