>>>>> "Brian" == Brian Moon <brianm@stripped> writes:
Brian> Ok, it locked up again. I will be running it with --log now, but have not
Brian> yet because it had not died. I did a
>> mysqladmin ext # would not run
>> mysqladmin var # would not run
>> mysqladmin pro # would run, output below
Brian> Got no response. During this lock up, the mysql cpu hovered around 58% for
Brian> hours before we found it. We have a script that logs the mysql cpu every 2
Brian> This is the command line used (I got it from ps -aux | grep mysql):
Brian> /usr/local/mysql-3.22.26/libexec/mysqld --basedir=/usr/local/mysql-3.22.26 -
Brian> -datadir=/usr/local/mysql-3.22.26/var -O max_connections=250 -O
Brian> back_log=100 -O table_cache=250 -O wait_timeout=300
Brian> I will add --log to this command line.
Brian> Any other ideas?
This seams to be a problem with some mutex lock somewhere. This could
be a problem also with your thread library.
- Upgrade to BSD 3.2
- Try if MySQL 3.23.4 helps.
- Get gcc 2.95 and use this when you compile MySQL
- Recompile mysql with --with-debug ; This will enable some mutex
checking in MySQL that may solve this!
- Running mysqld under gdb and when you get a lock, kill mysqld and
get back traces for all threads.
Another issue; Can you find some tool for FreeBSD that writes a
stack trace for all running threads? (Solaris have a utility called
pstack that does this).
Sorry that I don't have any specific suggestions, but I have only seen
one similar case before and I couldn't get a stack trace of this