> > > > 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
PE2950
Description: Binary data
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"