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 0B98E419C for ; Thu, 2 Jun 2011 21:56:32 +0000 (UTC) Received: (qmail 92375 invoked by uid 500); 2 Jun 2011 21:56:28 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 92223 invoked by uid 500); 2 Jun 2011 21:56:28 -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 92191 invoked by uid 99); 2 Jun 2011 21:56:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Jun 2011 21:56:28 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of aserba@gmail.com designates 209.85.220.176 as permitted sender) Received: from [209.85.220.176] (HELO mail-vx0-f176.google.com) (209.85.220.176) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Jun 2011 21:56:22 +0000 Received: by vxa37 with SMTP id 37so1655429vxa.35 for ; Thu, 02 Jun 2011 14:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=BnA+pWrPAvwLI44ubqiSOoKDgnBjkjIiRjQd6vLI3rQ=; b=fDe2cs8IKoSE0T3Fl/hbzpOyu/p7jmoXmw6Czsdmt7H3X/m7uTsczF0opAn2OFgXHF UDBZi9zHBKAnqppXsQ2fuojIvb5l5W6efNy1zRBTKxeBoipPl5dC1evJ83w50HwnwbB9 6MfBWf/6qcPvgwL+MEb5oWe9XXcpmFr7wUcg8= 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:content-transfer-encoding; b=W7GwoT1mKWljblkqLF9oJ0e30s40v1bEjpaP58b1GHBpzHzfyasHREhWNSIYvnzA8H qBp2Kt/qlWzwOZPV+qXVljA+am9KFvIwGo+iBzX4vxb2PlI5C2kM2eZkL4lIu+L3FXnB 2ipMzOCo1sLb2ECAKrIx5Eul9S8qsV9YWvbCM= MIME-Version: 1.0 Received: by 10.52.97.232 with SMTP id ed8mr1718817vdb.84.1307051761379; Thu, 02 Jun 2011 14:56:01 -0700 (PDT) Received: by 10.52.162.226 with HTTP; Thu, 2 Jun 2011 14:56:01 -0700 (PDT) In-Reply-To: <772529952.20110602104550@ukr.net> References: <1387286856.20110531231829@ukr.net> <145339191.20110601191511@ukr.net> <4DE668FE.5080108@jhu.edu> <101380622.20110601193717@ukr.net> <4DE66FA2.5080005@jhu.edu> <1655376041.20110601201906@ukr.net> <4DE67E58.10105@jhu.edu> <1543945304.20110601213357@ukr.net> <772529952.20110602104550@ukr.net> Date: Fri, 3 Jun 2011 01:56:01 +0400 Message-ID: Subject: Re: Solr memory consumption From: Alexey Serba To: solr-user@lucene.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Commits are divided into 2 groups: > - often but small (last changed > info) 1) Make sure that it's not too often and you don't have commit overlapping problem. http://wiki.apache.org/solr/FAQ#What_does_.22PERFORMANCE_WARNING:_Overlappi= ng_onDeckSearchers.3DX.22_mean_in_my_logs.3F 2) You may also try to limit cache sizes and check if it helps. 3) If it doesn't help then try to monitor your app using jconsole * try to hit garbage collector and see if it frees some memory * browse solr jmx attributes and see if there'r any hints re solr caches usage, etc 4) Try to run jmap -heap -histo and see if there's any hints there 5) If none of above helps then you probably need to examine your memory usage using some kind of java profiler tool (like yourkit profiler) > Size: 4 databases about 1G (sum), 1 database (with n-gram) for 21G.. > I =A0don't =A0know any other way to search for product names except n-gra= m > =3D\ Standard text field with solr.WordDelimiterFilterFactory and generateWordParts=3D"1" generateNumberParts=3D"1" catenateWords=3D"1" catenateNumbers=3D"1" catenateAll=3D"1" splitOnCaseChange=3D"1" during indexing isn't good enough? You might want to limit min and max ngram size, just to reduce your index size.