Date: Mon, 28 Jun 1999 10:23:22 -0700 (PDT) From: vsimoes@fleximedia.pt To: freebsd-gnats-submit@freebsd.org Subject: kern/12434: signal 11 (core dumped) on mysqld when machine is under quite heavy load Message-ID: <19990628172322.774F81544C@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 12434 >Category: kern >Synopsis: signal 11 (core dumped) on mysqld when machine is under quite heavy load >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jun 28 10:30:00 PDT 1999 >Closed-Date: >Last-Modified: >Originator: Vitor Simoes >Release: FreeBSD 3.2-BETA >Organization: Fleximedia >Environment: FreeBSD shiva.fleximedia.pt 3.2-BETA FreeBSD 3.2-BETA #8: Tue May 11 16:34:33 WEST 1999 root@:/usr/src/sys/compile/SHIVA i386 >Description: I've been using mysql for a long time and it used to work very stable until lately. Recently after uprgading from FreeBSD 3.1 to FreeBSD 3.2 mysqld started dumping core regularly with signal 11 (segmentation violation) at moments of high load. There seems to be no particular query that is garanteed to kills mysqld, although >How-To-Repeat: The specifics of usage is that mysql gets a lot of 'replace delayed' queries (up to 7-10 queries a second) on one table while different selects are done on other tables. Till the very death mysql performs very well, giving fast answers and taking only 1-3% of cpu load. The death itself is instant and unpredictable. There is nothing left in any log files about it. >Fix: We worked around the problem by using a static mysqld built on 3.1. That worked quite well. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990628172322.774F81544C>