Thanks, Ken.
> 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've noticed rare occasions (about 1% of the time) when poll() returns 0
-- these are always preceeded in the trace output by a signal handler,
like this:
45689 mysqld 0.000008 CALL sigreturn(0x826ae7c)
45689 mysqld 0.000010 RET sigreturn JUSTRETURN
45689 mysqld 0.000024 CALL poll(0x8270000,0x91,0)
45689 mysqld 0.000041 RET poll 0
45689 mysqld 0.000023 CALL poll(0x8270000,0x92,0x1ff)
45689 mysqld 0.000040 RET poll 1
(Really, I'm not sure what to make of ktrace: which thread makes a
particular call? Why are the timestamps interleaved?...)
> I was also wondering how much RAM you had, I hope it is about 2 gig
I have 768 MB here, for 50 databases with about 10 tables each, getting
6 queries per second. My current mysqld has been running since
yesterday and now has a resident size of about 100MB. I did restart the
server yesterday to get it back to normal, and I can't reproduce the
problem, but I can leave it running and expect the problem to reappear
within about 10 days. When it comes back, I will take a good look at
memory and the processlist. My recollection is that the condition will
persist without there being any currently running query at all...
- JD
-------------------------------------------
John David Duncan
Systems Administrator
Great Schools, Inc.
---------------------------------------------------------------------
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
