From owner-freebsd-ports@FreeBSD.ORG Thu Jul 13 03:16:48 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42AD616A4DD for ; Thu, 13 Jul 2006 03:16:48 +0000 (UTC) (envelope-from grog@lemis.com) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8840043D49 for ; Thu, 13 Jul 2006 03:16:47 +0000 (GMT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 823D59B499; Thu, 13 Jul 2006 12:46:46 +0930 (CST) Date: Thu, 13 Jul 2006 12:46:46 +0930 From: Greg 'groggy' Lehey To: Koen Martens , freebsd-ports@freebsd.org, uzi@bmby.com Message-ID: <20060713031646.GJ19708@wantadilla.lemis.com> References: <44B52695.5050700@metro.cx> <20060712170517.GA99030@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3CAnR4CLEnEWqRMR" Content-Disposition: inline In-Reply-To: <20060712170517.GA99030@icarus.home.lan> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 VoIP: sip:0871270137@sip.internode.on.net WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: Subject: Re: mysql signal 11 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 03:16:48 -0000 --3CAnR4CLEnEWqRMR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 12 July 2006 at 10:05:17 -0700, Jeremy Chadwick wrote: > On Wed, Jul 12, 2006 at 06:43:01PM +0200, Koen Martens wrote: >> Hi All, >> >> Recently came across: >> >> http://lists.freebsd.org/pipermail/freebsd-ports/2005-April/022667.html Unfortunately, this message doesn't give much information about the cause of the problems. >> I tried mysql-5.0.22 as a freebsd package, tried the official mysql >> binary for freebsd-6.x and tried a fresh compile from the mysql >> source tarball, all with the same problem. >> >> I then tried the 4.1 binary from mysql.com, that worked fine, also >> tried the 5.1 beta binary from mysql.com, and that was fine too. >> >> Not sure what to do with this info, i'll probably try to make a >> test-case for it and submit it to the mysql bug system. (Koen) Yes, please do. > I've experienced this exact problem (with current versions of MySQL, > as well as older (4.0 and 4.1)). I ended up fixing it by doing the > following on our 5.5-STABLE (which has been world'd since > 5.2-STABLE, in case there's any concern): You can't really know if it's the exact problem or not. A SIGSEGV is a very unspecific problem. At MySQL, we've seen a number of different problems with FreeBSD, many of which result in a SIGSEGV. In this particular case, Koen reported that the problem only happens on 5.0, not on 4.1 or 5.1. You report that you've had it on all versions you've tried. That tends to suggest that these are two different problems, but we can't confirm that either based on the evidence at hand. You might like to take a look at http://dev.mysql.com/doc/refman/5.0/en/debugging-server.html ; we can certainly do with the information requested there. Note also http://bugs.mysql.com/bug.php?id=19496 , which was caused by a bug in the thread library. It was fixed by 5.5, I think, but potentially it's Koen's problem. > 1) Kernel: use SCHED_4BSD not SCHED_ULE > > 2) Kernel: use ADAPTIVE_GIANT > > 2) Kernel: Increasing size limits using loader.conf variables: > kern.maxdsiz="805306368" > kern.dfldsiz="805306368" > kern.maxssiz="134217728" > (The machine has 1GB RAM; note the sizes are topped out at > 768MB, since that could induce a kernel panic due to > memory exhaustion) > > 4) MySQL tuning: increased packet size (which fixed segfault; > possibly related?) > set-variable = max_allowed_packet=32M > > 5) MySQL tuning: didn't require much, but we did set some higher > limits for join/sort/read_buffer_size (128M). This isn't really a fix, it's a workaround. It's also rather extensive. Have you confirmed that *all* of these are necessary to make the problem go away? In general: at MySQL, we *are* seriously concerned about reliability. But before we can fix it, we need reports that help us to identify the problem. Feel free to enter bug reports (after reading the manual). And yes, it's a pain getting all this information together. I can understand that you might not want to do so. That's your choice; but if we can't reproduce a bug, or at least have a reasonable idea where it's coming from, we can't do much about it. Greg -- Greg Lehey, Senior Software Engineer, Online Backup MySQL AB, http://www.mysql.com/ Echunga, South Australia Phone: +61-8-8388-8286 Mobile: +61-418-838-708 VoIP: sip:4484@sip.mysql.com, sip:0871270137@sip.internode.on.net Diary http://www.lemis.com/grog/diary.html Are you MySQL certified? http://www.mysql.com/certification/ --3CAnR4CLEnEWqRMR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEtbseIubykFB6QiMRAjtKAJ9PoVnjHMbYJraTLNfv4aUJcEHZhQCfdI5G V0P73j2RPLLsqeCQfk2ImDU= =lWH8 -----END PGP SIGNATURE----- --3CAnR4CLEnEWqRMR--