Hi!

Tomas> Sorry for the late reply. Tomas> I have not been able to find the situation, that triggers the problem.

Tomas> But it definitely is not related to some particular query or code, it Tomas> just depends on machine load.

Tomas> But two days ago, I doubled the amount of RAM in the machine, and the Tomas> problem really seems to disappear.

Tomas> The system has been stable for more than two days since the upgrade was Tomas> done. Compared to the crashes that usually occured many times a day, I Tomas> am sure the system is OK now.

Tomas> But it really is very strange that something like low amount of memory Tomas> can trigger such problems. The system even did not use swap space ...

Tomas> I also suppose the "mysql daemon hangs on Suse" problem, that you Tomas> discuss here now, in fact is the SAME problem - at least the indications Tomas> are the same. The admin of machine involved really should check his Tomas> syslog for the "sigpending lied" messages. When the crash occurs, new Tomas> processes are not spawned out immediately - it takes about three minutes Tomas> until the first one new process is spawned, so maybe the admin did not Tomas> noticed that the amount of processes actually slowly grows.

Tomas> Regards, Tomas> Tomas Styblo Tomas> adm...@cyberspace.cz

I have during the weekend tried to find a problem with signals during pthread_create() on Suse 6.3 Linux-Alpha and I found something that I can repeat that indicates that sometimes during high load LinuxThreads misses a signal that is required for pthread_create() to work. The missed signal will lock up MySQL completely :)

I am this week travelling in Europe but I will next week make an independent test case that I will mail the linuxthread developer so that he can find and fix this bug!

In MySQL 3.23.16 we have added a thread cache that helps a lot in avoiding this bug, but we still need to get this fixed!

Regards, Monty