From owner-freebsd-stable@FreeBSD.ORG Mon Jul 10 18:06:33 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 BFD9D16A4DD for ; Mon, 10 Jul 2006 18:06:33 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8928043D5C for ; Mon, 10 Jul 2006 18:06:16 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 865676075; Mon, 10 Jul 2006 14:06:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdEVdCtXYVEk; Mon, 10 Jul 2006 14:06:14 -0400 (EDT) Received: from [192.168.1.251] (pool-68-161-117-245.ny325.east.verizon.net [68.161.117.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 13F7C5C14; Mon, 10 Jul 2006 14:06:13 -0400 (EDT) Message-ID: <44B2970E.7000501@mac.com> Date: Mon, 10 Jul 2006 14:06:06 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Mike Jakubik References: <44B16BE9.60508@rogers.com> <44B176D2.3080501@rogers.com> <44B276F7.4070507@mac.com> <44B28B7F.1000507@rogers.com> In-Reply-To: <44B28B7F.1000507@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Mon, 10 Jul 2006 18:06:33 -0000 Mike Jakubik wrote: > Chuck Swiger wrote: >> 512MB is more than enough for almost all processes to run just fine, >> and is only really inappropriate for the case where you've got 1-plus >> GB of physical RAM and want to dedicate the system to a single large >> task, or perhaps a single-digit number of processes if you've got >> several GB of physical RAM. > > Such as a database server. Yes, exactly. :-) Database servers are a rather specialized role which differs in tuning requirements from normal "general purpose"/"interactive use" workloads substantially, and it is common for databases to work much better after the system has been tuned appropriately. This is partially because many databases want to do their own filesystem management and control their own VM/paging behavior, which are uncommon requirements. > I just think it would be nicer if this limit > was dynamically set, based on your configuration. Just like MAXUSERS was > a kernel variable, it is now dynamically set based on your resources. Yes, well, autotuning is nice but sometimes there isn't an "obviously correct value" for this limit which is appropriate for all circumstances. Anyone doing virtual hosting needs to keep this kind of thing under tighter control, for example. Setting the value lower is beneficial for some cases because it prevents memory leaks in C code or the system libraries, or bloated Java VM's, etc, from stealing too many resources from other processes. -- -Chuck