List:General Discussion« Previous MessageNext Message »
From:Dan Nelson Date:March 30 2001 9:52pm
Subject:Re: linux innobase benchmarking and BSD problem
View as plain text  
In the last episode (Mar 30), Heikki Tuuri said:
> The FreeBSD bug is known. I will run tests on our FreeBSD machine in
> the next few days. Obviously there is something wrong with the
> FreeBSD port. Was it so that it hung and used 100 % of CPU? That has
> been reported also from Italy.

I have a similar problem, on FreeBSD 5 (i.e. -current).  I can insert
records one at a time with no problem, but if I try to update more than
~250 records at a time, it hangs, consuming 100% cpu.  gdb'ing a corefile of
the process, it looks like a mutex/spinlock problem of some sort. 
Deleting records dies if I delete between 100 and 150 records in one
go.  Does innobase create a mutex for each record processed?  Maybe
there's a limit on 256 held mutices per thread on FreeBSD or something.

-- mysqld hung on "insert into temp (value) select ip from iptable limit 300":
(gdb) thread apply all bt

Thread 1 (process 764):
#0  0x28288163 in _get_curthread ()
    at /usr/src/lib/libc_r/uthread/uthread_kern.c:1145
#1  0x28280064 in _spinlock_debug (lck=0xbfaa9ecc, 
    fname=0x28280138
"\203─\020\205└\017\2055   \213\205ⁿ■  \213U\b\211B\004\213E\f\211B\b\213E\020\211B\f\215Ñ╪■  [^_\211∞]├$FreeBSD:
src/lib/libc_r/arch/i386/_atomic_lock.S,v 1.3 1999/08/28 00:03:01 peter Exp $",
lineno=149551536)
    at /usr/src/lib/libc_r/uthread/uthread_spinlock.c:83
#2  0x282854d6 in mutex_trylock_common (mutex=0xbfaa9ecc)
    at /usr/src/lib/libc_r/uthread/uthread_mutex.c:311
#3  0x28285712 in __pthread_mutex_trylock (mutex=0x8ea3090)
    at /usr/src/lib/libc_r/uthread/uthread_mutex.c:441
#4  0x8193d4b in mutex_spin_wait (mutex=0x8ea308c) at ../include/os0sync.ic:38
#5  0x8126ead in srv_master_thread (arg=0x0) at ../include/sync0sync.ic:220
#6  0x2827f18c in _thread_start ()
    at /usr/src/lib/libc_r/uthread/uthread_create.c:326
#7  0x0 in ?? ()
(gdb) 


-- mysqld hung on "delete from temp limit 150":
(gdb) info threads;
* 1 process 26111  0x28361b54 in gettimeofday () from /usr/lib/libc.so.5
(gdb) where
#0  0x28361b54 in gettimeofday () from /usr/lib/libc.so.5
#1  0x28280949 in _thread_sig_handler (sig=0, info=0x828a660, ucp=0x282808d1)
    at /usr/src/lib/libc_r/uthread/uthread_sig.c:93
#2  0xbfbfffac in ?? ()
#3  0x28287ffb in _thread_kern_sig_defer ()
    at /usr/src/lib/libc_r/uthread/uthread_kern.c:1049
#4  0x282854bf in mutex_trylock_common (mutex=0x0)
    at /usr/src/lib/libc_r/uthread/uthread_mutex.c:308
#5  0x28285712 in __pthread_mutex_trylock (mutex=0x8ea3210)
    at /usr/src/lib/libc_r/uthread/uthread_mutex.c:441
#6  0x8193d4b in mutex_spin_wait (mutex=0x8ea320c) at ../include/os0sync.ic:38
#7  0x8165a84 in buf_page_get_gen (space=0, offset=6, rw_latch=2, guess=0x0,
    mode=10, mtr=0xbfaa95d0) at ../include/sync0sync.ic:220
#8  0x81576d9 in trx_purge_truncate_rseg_history (rseg=0x8ebd10c,
    limit_trx_no={high = 0, low = 7946}, limit_undo_no={high = 0, low = 0})
    at ../include/trx0rseg.ic:25
#9  0x8157bdd in trx_purge_truncate_history () at trx0purge.c:545
#10 0x81589c7 in trx_purge_fetch_next_rec (roll_ptr=0xbfaa9ee4,
    cell=0x8ec016c, heap=0x8ebfe0c) at trx0purge.c:564
#11 0x813a2b6 in row_purge (node=0x8ec0134, thr=0x8ec00d4) at row0purge.c:481
#12 0x813a4fe in row_purge_step (thr=0x8ec00d4) at row0purge.c:548
#13 0x8129aa2 in que_run_threads (thr=0x8ec00d4) at que0que.c:1223
#14 0x8158f95 in trx_purge () at trx0purge.c:1050
#15 0x8126fb5 in srv_master_thread (arg=0x0) at srv0srv.c:1901
#16 0x2827f18c in _thread_start ()
    at /usr/src/lib/libc_r/uthread/uthread_create.c:326
#17 0x0 in ?? ()
(gdb)


-- 
	Dan Nelson
	dnelson@stripped
Thread
linux innobase benchmarking and BSD problemSeung Yoo30 Mar
Re:linux innobase benchmarking and BSD problemHeikki Tuuri30 Mar
  • Re: linux innobase benchmarking and BSD problemDan Nelson30 Mar
Re: linux innobase benchmarking and BSD problemHeikki Tuuri31 Mar