From owner-freebsd-hackers Mon Jul 29 11:40:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8B7137B400; Mon, 29 Jul 2002 11:39:57 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7345743E31; Mon, 29 Jul 2002 11:39:57 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g6TIdvCV055640; Mon, 29 Jul 2002 11:39:57 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g6TIduVw055637; Mon, 29 Jul 2002 11:39:56 -0700 (PDT) (envelope-from dillon) Date: Mon, 29 Jul 2002 11:39:56 -0700 (PDT) From: Matthew Dillon Message-Id: <200207291839.g6TIduVw055637@apollo.backplane.com> To: Anders Nordby Cc: Nuno Teixeira , Jens Rehsack , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: squid and datasize kernel problems (was: openoffice stack and datasize kernel problems) References: <20020608153940.GA13033@gw.tex.bogus> <3D022B97.3BB722F@liwing.de> <20020608161556.GC13033@gw.tex.bogus> <200206081740.g58HesRL081782@apollo.backplane.com> <20020729135107.GA82519@totem.fix.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :... :> It should be noted that mmap() uses whatever VM space :> remains after MAXDSIZ and MAXSSIZ have been reserved, so :> increasing MAXDSIZ reduces the amount of VM available :> to mmap(). Still, a 1 GB MAXDSIZ should not result in :> system utilities / servers running out of mmap() space! :> Userland has 3G of VM space to play with. : :I'm running into some similar issues when trying to make Squid eat as :much as possible of the 4 GB memory I have installed in a Compaq :ProLiant DL 380 G2. At first, Squid seems to die and restart when trying :to allocate memory above 512 MB. By tuning MAXDSIZ, I have made it use :up to around 2 GB. If I set MAXDSIZ (I now do it in loader.conf with :kern.maxdsiz) above around 2950 MB, init starts failing upon boot: : :init in malloc(): error mmap(2) failed, check limits :init in malloc(): warning: recursive call : :Does anyone have any clues on how to overcome this? I'll be trying out :the the dlmalloc library that is distributed with Squid, but I suppose :I do need a 4 GB maximum data size to be able to make Squid actually use :4 GB. Is this possible, or am I being totally foolish? : :Any hint very appreciated. :-) : :Cheers, : :-- :Anders. 0xFFFFFFFF +-----------------------+----- | | | KERNEL | (1G) | | 0xC0000000 +-----------------------+----- | | | USER STACK | | | | | V | | | +-----------------------+ | | | | | AVAILABLE FOR MMAP | | | (stack, mmap, user data, program) = 3G MAXDSIZ +-----------------------+ | | | USER DATA (NON-MMAP)| | | +-----------------------+ | | | PROGRAM BINARY | | | 0x00000000 +-----------------------+----- Any C program which uses shared libraries uses mmap(). Many library functions and libraries also use mmap(), including portions of our malloc() implementation (though the main area used by mmap is the user data area). If you increase MAXDSIZ to the point where there is not enough VM for the mmap()'s programs make then you will run into the problems you are having. I'm not sure why you are trying to have squid use all 4G of the machine directly in its user data area. Squid caches a lot of things in memory, sure, but it also caches things in files and FreeBSD will use free physical memory to cache those files regardless of how you configure the machine. So you should be getting good utilization of your 4G of memory even if Squid cannot use all 4G in its user data area directly. Setting MAXDSIZ to 2.9GB out of the 3G of user VM available puts a huge squeeze on how much the program can mmap() before it runs out of VM. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message