Loaded MySQL 4.0.18 w/ KSE running nicely

[Julian Elischer]

On Mon, 22 Mar 2004, Thomas Hurst wrote:

> * Julian Elischer (julian at 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 at aagh.net  -  http://www.aagh.net/
>