Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 60400 invoked from network); 31 Mar 2010 09:24:19 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 31 Mar 2010 09:24:19 -0000 Received: (qmail 27293 invoked by uid 500); 31 Mar 2010 09:24:18 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 27019 invoked by uid 500); 31 Mar 2010 09:24:18 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 27006 invoked by uid 99); 31 Mar 2010 09:24:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Mar 2010 09:24:16 +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: local policy) Received: from [194.172.26.33] (HELO MX1.aeb.de) (194.172.26.33) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Mar 2010 09:24:09 +0000 X-IronPort-AV: E=Sophos;i="4.51,340,1267398000"; d="scan'208";a="5157003" Received: from unknown (HELO S-HQMX6.pmbelz.de) ([10.237.5.6]) by MX1I.pmbelz.de with ESMTP; 31 Mar 2010 11:23:47 +0200 Received: from S-HQMX6.pmbelz.de ([fe80::c11d:7ab7:ed94:fb34]) by S-HQMX6.pmbelz.de ([fe80::c11d:7ab7:ed94:fb34%14]) with mapi; Wed, 31 Mar 2010 11:23:47 +0200 From: "Cech. Ulrich" To: "'users@jackrabbit.apache.org'" Date: Wed, 31 Mar 2010 11:23:46 +0200 Subject: Jackrabbit MemoryManagement Thread-Topic: Jackrabbit MemoryManagement Thread-Index: AcrQs94GCGr1/g3ATXig+fc7F0s02g== Message-ID: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Hello, I just running a mass test with some hundrets of thousends files (all have = 15 properties), very structured repo tree (no more than 2000 direct child n= odes!). Everything works fine so long, but I see a very slight increasing of used m= emory. Every document storage ends with a "session.save()", so there are no transi= ent changes anymore. Every 100 documents, I do a little "break" and call Sy= stem.gc(). I see, that the used memory is hold on a certain value (some kb more and le= ss) for a yet long time (about 30-60 min.), then there is an increase of so= me MB, holding for next 30.60 min and so on. I did not change any cache settings, so the cache should only the 16MB (def= ault values, if I look exactly). Is this perhaps the index, which consumes more and more memory? Is there a = setting to limit the maximum used memory? I would solve this, so that the s= ystem does not crash down with an OutOfMemoryException some days. Thanks for any hints/advices, Ulrich