From: Reini U. <ru...@x-...> - 2005-04-02 13:01:29
|
SourceForge.net schrieb: > Bugs item #1153483, was opened at 2005-02-28 08:01 > Message generated for change (Comment added) made by uckelman > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=106121&aid=1153483&group_id=6121 > > Category: version 1.3.x (experimental) > Group: Installation > Status: Open > Resolution: Later > Priority: 5 > Submitted By: Peter Lundqvist (p3l) > Assigned to: Reini Urban (rurban) > Summary: crao theme breaks installation > > Initial Comment: > It seems (tried a few times with fresh database) that > the virgin wiki won't load using the crao theme. It > stops after > > Loading Virgin Wiki > %BODY% > > Switching to the default theme, loading the virgin wiki > and then switching back solves the problem if you want > to use the crao theme. > > ---------------------------------------------------------------------- > > >>Comment By: Joel Uckelman (uckelman) > > Date: 2005-04-01 20:18 > > Message: > Logged In: YES > user_id=245140 > > Ok, what I'm seeing is clearly due to hitting a memory > limit, not to any peculiar properties of the pages being loaded: > > [client 128.104.60.232] PHP Fatal error: Allowed memory > size of 8388608 bytes exhausted (tried to allocate 9749 > bytes) in /home/uckelman/projects/phpwiki/lib/ziplib.php on > line 829 > > Why does loading a fresh wiki take such an enormous amount > of memory? Are all the pages kept in memory simultaneously > prior to being written to the DB? Hmm. That memory hunger started with 1.3.4 when output buffering for our templates was introduced. Before we preg_replace'd the vars and did some simple logic with magic ### markers. This was fast and needed no memory at all, but lead to dirty template syntax. The big thing is really a php bug, the various Load/SavePages loop, which doesn't free its internal memory after rendering each page. Either a) we go back to the previous template solution without output buffering inside our template expansion, or b) we introduce a 3rd party template lib (Smarty). a) Will not work with a few templates anymore. We are not allowed to assign vars anymore in php (no major problem) and we may not loop (just a problem for non-critical plugins). We do have some IF. Some FOR may be easily introduced also, if really needed. b) Smarty will introduce another major 3rd party lib dependency (as adodb, pear DB, ...), but would solve all these problems. Other templating systems in php5 pecl are in sight also. wikilens already introduced Smarty, but not as general template system, just for their user-editable templates. With Smarty we could go this step also and allow users edit the templates. But this will be a big step. I delayed this decision for middle of this year. > ---------------------------------------------------------------------- > > Comment By: Joel Uckelman (uckelman) > Date: 2005-04-01 20:01 > > Message: > Logged In: YES > user_id=245140 > > I've investigated this problem a bit and found the following: > > When loading a virgin wiki (using every theme I've tried), > it stops while loading ReleaseNotes. Refreshing the page > causes the remainder of the pages to be loaded. > > I'm not sure yet whether something about the ReleaseNotes > page is causing the problem, or if some memory or process > limit is being hit. If I delete ReleaseNotes from pgsrc, > loading continues up to PhpWikiPoll, and stops there. > Deleting PhpWikiPoll lets the initial load progress a bit > farther. I repeated this through several iterations, but > didn't reach the end of the load process without reloading > the page first. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban http://phpwiki.org |
From: Reini U. <ru...@x-...> - 2005-04-03 10:13:38
|
Joel Uckelman schrieb: > Thus spake Reini Urban: >>That memory hunger started with 1.3.4 when output buffering for our >>templates was introduced. >>Before we preg_replace'd the vars and did some simple logic with magic >>### markers. This was fast and needed no memory at all, but lead to >>dirty template syntax. >>The big thing is really a php bug, the various Load/SavePages loop, >>which doesn't free its internal memory after rendering each page. > > I wonder whether strategic placement of a few unset()'s would mitigate the > problem? I thought that data was garbage-collected when the ref count dropped > to zero. Is it possible that we have a circular reference somewhere? I actually unset every possible var, and also checked the destructors with possible external ressources (mysql handles and query results). It could be a circular ref left over. But I searched for almost one year for such a beast and found nothing. So I rather suspect it's php itself, which I didn't compile for memory tracing, yet. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban http://phpwiki.org |