-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mapnik spends most of its time in font cache misses #4406
Comments
What I can say from stracing Looking at the mod_tile source it will walk it's configured font directories and call I don't think that That said I don't see why that causes the symptoms we see - if anything I'd expect it to cause crashes! |
Actually I think I see the problem - the local map is populated (but the local cache isn't as Interestingly if the font wasn't found in the local map we would fall back to the global map and would then check the global cache, but without taking the mutex which isn't safe when multithreaded. |
With debugging openstreetmap/mod_tile#333, I got to a Mapnik issue.
When run on OSMF servers, renderd normally consumes about 20% of CPU, regardless of load except for periods every ~8 minutes where it goes to 100% CPU and produces tiles at a normal rate. Attaching GDB when it was not producing tiles at a normal rate revealed 75% of the threads were in a mutex in
mapnik::freetype_engine::create_face_impl
. The one mutex in that function is for if a font file was found but is not yet in memory:mapnik/src/font_engine_freetype.cpp
Line 376 in d69a090
My reading of the function is that most of the time, the font should already be in memory and it won't hit the mutex. I don't know why this isn't happening.
The server is running the latest Mapnik release (3.1.0 (3.1.0+ds-1ubuntu2)) with OpenStreetMap Carto v5.7.0, which has a fairly long fonts list because it attempts to support all scripts.
There are some oddities I can't explain
The text was updated successfully, but these errors were encountered: