fatal error on wiki....

Hi,
Im getting the following message:
Fatal error: Allowed memory size of 12582912 bytes exhausted (tried to allocate 556741 bytes) in /var/www/wiki.openstreetmap.org/includes/Parser.php on line 312

when opening this page:
http://wiki.openstreetmap.org/index.php/Map_Features

(might not be the correct place to report, but could not find anything better…)

The problem is widely known (caused by the size of the map feature pages) and I guess ppl are working on it.

You can still read them page for page in the Map features Category

I’ve just edited Map Features to kind of fix the problem. But it’s a bit crippled. The server couldn’t cope with all the template inclusions on that page.

If you look at this old revision (Map Features with all template inclusions)…
http://wiki.openstreetmap.org/index.php?title=Map_Features&oldid=84725
…it’s giving “Fatal error: Allowed memory size of 12582912 bytes exhausted (tried to allocate 537789 bytes) in /var/www/wiki.openstreetmap.org/includes/MagicWord.php on line 279”

This might mean we need to scale back on the number/complexity of wiki template inclusions.

Or it may actually be a memory shortage on the wiki VM (which maybe someone can fix)

This is a fairly urgent thing we should try to fix. Obviously it doesn’t look too good cosmetically speaking, at the moment, and also it’s difficult to search. It has also meant that a lot of translated information is lost, temporarily until we solve this.

There are two angles on the problem. I suspect that the server genuinely is low on memory, because back on Saturday it seemed to slow down and die all together, which surely means it’s not too healthy, so I’m hoping that one of the System Administrators is actually investigating, but I guess I should contact them directly to check if they’re doing anything.

But the other thing is perhaps we can scale back on the tree of template inclusions we have set up there. I’m not exactly sure what type of thing is using a lot of memory particularly, but I imagine it must be the sheer number of included templates. I’m thinking one idea might be to avoid using {{IconNode}}, {{IconWay}}, and {{IconArea}} everywhere, just reference the images more directly.

However there’s a concern I have, that by reducing template inclusions (going for less clever/elegant arrangements of wiki information) all we do is delay some enevitable out-of-memory error cropping up elsewhere in the wiki as the server gets worse.

The question itself is, if a change in the memory allocation (raise the allowed memory) will help in the long run.

It is not the first time the Map Feature page run into this kind of problems.
I don’t have a good knowledge about the wiki system backgrounds and how to avoid this problem. So my guess is we could try to simplify the site with your mentioned reduction of the {{Iconxxx}} templates. Furthermore we could get rid of the photo and rendering columns as this information can be found in the subpages that describes the tags more precisely.

Other than that we could separate the Map feature list from the wiki and show a complete list as simple html webpage instead. I wrote a small perl lib that is able to parse all available pages (Map Features, Key:xxx, Tag:key=value pages and categories etc) from the wiki and create a translated html version of the original Map Feature page.

My original intention was it to offer a xml based version for further usage of all known tags.
Only problem so far I never finished it since I’m a bit busy with my bachelor thesis right now.

This might mean we need to scale back on the number/complexity of wiki template inclusions.

Note that if you retrieve a version of the page “before” the template inclusions, e.g.:
http://wiki.openstreetmap.org/index.php?title=Map_Features&oldid=71404

and click on “edit” and “preview”, you will see the same error:
Fatal error: Allowed memory size of 12582912 bytes exhausted (tried to allocate 506949 bytes) in /var/www/wiki.openstreetmap.org/includes/Parser.php on line 358

although the page only use templates for nodes, ways and areas icons…

just to say that removing templates will not resolve the problem but postpone it (if any).

I see 3 solutions:

  • increase the memory allocated for PHP/wiki
  • the “Map Features” page is just collecting the links to the “Key:*” pages but the page looses its overview and completeness capacity.
  • the “Map Features” page provides a full list of all key/values but in a light form (no table, no pictures, no links).

My preference goes to the third solution. The templates could be modified with an optional “light version” flag. Based on the flag, the template could deliver two different outputs:

  • the “light version” just displays the list of keys, values and descriptions; no pictures, no rendering examples, no “node”, “way” or “area” templates, no tables, no links (excepted one to the “Key:*” page)
  • the “heavy version” called by the “Key:*” pages themselves displaying the tables as they are today.

The advantage of this is that we maintain the list of values in a single page and we keep the facility for internationalization.

I tried swapping out the {{IconWay}} for redirect image references. Doesn’t seem to have solved anything

For the wiki administrator:
the PHP environment is currently limited to 12MB (said in the error report “Allowed memory size of 12582912 bytes exhausted”).
A short look on the mediawiki:
http://www.mediawiki.org/wiki/Manual:Errors_and_Symptoms#Fatal_error:Allowed_memory_size_of_xxxxxxx_bytes_exhausted.28tried_to_allocate_xxxx_bytes.29

says:
Fatal error: Allowed memory size of xxxxxxx bytes exhausted (tried to allocate xxxx bytes)
Raise PHP’s memory limit in php.ini:
memory_limit = 32M ; Maximum amount of memory a script may consume (32MB)

(also on other forums talking about this topic, e.g. http://www.mwusers.com/forums/archive/index.php/t-3806.html))

I see that the wiki server is a VM using 512MB (http://wiki.openstreetmap.org/index.php/Servers/vm).

I don’t think that allocating 20Mb more (12Mb → 32Mb) for the wiki would have a serious impact on the server.

And with this value, it will still be possible to display most of the common tags in a single page.

yeah. could be a good thing to try. I guess I’ll ask a system administrator to do that.

There’s two different places we can make this setting. Either in php.ini doing “memory_limit = 32M;” or in LocalSettings.php in the wiki with ini_set( ‘memory_limit’, ‘20M’ );

…depending on if we want to up the memory on all PHP scripts running on that server, or just the wiki scripts. Probably better to do it in LocalSettings.php dunno if php.ini changes require a restart to be picked up.

Yes, you are probably right.
But do you know who is the administrator of this server ? Did you already contact him ?
Because the problem is not fixed since almost a month and nothing happen…
Or is some other activities planned on this server at the same time (hardware migration, updates, etc…) ?
or shall we raise a new alert on the ML ?

Read the mailing list discussion that was up in march, and then decide if it need to be fixed…

Perhaps using a wiki isn’t the best idea for what the main map features page is used for…

TomH is the System Administrator I’ve been able to contact about wiki issues occasionally. I know he upgraded mediawiki to the latest version about a week ago. That didn’t fix the problem…

…but something did! Today I’ve been able to restore the old revision with all the template inclusions. I dont know why, but the server seems happier again. A bit faster in general too I think. Somebody did something?

Anyway maybe this is only a temporary lull in the memory problem. So it would still be a good idea to think about solutions. The server is still thinking for a while to generate the Map Features page every time.

Thomas linked to this: http://en.wikipedia.org/w/index.php?title=Wikipedia:Template_limits&oldid=174802700

I haven’t puzzled through what the parser is doing with its counters, but I was interested to note that having lots of documenation in sections can be a factor. Need to look into it in more detail.