I got some new to me hardware. I did a fresh LinHES R6.01 install and restored my R5.5 DB, then upgraded to R6.03. I've been running it for about a month now and at times I find is slow to respond. top tells me that mysql is using 150% cpu usage. A quick restart of mysql and things are back to normal for a while. /var/log/mysql.log is blank so I'm not sure where to start looking. When I look at the RRD graphs it seems to happen around midnight. /etc/cron.daily has something in there to check the DB but when I run it manually it runs fine, and it doesn't happen every day.

Any thoughts on where to start?

From memory, that's not where mysqld's logs are. Look at /var/log/mysql/. Also, mysql logs may be binary (noticed a while ago that this was the case - may not be any longer). If so, you will have to use amysql log tool to read them.

I would tail -f the log file while the cpu is climbing.

Mike

EDIT: Just noticed that it seems to jump suddenly to 100% at midnight. Is that correct? It's highly suspicious. What cron jobs are running at midnight? What do the other logs say about this?

_________________
*********************
LinHES 7.4
Australian Dragon
*********************

Hi Mike.
Both my production box and test box have /var/log/mysqld.log files but they are blank. I don't see a mysql folder in the log folder either. I changed /etc/sv/mysql/run to point to /var/log/mysqld.log instead of /dev/null but all I get is this when the server starts. Nothing changes when it starts to run away.

The thing I suspect, like you, is that since it's always happening near midnight that some job is setting it off, however it's not doing it every day. (6-7 times this month) The first suspect is /etc/cron.daily/myth_mtc.sh which appears to run an optimize on the db. The log from that is

The only difference I can see between the logs on a night when it happens is the "myth is not idle" part. But is seems that it waits till it is before running the optimize.

See anything in there that jumps out at you that I may have missed?

It certainly seems high in the likelihood stakes. Two easy things to check whether it's the cause:
1. Run the process manually (run in a terminal the line in your crontab that runs the job) and check it, or
2. comment it out of your crontab, ensuring it doesn't run for a while. This isn't going to kill your database. The optimisation thing wasn't even in the distro until recently, so if you determine that it's the problem, just disable it.

The first is much better if you're really impatient.

Mike

_________________
*********************
LinHES 7.4
Australian Dragon
*********************

I found that /etc/cron.daily/myth_mtc.sh was on the backend and both my frontend only machines. I removed it from the frontend machines hoping that if they were running at the same time they might conflict. It didn't help so I removed it from the backend as well. I've now been running 2 weeks without a hitch. The real question is, if it's installed by default, and no one else is having trouble, what's wrong with my machine? Is the DB corrupt?

Interesting. Until you pointed out I didn't know what was causing my master backend to occasionally have mysql running at 99% of CPU. I found myth_mtc still running today which doesn't seem right. I've commented out that cron job and I will see if I am more stable.