From owner-freebsd-stable@FreeBSD.ORG Tue Jul 11 01:03:14 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 084C016A4DA; Tue, 11 Jul 2006 01:03:14 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from groat.ugcs.caltech.edu (groat.ugcs.caltech.edu [131.215.176.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id B350543D45; Tue, 11 Jul 2006 01:03:13 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by groat.ugcs.caltech.edu (Postfix, from userid 3640) id C1EED5880B; Mon, 10 Jul 2006 18:03:12 -0700 (PDT) Date: Mon, 10 Jul 2006 18:03:12 -0700 From: Paul Allen To: Mike Jakubik Message-ID: <20060711010312.GB12597@groat.ugcs.caltech.edu> References: <44B16BE9.60508@rogers.com> <44B171AA.9080400@bitfreak.org> <6C05189234026592B01C2703@[192.168.1.5]> <44B17437.5010506@bitfreak.org> <7215DBE558702ADFC8718798@[192.168.1.5]> <44B176F5.2050409@rogers.com> <2B636EF151DC536C47555034@[192.168.1.5]> <44B17AE2.5020908@rogers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B17AE2.5020908@rogers.com> Sender: jd@ugcs.caltech.edu Cc: Mathieu Arnold , Darren Pilgrim , stable@freebsd.org Subject: Re: MySQL and default memory limits (mysqld: Out of memory) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 01:03:14 -0000 >From Mike Jakubik , Sun, Jul 09, 2006 at 05:53:38PM -0400: > Mathieu Arnold wrote: > >| Exactly, its nice being able to see the current values. How else can i > >| see what the values are set to? > > > >As I previously said, it's 512M on i386, and 1G on 64 bit platforms. > > > > > > Right, this explains why my amd64 system works just fine. Shouldn't this > be a dynamic value based on total amount of ram? Say 70% of RAM, I mean > servers have plenty of RAM nowadays, this seems like an old hard limit, > which many new users will trip over.... I set my value to 805306368, and > mysql seems to be happy now. > maxdsiz sets the largest brk(2) allocation. mmap(2) allocations are made from virtual addresses above maxdsiz. Raising maxdsiz squeezes mmap and lowering it squeezes brk. The system allocator (phkmalloc) uses the brk system call to get memory--as do many other allocators but notable not ptmalloc2 or the new 7.x jmalloc IMO, the kernel is just being obnoxious here. It would be better if the mmap address space allocation algorithm just tried to work from the stack down (growing toward the brk where-ever it happened to be). What is old and out of date is that the amount of physical RAM has caught up to the size of the virtual address space of a process. Historically, it was cheap/free to use a boundary like this. Now i386 is on its last legs and thus the wastefulness (in exchange for simplicity) has a noticable cost.