Hi Shawn, I tried optimizing using this command...
curl ' http://10.7.233.54:8088/solr/update?optimize=true&maxSegments=10&waitFlush=true' And i got this response within secs... <?xml version="1.0" encoding="UTF-8"?> <response> <lst name="responseHeader"><int name="status">0</int><int name="QTime">840</int></lst> </response> Is this a valid response that one should get ? I checked the statistics link from /solr/admin page and it shows the number segments got updated. Would this be a good indication that optimization is complete ? At the same time - I even noticed the number of files in data/index directory hasn't reduced & all files are not updated. Since it took just couple of secs for the response(even with waitFlush=true) - i am doubting if optimization really happened , but details on statistics page shows me correct number of segments. On Tue, Mar 12, 2013 at 8:34 PM, Shawn Heisey-4 [via Lucene] < ml-node+s472066n4046834...@n3.nabble.com> wrote: > On 3/12/2013 4:17 PM, feroz_kh wrote: > > Do we really need to optimize in order to reformat ? > > The alternative would be to start with an empty index and just reindex > your data. That is actually the best way to go, if that option is > available to you. > > > If yes, What is the best way of optimizing index - Online or Offline ? > > Can we do it online ? If yes - > > 1. What is the http request which we can use to invoke optimization - > How > > long it takes ? > > 2. What is the command line command to invoked optimization - How long > this > > one takes ? > > The only way I know of to optimize an index that's offline is using > Luke, but it is difficult to find versions of Luke that work with > indexes after 4.0-ALPHA - the official Luke page doesn't have any newer > versions, and I have no idea why. Online is better. Solr 4.2 just got > released, you may want to consider skipping 4.1 and going with 4.2. > > There would be no major speed difference between doing it offline or > online. Whatever else the machine is doing might be a factor. I can > only make guesses about how long it will take. You say your index in > 3.5 is 14GB. I have experience with indexes that are 22GB in 3.5, which > takes 11 minutes to optimize. The equivalent index in 4.2 is 14GB and > takes 14 minutes, because of the extra compression/decompression step. > This is on RAID10, volumes with no RAID or with other RAID levels would > be slower. Also, if the structure of your index is significantly > different than mine, yours might go faster or slower than the size alone > would suggest. > > There is a curl command that optimizes the index in the wiki: > > > http://wiki.apache.org/solr/UpdateXmlMessages#Passing_commit_and_commitWithin_parameters_as_part_of_the_URL > > You would want to leave off the "maxSegments" option so it optimizes > down to one segment. Whether to include waitFlush is up to you, but if > you don't include it, you won't know exactly when it finishes unless you > are looking at the index directory. > > Thanks, > Shawn > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://lucene.472066.n3.nabble.com/Upgrade-Solr3-5-to-Solr4-1-Index-Reformat-tp4046391p4046834.html > To unsubscribe from Upgrade Solr3.5 to Solr4.1 - Index Reformat ?, click > here<http://lucene.472066.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4046391&code=ZmVyb3oua2gyMDAwQGdtYWlsLmNvbXw0MDQ2MzkxfDIwNzA2NTYxOTI=> > . > NAML<http://lucene.472066.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://lucene.472066.n3.nabble.com/Upgrade-Solr3-5-to-Solr4-1-Index-Reformat-tp4046391p4052969.html Sent from the Solr - User mailing list archive at Nabble.com.
