I tried that search, without success :-( I suspect what Otis was trying to say was to question why you are optimising. Optimise was necessary under 1.4, but with newer Solr, the new TieredMergePolicy does a much better job of handling background merging, reducing the need for optimize. Try just not doing it at all and see if your index actually reaches a point where it is needed.
Upayavira On Wed, Dec 5, 2012, at 12:31 AM, Otis Gospodnetic wrote: > Hi, > > You should search the ML archives for : optimize wunder Erick Otis :) > > Is WAS really AWS? If so, if these are new EC2 instances you are > unfortunately unable to do a fair apples to apples comparison. Have you > tried a different set of instances? > > Otis > -- > Performance Monitoring - http://sematext.com/spm > On Dec 4, 2012 6:29 PM, "Sandeep Mestry" <sanmes...@gmail.com> wrote: > > > Hi All, > > > > I have recently migrated from solr 1.4 to solr 4 and have done the basic > > changes required for solr 4 in solrconfig.xml and schema.xml. I have also > > rebuilt the index set for solr 4. > > We run optimize every morning at 4 am and we keep the index updates off > > during this process. > > Previously, with 1.4 - the optimization used to take around 20-30 mins per > > shard but now with solr 4, its taking 6-8 hours or even more.. > > I have also tested the optimize from solr UI and that takes 6-8 hours too.. > > The hardware is saeme and, we have deployed solr under WAS. > > There ar 4 shards and every shard contains around 8 - 9 Gig of data and we > > are using master-slave configuration with rsync. I have not enabled soft > > commit. Also, commiter process is scheduled to run every minute. > > > > I am not sure which part I'm missing, do let me know your inputs please. > > > > Many Thanks in advance, > > Sandeep > >
