Re: [OSM-dev-fr] Fwd: [contact] [Remarque, suggestion à propos de ce site] Source code of http://osm102.openstreetmap.fr/~jocelyn/polygons/
Le 09/11/2012 09:44, Christian Quest a écrit : Jocelyn, ton code est publié quelque part ? Yep, je viens de le publier sur github: https://github.com/jocelynj/osm-polygons-generation Le code n'est pas vraiment utilisable en tant que tel: il faut une base osmosis derrière, et rajouter une table à la base de donnée via le init.sql. Je vais répondre directement à celui qui t'a contacté. Merci, Jocelyn ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev] 404 from Apache2/mod_tile
On 09.11.2012 20:37, Stefan Elspaß wrote: This is indeed the case, but sometimes - in these seldom cases when rendering on the first request works - the command RenderPrio instead of command Dirty appears in /var/log/syslog (see below). Does that indicate that it might by a load-related decision from mod_tile? mod_tile does read system load: get_load_avg() If this is higher than config value ModTileMaxLoadMissing then 404 is returned. But you should see this in the logfile. Can you enable level info? ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, Load larger max_load_missing (%d). Return HTTP_NOT_FOUND., scfg-max_load_missing); Stephan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 404 from Apache2/mod_tile
Stefan Elspaß wrote Hi Kai, If I read your renderd log correctly, mod_tile is sending rendering requests with priority dirty rather than the missing priority. The dirty priority is a background priority in which mod_tile does not wait for the result and immediately returns the tile (or in case of a missing tile a 404). This is indeed the case, but sometimes - in these seldom cases when rendering on the first request works - the command RenderPrio instead of command Dirty appears in /var/log/syslog (see below). Does that indicate that it might by a load-related decision from mod_tile? So the question is why does mod_tile send the requests with the incorrect priority? This should only happen if the load average is above the configured max missing load. Your configurations do look fine though. Do you know by chance what unit ModTileMaxLoadMissing uses? Is it a percentage? The settings for the log below were as follows: The load is in units of number of processes that are wanting CPU time. It is the load number you get from /proc/loadavg. So if you have a load average of 500 on a 1 core system, then each process only gets 1/500th of a CPU and will be dog slow. The load numbers should therefor typically be not too much more than the number of CPU cores you have. Therefore unless something is drastically wrong with your server, you really shouldn't be seeing a load of 500. Stefan Elspaß wrote Can you increase the debug level of mod_tile to debug and then post your apache error.log again? The debug output unfortunately currently doesn't tell you what mod_tile thinks the load on the server is, but at least it would confirm if this is the cause and what the configuration is set to. In /etc/apache2/site-available/default I changed the log-value by changing the line to LogLevel debug. Is there any other way to increase the debug level of mod_tile? No, that is the correct way to increase the debug level of apache. And setting it to debug, will include all of the other levels like info warning and error. However, apache does not log to syslog. It has its own error.log file. It can typically be found in /var/log/apache/error.log Kai -- View this message in context: http://gis.19327.n5.nabble.com/404-from-Apache2-mod-tile-tp5734970p5735220.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 404 from Apache2/mod_tile
Hi, Am 10.11.2012 um 18:01 schrieb Kai Krueger kakrue...@gmail.com: Do you know by chance what unit ModTileMaxLoadMissing uses? Is it a percentage? The settings for the log below were as follows: The load is in units of number of processes that are wanting CPU time. It is the load number you get from /proc/loadavg. So if you have a load average of 500 on a 1 core system, then each process only gets 1/500th of a CPU and will be dog slow. The load numbers should therefor typically be not too much more than the number of CPU cores you have. Therefore unless something is drastically wrong with your server, you really shouldn't be seeing a load of 500. I compiled mod_tile again with svn-r28921 containing today's change from apmon which writes the actual load into error.log. The result is strange: [info] [client xx.xx.xx.xx] Load (1202590843) larger max_load_missing (50). Return HTTP_NOT_FOUND., referer: http://..xx/ Quite some high load, isn't it? I hadn't time yet to dig deeper but will do that the coming days. If in the meantime someone has an idea: feel free to share :-) Greetings, Stefan___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 404 from Apache2/mod_tile
Stefan Elspaß wrote I compiled mod_tile again with svn-r28921 containing today's change from apmon which writes the actual load into error.log. The result is strange: [info] [client xx.xx.xx.xx] Load (1202590843) larger max_load_missing (50). Return HTTP_NOT_FOUND., referer: http://..xx/ Quite some high load, isn't it? I hadn't time yet to dig deeper but will do that the coming days. If in the meantime someone has an idea: feel free to share :-) It looks like there was a bug in mod_tile. It was missing an include of sys_utils.h and so the compiler was interpreting the return value of get_load_avg() as an int whereas it was a double resulting in totally bogus load values. Please do another svn update and check if this is fixed now? Kai -- View this message in context: http://gis.19327.n5.nabble.com/404-from-Apache2-mod-tile-tp5734970p5735268.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
