[pmwiki-users] PmWiki seems to "hang" on overloaded boxes

Patrick R. Michaud pmichaud at pobox.com
Sun May 22 12:30:24 CDT 2005


On Sun, May 22, 2005 at 06:10:09PM +0200, Joachim Durchholz wrote:
> Patrick R. Michaud wrote:
> >>>At 08:11 AM 5/22/2005, Joachim Durchholz wrote:
> >>>>Here's what happened: PmWiki suddenly started to "hang", i.e.
> >>>>it would not respond at all, or display only part of the output
> >>>>and "hang". With "hang", I mean that the browser still has the 
> >>>>data-is-forthcoming animation, but no new data ever arrives.
> >>>>(For an "forever" value of one or two minutes.)
> >
> >First and most importantly, what version of PmWiki?
> 
> 2.0beta28.

Yup, that's likely the issue.  There may also be issues with interactions
between session-based authentication and the .flock file; beta30
takes care of these also.

> >Second, note that by the time PmWiki is outputting information to the
> >browser, PmWiki has pretty much completed any "real work" that needs 
> >to be done and is simply doing lots of print statements.  

> Hmm... I had at least one occasion when PmWiki had output the header and
> left sidebar, but didn't output the right sidebar and main content. (For
> that specific skin, the output order is header -> left sidebar -> right
> sidebar -> page, via CSS.)

FWIW, in terms of "when things are converted to HTML", it's page, 
header, left sidebar, right sidebar.

> No, I'll have to upgrade. I wasn't too happy with the ramifications of
> some of the announced changes (not sure anymore which ones, but there
> were some), so I decided to stop upgrading unless necessary. 

Totally understandable -- I just know that beta28 and beta29 substantially
increased the potential for deadlocks to develop, which is why I redid the
locking system for beta30.

> I'm somewhat surprised by that result though. If PmWiki managed to 
> output top margin and sidebar, it probably died while rendering the 
> rightbar. However, that doesn't really make sense: the only reason why 
> it could have died without giving an error message might be a shutdown 
> from Apache because it exceeded some resource limit, but I don't think 
> it's taking that long or that that much memory! So where's the fault in 
> the logic?
> On a tangent, what's the best way to see how much time a page took?

The diag.php module includes a "stopwatch" function that can give some
idea of how long things are taking -- see, for example, the bottom of
http://www.pmwiki.org/wiki/Main/AllRecentChanges?skin=stopwatch .

> >I ran into similar problems such as this in the distant past, and I
> >finally traced the problem to Apache.  When a browser closed a 
> >connection before output was completed (or even begun), Apache would 
> >sometimes block indefinitely, never returning control back to PmWiki 
> >nor killing off the PmWiki process.
> 
> Ah, that's something that has been bugging one of my PmWiki
> installations. Do you recall which part of the Apache configuration was
> responsible for that?

No, I didn't have access to any the Apache configuration on the system
exhibiting the problem, so I wasn't able to troubleshoot it beyond
noting it as a problem with Apache.  We built some other workarounds
into the system, including a way for authors to be able to break the
.flock when it occurred.  (However, AFAIK it hasn't occurred at all since
beta30.)

Pm



More information about the pmwiki-users mailing list