Return-Path: X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E7B02F310 for ; Mon, 1 Apr 2013 18:16:54 +0000 (UTC) Received: (qmail 67973 invoked by uid 500); 1 Apr 2013 18:16:51 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 67923 invoked by uid 500); 1 Apr 2013 18:16:51 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 67913 invoked by uid 99); 1 Apr 2013 18:16:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Apr 2013 18:16:51 +0000 X-ASF-Spam-Status: No, hits=4.4 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,NORMAL_HTTP_TO_IP,SPF_NEUTRAL,URI_HEX,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 216.139.236.26 is neither permitted nor denied by domain of feroz.kh2000@gmail.com) Received: from [216.139.236.26] (HELO sam.nabble.com) (216.139.236.26) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Apr 2013 18:16:45 +0000 Received: from ben.nabble.com ([192.168.236.152]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UMjHM-0000fF-Hk for solr-user@lucene.apache.org; Mon, 01 Apr 2013 11:16:24 -0700 Date: Mon, 1 Apr 2013 11:16:24 -0700 (PDT) From: feroz_kh To: solr-user@lucene.apache.org Message-ID: In-Reply-To: <513FC94E.6020602@elyograg.org> References: <1363024584158-4046391.post@n3.nabble.com> <513E2F13.6070905@elyograg.org> <1363126660832-4046802.post@n3.nabble.com> <513FC94E.6020602@elyograg.org> Subject: Re: Upgrade Solr3.5 to Solr4.1 - Index Reformat ? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_148745_21644535.1364840184538" X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_148745_21644535.1364840184538 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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... 0840 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+s472066n4046834h97@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 > . > 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. ------=_Part_148745_21644535.1364840184538--