creating log files

[David King]

I apologise for not lurking for longer before posting, but this is 
becoming increasingly important. 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. (They look suspiciously like PIDs.) 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 does it in spurts, taking 6%, and then 30% right around the time it 
creates the files. It seemed to be created about one every twenty seconds, 
without even querying the database! Here's an example:

[EMAIL PROTECTED]:/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:
[EMAIL PROTECTED]:/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? (I wrote that email 
a few days ago, here is an update:) It seems that now another set of files 
is being created in the same directory, with names like 
ib_arch_log_0000050412, those numbers change as more files are created. I 
can't time how many are being created per minute exactly, but here's an 
example like above:

[EMAIL PROTECTED]:/var/db$ while true; do sudo ls mysql | grep 
'inno\|ib_arch_log' | wc -l; sleep 60; done
       0
       8
      14
      22
      28
      36
      42
      49
      56
      64
      70
      76
      84
      90 ^C

The ib_arch_log_0000050444 files are not printable, and are all 2560 
bytes long, owned by mysql:mysql.

My server houses one small database with two tables, and then the mysql 
internal databse and an empty "test" database, and to my knowledge nothing 
is strange about its setup. I am using the default my_small.cnf that 
installed with it (from FreeBSD ports), and if it has any modifications 
they are only things like "hostname" and so on. I did turn off IP ports 
for it, so it's only using /tmp/mysql.sock for connection. If any more 
information is needed I can provide it. My current fix is walking up to 
the machine every few hours and deleting the log files, which definately 
isn't acceptable. I apologise if I am in the wrong group for this, I would 
like if I could be directed to the correct one. Thank you.

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]