Hi Lenz, thanks a lot for your reply!
> Is that a self-compiled binary or one of ours? It are the MySQL-4.0.13-MAX-RPMs from your site. > Not very helpful. Does this occur under high load only? Yeah I know, otherwise I would have tried to generate a reproducible testcase with a given query or such. Any way to have valid pointers there? Nope, the load on that system is mostly around 0.5 with peaks up to 1.5, not something I would call a high load for a dual-system. Also the crashes are at many different times (even in the deep night) so I don't think its related to load :-(. > What version of glibc is this system running on? Is it 2.2.3 by chance? Nope, sorry. Its glibc-2.2.4-32. > What version of glibc is being used on that system? I noticed that you use > the "Max" binary, which is dynamically linked - so it will use the locally > installed libc.so. Is there any special reason for using Max? Or could you > try to use our statically linked Standard binary instead? Yeah I could try that instead, maybe I should try with 4.0.13 to see if its a problem of that version. Or should I better try 4.0.14 already? I was hosting a couple of bdb-tables for some time, but no longer now. Currently only myisam and innodb-tables so I could try the standard-built too. > The problem above looks very similar to the problems we had when we linked > against glibc 2.2.3 instead of 2.2.5: under high load, a mysqld thread > starts eating up all CPU resources on an SMP system. Unfortunately we > never found the reason for that - it did not seem to happen when using > glibc 2.2.5... Hmm, maybe 2.2.4 has the same problem? The problem is that the init-process is taking all the cpu, didn't see a mysql-process doing the same before. Thanks, Thomas -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
