[vox-tech] mysql experts?

[ketralnis at softhome.net]

This is a FreeBSD system, but it's standard MySQL (mysql  Ver 12.22 Distrib 
4.0.20, for portbld-freebsd5.0 (i386)). This morning, a user of my network 
told me that "the internet is down." Quick inspection of the machine 
revealed that the WinXP box had failed to receive an IP address from the 
DHCP server, the machine in question. I plugged a monitor into it (since I 
now couldn't boot another unix machine that required NFS and couldn't talk 
to it from a windows box) to reveal a screen full of errors, most of them 
saying "no room left on device" or "not enough inodes." A quick df -i 
revealed that indeed, /var had no inodes left, which is weird since it 
usually sits at about 6% inodes used (obviously dhcpd couldn't write out the 
new lease file because it had no inodes left, explaining the internet "being 
down"). du -d2|sort -n revealed that 95% of the inodes used were in 
/var/db/mysql, and a directory listing revealed several thousand files named 
innodb.status.???? where ? is a number from 0-9. I've noticed that past few 
days that mysql, while sitting idle, has been taking up as much as 30% CPU, 
and I can't track down why it would be doing that. It seemed to be created 
about one every twenty seconds, without even querying the database! Here's 
an example: 

root at melchoir:/var/db/mysql# while true; do sleep 60; ls inno*|wc -l; done
      5
      8
     12
     16
     19
     23
     26
     30
     34
     37 ^C 

Obviously, this is a bad thing. A typical innodb.status.???? looks like 
this: 

root at melchoir:/var/db/mysql# cat innodb.status.1959 

=====================================
040614 20:55:02 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 16 seconds
 ----------
SEMAPHORES
 ----------
OS WAIT ARRAY INFO: reservation count 4, signal count 4
Mutex spin waits 0, rounds 0, OS waits 0
RW-shared spins 6, OS waits 3; RW-excl spins 1, OS waits 1 

 

Does anyone know what could cause this? It looks to be, for whatever reason 
writing out status information. But why it would do that, and why it would 
take 30% CPU idling is beyong me. Any ideas?