Using Redhat linux 7.3 with an ext3 FS. Incidentally, I've just manually restarted mysql (which drops all in-progress processes), and it seems that the problem "takes a while to show" (i.e. there's a period after a restart that things seem to go along fine, then it all comes undone). I also should note that the database is being written to almost-constantly (it's being used as an apache logger process via mod_log_sql).
-dan On Tue, 28 Oct 2003, Chris Nolan wrote: > Which platform are you using? Which FS? > > Regards, > > Chris > > On Tue, 28 Oct 2003 01:14 pm, Dan Goodes wrote: > > Hi folks, > > > > I have a bit of a problem. I'm running 3.23.53 which I've compiled up from > > source (because the RPMs are not an option for me). > > > > I have a process that does a fairly large select statement every 10 > > minutes - up until a few days ago it was all find and dandy. > > > > A few days ago I did a massive delete from one of the tables (getting rid > > of a lot of old records), and since then things have gone awry. The select > > statement seems to get "stuck" in the "COPY TO tmp table" stage, and > > starts to back up fairly heavily. Each of the cron-run processes gets to > > this "COPY TO TMP TABLE" stage and locks up, which consumes all available > > slots on the server and the whole things comes to a grinding halt. > > > > I've already run an optimize table on the table, and that got rid of all > > the "empty space" freed up by the delete. > > > > Any ideas why, after the massive delete, things have started slowing right > > down (or locking up entirely)? > > > > THanks for help. > > > > -Dan > -- Regards, Dan Goodes : Systems Programmer : [EMAIL PROTECTED] Help support PlanetMirror - Australia's largest Internet archive by signing up for PlanetMirror Premium : http://planetmirror.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
