I’ll be in Brussles for FOSDEM from Friday to Sunday, if anyone wants to meet me please drop me a note on hartmut@php.net.
I’m not giving any talk this year, and having no other duties either, so I’m very flexible time wise 🙂
A playground for OSM related stuff
I’ll be in Brussles for FOSDEM from Friday to Sunday, if anyone wants to meet me please drop me a note on hartmut@php.net.
I’m not giving any talk this year, and having no other duties either, so I’m very flexible time wise 🙂
Yesterday afternoon the rendering daemon failed in an interesting way, the preview images were rendered for most map requests, but not the actual map files.
It turns out that the root cause was a rendering request for a rather large area that consumed all available memory, leading to a short phase of swapping, and eventually a hard out-of-memory kill. Somehow the rendering service didn’t recover from this properly, and so the following requests were not properly processed either.
I thought I had memory issues covered in the renderers systemd service, by setting LimitRSS, the apparent systemd equivalent for “ulimit -m”.
But it turns out I had been “StackOverflowed” on this. Looking at the systemd.exec man page I learned that:
“LimitRSS= is not implemented on Linux, and setting it has no effect.”
Now I have replaced LimitRSS in the renderers service file with MemoryMax, and this actually seems to do the job. I re-ran all failed requests. This time the “bad” request still failed as it consumed too much memory, but it failed when reaching the set limit of 50% of total RAM already, without driving the system into swapping, and the following requests were properly processed again.
Hopefully this now has fixed “runaway memory” issues once and for all, not by preventing them in the first place, but by properly handling them when they occure, letting just that one render request fail, but not the following ones in the queue.
The site has been upgrated to use Bootstrap v4 instead of v3, which allows for a few HTML simplifications and visual improvements.
Look and feel shouldn’t have changed too much, the most notable change for now being that the UI language and map locale dropdowns now also show country flags for easier orientation.
On special request during 35C3 I’ve added an “Allotment” style overlay that renders allotment plot borders and plot numbers:
I actually added the ability to add a QR code on the map to the renderer backend quite a while ago, but up to now it was only accessible via a command line parameter when starting the renderer directly.
This has now changed, and the web interface now offers a new QR code effects overlay. For now the endoced text is fixed to the request URL of the rendered map itself, but as soon as I’ve finished my plans for allowing for input of extra overlay customization parameters the QR code content will be freely customizeable.
I’ve started to add some hyperlinks to the multipage PDF output, now that CairoGraphics and PyCairo support this.
For now only the “next page” arrows on the edges of the detail map pages are linked to the target pages in the PDF:
UPDATE: The page rectangles on the overview now link to the detail pages, too
In recent weeks I have exeprimented with some user interface improvements again. None of these really changed the workflow, so they should be rather intuitive. But I still think that they improve the user experience a little bit.
Last week this MapOSMatic instance processed its 40,000s map request, for a map of Sindelfingen, Germany.
While request numbers per day are fluctuating quite a bit there’s an obvious, but slow upwards trend, with typically over a hundred requests processed per day.
Fun fact: over the last year activity slowly shifted from peaks on weekends to higher activity on regular weekdays.
If you want to have a look for yourself: here are the Munin monitorign graphs
I’m preparing to move to new (faster and more affordable) server.
If all goes well I’ll move services over to the new machine on Sunday evening (September 30th, 18:00UTC).
During the switchover the service will be offline for an hour or two, for moving over existing rendering results to the new machine and doing some testing.
After that rendering should be a little bit faster as all databases will fit on the machines SSDs then, and there will be enough “rotating rust” HDD space for keeping rendered results around for a few months instead of just a some two weeks again.
The OSM Carto standard style, and its German countarpart, have been upgraded to v4.15.0.