On Friday 10 March 2006 13:25, Magnus Hagander wrote: > > > > Could it be they broke it when they did that???? > > > > > > In theory, yes, but it still seems a bit far fetched :-( > > > > Well, I rolled back SP1 and am running my test again. Looking > > much better, hasn't locked up in 45mins now, whereas before > > it would lock up within 5mins. > > > > So I think they broke something. > > Wow. I guess I was lucky that I didn't say it was impossible :-) > > > But what really is happening. What other thread is actually holding the > critical section at this point, causing us to block? The only places it > gets held is while looping the signal queue, but it is released while > calling the signal function itself... > > But they obviously *have* been messing with critical sections, so maybe > they accidentally changed something else as well... > > What bothers me is that nobody else has reported this. It could be that > this was exposed by the changes to the signal handling done for 8.1, and > the ppl with this level of concurrency are either still on 8.0 or just > not on SP1 for their windows boxes yet... Do you have any other software > installed on the machine? That might possibly interfere in some way? Just a JDK, JBoss, cygwin (running sshd), and a VNC Server. I don't think that interferes. > > But let's have it run for a bit longer to confirm this does help. I turned it off after 2.5hr. The longest I had to wait before, with less load, was 1.45hr. > If so, > we could perhaps recode that part using a Mutex instead of a critical > section - since it's not a performance critical path, the difference > shouldn't be large. If I code up a patch for that, can you re-apply SP1 > and test it? Or is this a production system you can't really touch? I can do whatever the hell I want with it, so if you could cook up a patch that would be great. As a BTW: I reinstalled SP1 and turned stats collection off. That also seems to work, but is not really a solution since we want to use autovacuuming. > > //Magnus jan -- -------------------------------------------------------------- Jan de Visser jdevisser@xxxxxxxxxxxxxxxxxx Baruk Khazad! Khazad ai-menu! --------------------------------------------------------------
