Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41

[Primeroz lists]

>
>
>
> There's additional information needed to help with this:
>
> 1) Contents of /boot/loader.conf


empty


>
> 2) What scheduler you're using in your kernel configuration


We using the 4bsd Scheduler (ULE is commented out in kernel conf)


> 3) Your kernel configuration in its entirity, if possible :-)


attached


>
> 4) What options you compiled/built mysql50-server with


As from Tinderbox log:

configure: running /bin/sh './configure' --prefix=/usr/local
'--localstatedir=/var/db/mysql' '--without-debug' '--without-readline'
'--without-libedit' '--without-bench' '--without-extra-tools'
'--with-libwrap' '--with-mysqlfs' '--with-low-memory'
'--with-comment=FreeBSD port: mysql-server-5.0.41'
'--enable-thread-safe-client' '--with-named-thread-libs=-pthread'
'--prefix=/usr/local' '--build=amd64-portbld-freebsd6.2' 'CC=cc'
'CFLAGS=-O2 -fno-strict-aliasing -pipe ' 'CXXFLAGS=-O2
-fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe
-felide-constructors -fno-rtti -fno-exceptions' 'CXX=c++'
'build_alias=amd64-portbld-freebsd6.2' CFLAGS=' -DDBUG_OFF -O2
-fno-strict-aliasing -pipe ' CXXFLAGS=' -DDBUG_OFF -O2
-fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe
-felide-constructors -fno-rtti -fno-exceptions -fno-implicit-templates
-fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=1000000'
--cache-file=/dev/null --srcdir=.



This is taken from loader.conf on our production SQL server running
> RELENG_6, i386, with 2GB RAM:
>
>
> # Increase maximum allocatable memory on a process to 1536MB.
> # We don't choose 2GB (our amount of RAM) since that would
> # exhaust all memory, and result in a kernel panic.  Maximum
> # stack size is still set to 128MB.
> #
> # dfldsiz = Initial data size limit (bytes)
> # maxdsiz = Maximum data size limit (bytes)
> # dflssiz = Initial stack size limit (bytes)
> # maxssiz = Maximum stack size limit (bytes)
> #
> kern.maxdsiz="1536M"
> kern.dfldsiz="1536M"
> kern.maxssiz="128M"
>

I did not setup anything in the /boot/loader.conf so i guess i'm using
default values for all of those settings,


> Some other comments:
>
>

> Finally, I will take a moment to urge you to upgrade that box to
> RELENG_7.  SCHED_ULE was re-written and specifically tested with mysqld
> in mind, and are quite impressive.  The fact you're using a pair of quad
> core CPUs would be reason enough to upgrade.  RELENG_6 will soon be on
> its way out the door, so it's an inevitable upgrade anyways.
>

Yes, configuration need fixing especially about InnoDB that is not
configured/tuned at all.
The one that take my attention more then others options is:

set-variable    = innodb_buffer_pool_size=512M

I'm sure i need to increase that value, i'm using the default that surely is
not giving me the expected resaults ... but i wonder if that can lead to
such a crash and not just a performance problem as i read on some sources on
internet about mysql optimization.

We are thinking about an OS Upgrade but what i would really like is to
understand what in mysql is triggering this crash before upgrading to new
OS/Mysql and maybe mask the problem for long time.

thanks for your help.
Francesco Ciocchetti
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PE2950
Type: application/octet-stream
Size: 5552 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080204/8266695d/PE2950.obj