Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 42854 invoked from network); 25 Dec 2009 22:14:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Dec 2009 22:14:59 -0000 Received: (qmail 28834 invoked by uid 500); 25 Dec 2009 22:14:57 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 28752 invoked by uid 500); 25 Dec 2009 22:14:56 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 28742 invoked by uid 99); 25 Dec 2009 22:14:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Dec 2009 22:14:56 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tsuraan@gmail.com designates 74.125.92.26 as permitted sender) Received: from [74.125.92.26] (HELO qw-out-2122.google.com) (74.125.92.26) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Dec 2009 22:14:48 +0000 Received: by qw-out-2122.google.com with SMTP id 5so364244qwi.53 for ; Fri, 25 Dec 2009 14:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=FNACl1eRLOnkRjYnn8ct4bG4WJs4c2S++MyduwsoKJw=; b=HIKIIOYsQYnHP+eRCrlAulc/ceWQcJorMUyFUW437zfuMMuDNy0TKZOH8Irr0DRpKl shbrg4Ck8zHL4gbtKEbnitjS4fx92XoZMlvaxWSOPPbVNlyKeCu5xlrcz+bL3+4yNUWQ /zk8uy3TaoczoGuLAUeOB2WqmTDrrlOC7VaXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=w/CYXXxHjxuEWjRCaamOJHAxs1FqF2+H/Hmx8iWkgLNoHOR1X7k1W1MZ+fwA/oExuR 56G37Z/H1yTOIqBBlOxg1FCvKh/PPRiPsk2czNte26FyRzqAo+r3Lfat+d6f2SRNW1aP rBVtokGXWcfMI5a9kdkx/NH06rmliWCgdL0hs= MIME-Version: 1.0 Received: by 10.229.15.203 with SMTP id l11mr5564504qca.43.1261779267965; Fri, 25 Dec 2009 14:14:27 -0800 (PST) In-Reply-To: <9ac0c6aa0912250336m1c649cv6c883bddd2f43c02@mail.gmail.com> References: <20090610122347.GB5557@kopfschmerz.zuhause> <9ac0c6aa0906100540q41d1aa4fq2910521623b2edc3@mail.gmail.com> <84fb38e30912232032v75ba4616p92ce5eeaff626092@mail.gmail.com> <9ac0c6aa0912250336m1c649cv6c883bddd2f43c02@mail.gmail.com> Date: Fri, 25 Dec 2009 16:14:27 -0600 Message-ID: <84fb38e30912251414v438c9a86h6b05ebeb8f91a705@mail.gmail.com> Subject: Re: Lucene memory usage From: tsuraan To: java-user@lucene.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org > Have you tried setting the termInfosIndexDivisor when opening the > IndexReader? EG a setting of 2 would load every 256th term (instead > of every 128th term) into RAM, halving RAM usage, with the downside > being that looking up a term will generally take longer since it'll > require more scanning. The problem that I have with doing this is I don't know how to get an estimate of how much RAM a given index will need. I'm generally searching on a few dozen indices of different sizes and compositions; if I run out of RAM, I can increment a universal index divisor and re-open all my indices, but I don't know of a more elegant way to handle memory limitations. Is there a call that I could do prior to the index being read to determine what divisor would be reasonable? For example, suppose I want to constrain Lucene to using 1GB per million lucene documents in an index. Is there a nice way to do that? --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org