From derby-user-return-12985-apmail-db-derby-user-archive=db.apache.org@db.apache.org Wed Jul 21 03:46:29 2010 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 8715 invoked from network); 21 Jul 2010 03:46:28 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Jul 2010 03:46:28 -0000 Received: (qmail 8937 invoked by uid 500); 21 Jul 2010 03:46:28 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 8753 invoked by uid 500); 21 Jul 2010 03:46:25 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 8746 invoked by uid 99); 21 Jul 2010 03:46:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 03:46:25 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of david.vancouvering@gmail.com designates 209.85.214.172 as permitted sender) Received: from [209.85.214.172] (HELO mail-iw0-f172.google.com) (209.85.214.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 03:46:19 +0000 Received: by iwn38 with SMTP id 38so7068120iwn.31 for ; Tue, 20 Jul 2010 20:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=zBcoSv1F0vzmNCtx6hVzsTnMu0YUfz/BoTOdwL0CYgo=; b=oOsMcU/qUGOf8seKhGXVl9FTKlEKgxn7Crg6jJPqXUMenMzfrQpcZuZIcR5NkJsJmV y91MSNaWfhylXyOrSfniJc53pGsaX6DrSwi39zaat3AShgWFYSe/XNSRUv40IilqFiE/ 6V1EOP1DFF5avzNEbXlnQASHUz2RQBgWBH29I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=HWdXny2rcrCE7L3YIIQh6v+nKKKkvM/MuKNuHY2GEhJovO3yHjjhctISD6lo2vinmW rnSX3/NlLeeEu8ig49c+48Ho01n9n7LvgVPZ0PG/y2w4R3/I9jBD/v5abrjP6b7qrLyL QG3mr2ZL5AMso/bcvKMjy0MBERWXo7FbzZJFc= Received: by 10.231.158.203 with SMTP id g11mr8691981ibx.24.1279683898159; Tue, 20 Jul 2010 20:44:58 -0700 (PDT) MIME-Version: 1.0 Sender: david.vancouvering@gmail.com Received: by 10.231.199.68 with HTTP; Tue, 20 Jul 2010 20:44:38 -0700 (PDT) In-Reply-To: References: <4C465D5C.9050202@gmail.com> From: David Van Couvering Date: Tue, 20 Jul 2010 20:44:38 -0700 X-Google-Sender-Auth: mslcy7z96pnKUBtSPhcnLRtp2vw Message-ID: Subject: Re: Reducing memory footprint of embedded Derby To: Derby Discussion Content-Type: multipart/alternative; boundary=005045013bbe2cb34c048bdda08c X-Virus-Checked: Checked by ClamAV on apache.org --005045013bbe2cb34c048bdda08c Content-Type: text/plain; charset=ISO-8859-1 Gads, I'm out of it today. Thanks, *Bryan*, not Mike... On Tue, Jul 20, 2010 at 8:34 PM, David Van Couvering wrote: > Thanks, Mike > > I am doing some of that, and am looking into doing more of that. > > But it's more than possible that I'll have a lot of open, *active* > databases. > > We're talking a lot of data, potentially 10s of GB of BLOBs. I was > concerned a single Derby DB would not be able to handle this well, so I > asplit this up into multiple databases. This also gives me future > flexibility to spread the databases across different disks to avoid > contention. > > But if you think this can be managed fine in a single database, well, I > could be convinced to go that way... :) > > Thanks, > > David > > > On Tue, Jul 20, 2010 at 7:37 PM, Bryan Pendleton < > bpendleton.derby@gmail.com> wrote: > >> Hi. Could you point me to a page, or just tell me, what >>> configuration settings I can tweak to reduce the overall memory >>> footprint of a booted Derby database. Losing performance is pretty much >>> OK, this is not a time-critical part of our code, but I have a lot of >>> databases open and it's impacting memory footprint pretty significantly. >>> >> >> If you can manage the performance hit, I think the best way to keep >> a lid on the overall resource usage is to change your approach, and *not* >> keep a lot of databases open, but rather close each database when it's >> not in use, and then re-open it upon demand. >> >> thanks, >> >> bryan >> >> > > > -- > David W. Van Couvering > > http://www.linkedin.com/in/davidvc > http://davidvancouvering.blogspot.com > http://twitter.com/dcouvering > -- David W. Van Couvering http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering --005045013bbe2cb34c048bdda08c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gads, I'm out of it today.=A0 Thanks, *Bryan*, not Mike...

On Tue, Jul 20, 2010 at 8:34 PM, David Van Couvering = <david@vanco= uvering.com> wrote:
Thanks, Mike
<= br>I am doing some of that, and am looking into doing more of that.=A0
=
But it's more than possible that I'll have a lot of open, *active* = databases.=A0

We're talking a lot of data, potentially 10s of G= B of BLOBs.=A0 I was concerned a single Derby DB would not be able to handl= e this well, so I asplit this up into multiple databases.=A0 This also give= s me future flexibility to spread the databases across different disks to a= void contention.=A0

But if you think this can be managed fine in a single database, well, I= could be convinced to go that way... :)

Thanks,

David


On Tue, Jul 20, 2010 at 7:37 PM, Bryan Pendleton <bpendleton.derb= y@gmail.com> wrote:
Hi. =A0Could you point me to a page, or just tell me, what
configuration settings I can tweak to reduce the overall memory
footprint of a booted Derby database. =A0Losing performance is pretty much<= br> OK, this is not a time-critical part of our code, but I have a lot of
databases open and it's impacting memory footprint pretty significantly= .

If you can manage the performance hit, I think the best way to keep
a lid on the overall resource usage is to change your approach, and *not* keep a lot of databases open, but rather close each database when it's<= br> not in use, and then re-open it upon demand.

thanks,

bryan







--
David W. Va= n Couvering

http://ww= w.linkedin.com/in/davidvc
http://davidvancouvering.blogspot.com
http://twitter.com/dcouvering=
--005045013bbe2cb34c048bdda08c--