Hi,
We've written a content management web application using mono, mod_mono & apache running on a slackware 10 (client's choice, not ours) server. We've got two problems. The first is an intermittent hang - whereby the mono processes are still running but no longer serve requests. Killing all mono processes or restarting apache gets the site responding again. We're still working on that one and have a workaround in place, of more concern is the other problem: the site just gobbles up memory until it uses all available and then, particularly on the production box, the whole server falls over. We've had to take the site off the production server now and are running a static version of the site.
My question is: is anyone running a busy site using mod_mono on apache? Have they noticed memory usage issues? We're working with an average of 50,000 hits a day on the production server, so it doesn't take long for the server to fall over.
I've tried a few different configurations, to try and narrow it down, but all of these have problems:
- Run the site on Red Hat Enterprise WS, with mono installed from RPMs, apache ( 2.0.50 ) from source
- the site runs fine on windows, but that's not really relevant so I won't mention it..
- Slackware 10 / mono 1.0.5 / mod_mono 1.0.5 / apache 2.0.52 (all installed from source)
- Slackware 10 / mono 1.0.5 / mod_mono 1.0.5 / apache 2.0.50 (all installed from source, three different machines)
- Slackware 10 / mono 1.1.3 / mod_mono 1.0.5 / apache 2.0.50 (all installed from source)
- on Slackware 10 / mono 1.0.5 / mod_mono 1.0.5 / apache 2.0.50:
-- using an aspx page with only response.write in it
-- using an aspx page with no server-side code at all
-- adding GC.Collect() at various points in the code
We've been building the app while several versions of mono have been released - we started on 1.0.1, so I've also tested on:
- Slackware 10 / mono 1.0.2 / mod_mono 1.0.5 / apache 2.0.50 (from source)
- Slackware 10 / mono 1.0.2 / mod_mono 1.0.2 / apache 2.0.50 (from source)
As well as the Red Hat distribution we've had a look at both debian and Suse and have noticed memory leaking on them too. My concern isn't so much that memory usage increases, it's that there is no limit to it and that the mono processes don't restart when they've consumed a huge amount of resource.
Basic configuration is something like this:
Apache install: ./configure --prefix=/usr/local/apache2 --enable-rewrite --enable-headers --enable-expires
Mono: ./configure --with-apxs=/usr/local/apache2/bin/apxs
Mod_mono: ./configure
*** Httpd.conf changes: ***
LoadModule mono_module modules/mod_mono.so
MonoRunXSP True
MonoUnixSocket /tmp/mod_mono_server
AddType application/x-asp-net .aspx .ashx .asmx .ascx .asax .config .ascx
MonoApplications "/:/web/http"
<Directory "/web/http">
AddHandler mono .aspx .ascx .asax .ashx .config .cs .asmx .htm
<FilesMatch "\.(aspx|ascx|ashx|config|cs|asmx|htm)$">
SetHandler mono
</FilesMatch>
# This rather convoluted bit is because RequestHeader & Header won't return normal env vars
# and also won't just echo env vars
RewriteEngine ON
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) /404b.aspx [E=URI:%{REQUEST_URI}]
RequestHeader set URI %{REDIRECT_URI}e
Options FollowSymLinks ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>
*** End httpd.conf changes ***
If I set a load generator on a simple aspx page served by a server configured like this, the memory usage simply increases until eventually the server gives up.
I've also tried using MonoMaxMemory and MonoMaxCPUTime but for me max CPU time has no effect and max memory stops ASP.NET pages responding once the limit is reached. I'd expected the mono processes to recycle, avoiding any memory issues but whatever I do, the processes don’t seem to restart. Should they? I did see it happen once on one of the earlier configurations when the GC was turned off ( I was testing something.. ) but am unable to replicate now.
Any advice appreciated. Even with these problems at the end of a long project, I'm still keen to use mono for this and future projects - it's a fine piece of work.
Thanks
Mark Prins
