Hello Sir,
I will delete most of your original message for brevity (to save
bandwidth). I do have a couple of suggestions, first is too back off
the optimzation (-O3 ) that you used to compile MySQL (probably in
make.conf) go with just -O. On an Idle system here kdump gives me a
call 'clock_gettime' and another poll I do not see in you trace!
Poll seems to returns 0 on mine. IE:
38554 mysqld 0.000019 RET clock_gettime 0
38554 mysqld 0.000028 CALL poll(0x82c1000,0x2,0)
38554 mysqld 0.000022 RET poll 0
38554 mysqld 0.000012 CALL poll(0x82c1000,0x3,0x2719)
38554 mysqld 10.010271 RET poll 0
38554 mysqld 0.000057 CALL gettimeofday(0x283799e8,0)
38554 mysqld 0.000014 RET gettimeofday 0
38554 mysqld 0.000058 CALL clock_gettime(0,0xbfafefa4)
38554 mysqld 0.000015 RET clock_gettime 0
38554 mysqld 0.000023 CALL poll(0x82c1000,0x2,0)
38554 mysqld 0.000016 RET poll 0
38554 mysqld 0.000011 CALL poll(0x82c1000,0x3,0x2710)
Your return of Poll 1 seems to indicated that there is a descriptor
ready to be serviced (hence the going in continuosly) but that the
daemon does not seem to be able to complete the servicing of that
descriptor. I am not sure why your daemon skips 'clock_gettime'.
Maybe a mysql programmer could help with this. I have heard of this
happening on some systems randomly, it does not happen to me.
I was also wondering how much RAM you had, I hope it is about 2 gig
becuase you have you buffers set very large. Did you think to look at
systat to see how much free memory you had during this condition? I
assume also that you have restarted the daemon to get it back on
track.
Also, I noted in the stats you sent that there were 145 connections
and 2 running queries, what were the queries? Was there some process
locked up? 'mysqladmin processlist' would show if anything funky was
going on with an individual process. Has this only occured once? If
not how often? Can you reproduce at will?
The information you provided was excellent, but I am not sure this
will be easy to find.
Ken
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2001 10:46 PM
Subject: Mysqld/FreeBSD 4.3 stuck in kernel
> >Description:
> This busy mysql server will run well for about one week,
> with 95% idle cpu. Then at some point it will get "stuck," so
> that it is still very responsive, but cpu utilization changes
> to 95% system cpu and 0% idle cpu.
> When the server is in this condition and I use the ktrace utility
> to trace system calls, the output of ktrace consists of about 44%
> calls to poll() and 44% calls to gettimeofday(), in a pattern like
> this:
>
> bash-2.05# kdump -Rf ktrace.stuck | more
> [...]
> 45689 mysqld 0.000011 CALL gettimeofday(0x821ae28,0)
> 45689 mysqld 0.000014 RET gettimeofday 0
> 45689 mysqld 0.000024 CALL poll(0x8270000,0x92,0x4c)
> 45689 mysqld 0.000041 RET poll 1
> 45689 mysqld 0.000010 CALL gettimeofday(0x821ae28,0)
> 45689 mysqld 0.000015 RET gettimeofday 0
> 45689 mysqld 0.000024 CALL poll(0x8270000,0x92,0x4c)
> 45689 mysqld 0.000041 RET poll 1
>
> A ktrace of a normal server, in comparison, contains less than 1%
> each of gettimeofday() and poll().
>
----------<much cut see original post
>----------------------------------------
>
> GCC: Using builtin specs.
> gcc version 2.95.3 [FreeBSD] 20010315 (release)
> Compilation info: CC='gcc' CFLAGS='-O3 -mpentiumpro' CXX='gcc'
CXXFLAGS='-O3 -mpentiumpro -felide-constructors -fno-exceptions -fno-r
tti' LDFLAGS=''
> LIBC:
> -r--r--r-- 1 root wheel 1174570 Apr 21 02:05 /usr/lib/libc.a
> lrwxrwxrwx 1 root wheel 9 Jun 27 20:55 /usr/lib/libc.so ->
libc.so.4
> -r--r--r-- 1 root wheel 561580 Apr 21 02:05 /usr/lib/libc.so.4
> Configure command:
./configure --with-mysqld-user=mysql --enable-assembler --with-commen
t --with-berkeley-db --localstatedir=/var/mysql --with-mysqld-ldflags=
-all-static --disable-shared --with-gnu-ld --with-charset=latin1
> Perl: This is perl, version 5.005_03 built for i386-freebsd
>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php