> > A crash was recreated by running a specific query. > > Oh. > > You didn't mention crashes in your first note. That changes > everything.
Sorry, I'm a dork. Buy crash I mean "all new connections getting stuck in authentication mode." As the day wears on my Jennifer Vernacular -> English translater is starting to buggy. :) > Yeah, if you're killing MySQL by force, you really ought to check all > tables and repir broken ones. Otherwise it's a craps shoot. My thoughts exactly. > > > We've seen that happen too on more recent FreeBSD versions with > > > LinuxThreads. So far it's not happening all that often and it seems > > > that the chance of it happening is much greater right after MySQL has > > > been [re]started. > > > > > > I haven't had much luck in tracking it down further. But I have a few > > > more ideas next time I see it. > > > > We aren't running Linux threads. We didn't seem to be experiencing > > any of the issues it helps. > > At least not the obvious ones. :-) > > We've found that on moderately busy machines here, upgrading to a > LinuxThreads-based MySQL reduced CPU utiliization by 30% or so. > This box sits around 1% all day unless something crazy's going on, but we've got another mysql box (more qps, more tables, but way less data) that could really benefit from this, thanks for the tip. > > For a while we'd only have this happen once a month, then it was > > once a week. Lately it has been a few times a day, but everyone is > > messing with box. > > Ugh. Yeah. Don't get me started, I can go on for days. > Hmm. I hadn't noticed that yet. But I hadn't thought to look at > disconnect rates either. It could be nothing, it's just the only pattern I have noticed. Unfortunately my systems knowledge isn't very strong, so I don't know if my suggestions are completely insane. The one thing I was thinking was it's has something to with releasing a lot of resources at once and not signalling that they are available again so the request just waits and waits. For some reason I'm thinking semaphores and starvation, but the only experience I really have is one OS theory course a few years ago. > I don't know how to do this with threads but with LT, I'd like to > identify a few of the pads for the struck threads and then get a > snapshot of the call stack to see where they're waiting. I'll run this by the systems guys, thanks for the suggestion. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
