Hi Paul,
So you have a complex historical "mess" and its not clear where the
performance issue is. So you need to divide the problem into small
problems that you can verify are or are not contributing. I would start
with something like this:
Take one slow image request and try that as cgi or cli and not fcgi and
turn on debugging.
- copy and rename you mapfile so it doesn't mess with the production
requests
- turn on the debugging and send it to stderr in the debug mapfile
- you can manually run that image request from the commandline like:
if mapserv is not in your path you might need to find it and your the
path to it below
mapserv -nh QUERY_STRING="everything after the ? in the original query"
>junk.png 2>error.txt
-nh suppresses headers from being output before the image data
error.txt will be stderr output and should contain the debug messages
Then report back what you find out.
-Steve W
On 7/22/2020 1:47 PM, English Paul wrote:
Hi,
Newbie here, just got a work assignment to look into some
performance issues with mapserver-6.0.1-3_0.el6.x86_64 – specifically,
at one time, it rendered radar images very fast, then it degraded and
seemed to consume a lot more CPU. So – the EC2 instance side was
upgraded significantly – and it still performs badly and uses a lot of
CPU. It also seems to be getting slowly worse over time (days/months,
not seconds/minutes). I asked this on IRC, but it looks like email
might be a better route.
During all of this, the same mapserver instance renders satellite
images quickly. These seem to be a similar, or in some cases larger
size png to start with, rendered onto the same final map/size.
So – the obvious answer is that it isn’t using the CPU to
render/re-render, but rather spending it on something else – I/O most
likely – eg: a network request, disk I/O, SQL query?
The previous person working on it tried turning on debug at various
levels – but unfortunately that made it even slower, making it tricky
to answer “what is making it slow when debug is turned off?”
My first instinct was to try an strace and nothing was obvious. Next
up – a flame graph from strace, and/or trying dtrace – but my
understanding is that dtrace is a little weak on RHEL/CentOS/Amazon
Linux 6.0 **and** I’m not particularly good at that. Also, we’re using
fcgi, so attaching to the correct process is a bit tricky.
My next instinct was to look at release notes and see if the current
stable has anything fixes/improvements that directly address this –
there aren’t any that are obvious to my eyes, but you developers have
been busy! So many things! Including some performance fixes and one
“significant” performance fix.
Current config file:
AddHandler fcgid-script fcgi
FcgidIPCDir /var/run/mod_fcgid
FcgidProcessTableFile /var/run/mod_fcgid/fcgid_shm
FcgidMaxProcesses 10
FcgidMaxProcessesPerClass 10
FcgidMaxRequestInMem 196608
FcgidInitialEnv PROJ_LIB /usr/share/proj
FcgidInitialEnv LD_LIBRARY_PATH "/usr/local/lib:/usr/pgsql-9.1/lib"
So – suggestions for my next move? I currently plan to take a quick
swing at building 7.6 for RHEL 6.0, knowing there might be old
libraries and whatnot that make that a non-starter. Of course – we’ve
got other infra running on this same instance, so upgrading everything
is a much bigger task.
Strace flame graph?
Stretch and try dtrace?
A better way to use debug?
Something else I’m missing – eg: differences between the image types
that make them perform so differently?
Thanks,
Paul
_______________________________________________
mapserver-users mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-users mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/mapserver-users
