From owner-freebsd-hackers  Sat Oct 26 10:29:36 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA12327
          for hackers-outgoing; Sat, 26 Oct 1996 10:29:36 -0700 (PDT)
Received: from anacreon.sol.net (anacreon.sol.net [206.55.64.116])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA12293
          for <hackers@FreeBSD.org>; Sat, 26 Oct 1996 10:29:12 -0700 (PDT)
Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by anacreon.sol.net (8.6.12/8.6.12) with ESMTP id MAA00689; Sat, 26 Oct 1996 12:28:41 -0500
Received: from localhost by solaria.sol.net (8.5/8.5)
	id MAA08279; Sat, 26 Oct 1996 12:31:20 -0500
From: Joe Greco <jgreco@solaria.sol.net>
Message-Id: <199610261731.MAA08279@solaria.sol.net>
Subject: Re: HELP! :-( Hitting datasize limit
To: phk@critter.tfs.com (Poul-Henning Kamp)
Date: Sat, 26 Oct 96 12:31:19 CDT
Cc: jgreco@ns.sol.net, hackers@FreeBSD.org
In-Reply-To: <17119.846344098@critter.tfs.com> from "Poul-Henning Kamp" at Oct 26, 96 05:34:58 pm
X-Mailer: ELM [version 2.4dev PL65]
MIME-Version: 1.0
Content-Type: text
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> In message <199610261417.JAA10206@earth.execpc.com>, Joe Greco writes:
> 
> >It starts off executing at about 55MB and will generally grow to double
> >that within 12 hours.  However, lately, it has been dying multiple times
> >daily with malloc errors (using phkmalloc, but given the apparent cause
> >I do not think this is the problem).  The current situation would tend 
> >to have caused it to grow >> 110MB... and when I did a little looking
> >into the problem, malloc was indeed returning NULL, which caused me to
> >scratch my head until I typed "unlimit; limit"...
> 
> You may want to
> 
> 	ln -sf H /etc/malloc.conf
> 
> I've not gotten a complete picture, but people indicate that it helps
> a little bit.

Hi Poul,

I did not mean to imply that I think it has ANYTHING to do with 
phkmalloc...  the growth in size is EXPECTED...

innd allocates per-channel receive buffers.  When the maximum allowed
size for a Usenet article is 1MB and you have fifty inbound NNTP channels,
it is reasonable to expect that the receive buffer for each channel will
eventually need to be grown close to 1MB to allow for the large 
alt.binaries articles that everyone shovels around.

I am sorry for any confusion.  I simply was looking for a way to remove
(or at least double) the datasize limitation.

Thanks!  :-)

... JG