Date: Mon, 10 Jul 2006 18:03:12 -0700 From: Paul Allen <nospam@ugcs.caltech.edu> To: Mike Jakubik <mikej@rogers.com> Cc: Mathieu Arnold <mat@freebsd.org>, Darren Pilgrim <darren.pilgrim@bitfreak.org>, stable@freebsd.org Subject: Re: MySQL and default memory limits (mysqld: Out of memory) Message-ID: <20060711010312.GB12597@groat.ugcs.caltech.edu> In-Reply-To: <44B17AE2.5020908@rogers.com> References: <44B16BE9.60508@rogers.com> <E56FEA0F58A776685B3AB5DF@[192.168.1.5]> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
>From Mike Jakubik <mikej@rogers.com>, 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060711010312.GB12597>