From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 28 10:39:43 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B2C51065670 for ; Sat, 28 Nov 2009 10:39:43 +0000 (UTC) (envelope-from andymac@bullseye.apana.org.au) Received: from ipmail02.adl6.internode.on.net (ipmail02.adl6.internode.on.net [203.16.214.140]) by mx1.freebsd.org (Postfix) with ESMTP id CE10F8FC23 for ; Sat, 28 Nov 2009 10:39:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoGAN+IEEt5LcZN/2dsb2JhbACBTZdiuT+EMQQ Received: from ppp121-45-198-77.lns20.cbr1.internode.on.net (HELO bullseye.apana.org.au) ([121.45.198.77]) by ipmail02.adl6.internode.on.net with ESMTP; 28 Nov 2009 20:54:22 +1030 Received: from [192.168.63.10] (tenring.andymac.org [192.168.63.10]) by bullseye.apana.org.au (8.14.2/8.14.2) with ESMTP id nASAPeQ4007378 for ; Sat, 28 Nov 2009 21:25:45 +1100 (EST) (envelope-from andymac@bullseye.andymac.org) Message-ID: <4B10F7DC.1080408@bullseye.andymac.org> Date: Sat, 28 Nov 2009 21:13:48 +1100 From: Andrew MacIntyre User-Agent: Thunderbird 2.0.0.23 (OS/2/20090822) MIME-Version: 1.0 To: FreeBSD Hackers References: <4B1041EB.9020109@sippysoft.com> <4B1059CA.6040605@FreeBSD.org> <4B10687D.3050209@sippysoft.com> <4B107D29.5030307@FreeBSD.org> <4B10896E.3080201@sippysoft.com> In-Reply-To: <4B10896E.3080201@sippysoft.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 10:39:43 -0000 Maxim Sobolev wrote: > Jason Evans wrote: >> I would set MAXDSIZ to 0, so that the maximum amount of memory is >> available for mapping shared libraries and files, and allocating via >> malloc. This may cause problems with a couple of ports that implement >> their own memory allocators based on sbrk, but otherwise it should be >> all good. You might also set /etc/malloc.conf to 'd' in order to >> disable the sbrk calls. > > I see, thank you for the explanation. One of the problem that we are > having is that we use a lot of interpreted languages in our environment > (python, php etc), and most of those implement their own memory > allocators, some of which rely on sbrk(2) unfortunately. I believe > that's where that 2GB limit of ours comes from - one of our Python > applications is very memory hungry and we had to bump that limit to > allow it sufficient room. While Python has its own allocator, it relies on the platform malloc() rather than sbrk(), and therefore Jason's suggestion to use '-d' in /etc/malloc.conf should be effective for it. -- ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia