Date: Mon, 22 Mar 2004 09:39:44 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Thomas Hurst <tom@hur.st> Cc: threads@freebsd.org Subject: Re: Loaded MySQL 4.0.18 w/ KSE running nicely Message-ID: <Pine.BSF.4.21.0403220934480.35223-100000@InterJet.elischer.org> In-Reply-To: <20040322170816.GA56747@voi.aagh.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Mar 2004, Thomas Hurst wrote: > * Julian Elischer (julian@elischer.org) wrote: > > > On Mon, 22 Mar 2004, Thomas Hurst wrote: > > > > > Just thought I'd make a little note to let people know that we're > > > successfully running MySQL 4.0.18 on 5.2.1-RELEASE-p3 dated Mar 18 using > > > libkse, after having raised thread limits to 500 per proc/150 per group: > [..] > > Spoke too soon; few hours ago we got: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 01 > fault virtual address = 0xea3db028 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc061e937 > stack pointer = 0x10:0xea3f6d74 > frame pointer = 0x10:0xbf93499c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 93103 (mysqld) > > We are not amused, especially since the kernel seemed to ignore our > PANIC_REBOOT_WAIT_TIME=5, and now we have MySQL churning through 65 > million records, which looks like it's going to take hours. I'm guessing that you don't have a debug kernel or a core dump right? The big difference between 5.2.1 and -current is that (assuming you select the BSD4 scheduler) the threads code has been cleaned up somewhat. Some edge cases have been cleened up for example. a core-dump would be great however! failing that you could do: (if you have a kernel.debug in your build tree) gdb -k kernel.debug /dev/mem x/i 0xc061e937 and see what function the pagefault occured in even without the kernel.debug there MAY be enough info in /kernel to give us a clue. > This seems to be a result of a load spike caused by a cronjob. We have > DSIZ/SSIZ both set to 1GB; I'm wondering if a 1GB stack is desirable, > given NOTES only has it set to 128M while the DSIZ example is at 1GB... > and I *really* hope it's not a hardware issue. Given it's got more fans > than the latest boy band and has good quality ECC memory in it, it > shouldn't be... > > > it's a pitty we can't see -current > > > > limits are increased to 500 and 1500 and code improved in several > > places. > > Hey, we tried :) > > > it would also be interesting to see how it differs with the package > > compiled to use process scope threads intead of system scope > > threads. Dan had instructions to do that somewhere I think. > > Will look into this. Further pointers gratefully received :) > > > is 142 Queries per second ok or slow? what were you getting before? > > About the same. If it were slower than before I wouldn't have said it > was successful. And given the latest development, maybe it's not :/ > > -- > Thomas 'Freaky' Hurst - freaky@aagh.net - http://www.aagh.net/ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0403220934480.35223-100000>