Re: [Speedycgi-users] Memory leak in speedy_backend

[PW <sub...@me...>]

Thank you for your feedback, Sam. Actually, I just discovered that I am 
in fact already using SpeedyCGI v2.21, not v2.11, since last October 
2002. And yes, all domains run under the same Apache user id. I applied 
your hint to "use" instead of "require" modules, as well as to preload 
the entire utilized module set in the main application. However, the 
described behavior in terms of memory growth and excessive port 
connections remains the same.

The idea to hard/soft link the application is interesting, however, will 
this strategy preserve the ENV vars of each virtual host (which the app 
depends on to distinguish between the hosts)? If yes, this might be the 
route to take.

Thanks -- Ph. Wiede


Sam Horrocks wrote:
> Groups help when you have many different scripts that you want to run
> within a single interpreter.  If your only concern is a single cgi-bin
> script, groups won't make a difference.  But using groups won't hurt,
> as long as your code is OK running that way.
> 
> In addition:
>     - Make sure all the domains run under the same user id.
> 
>     - Make sure all domains use the same exact file.  If you have multiple
>       copies of the script (for example one copy per virtual host), it
>       wont work right - each copy will have a different inode in the
>       filesystem, and therefore its own package (with groups),
>       or its own interpreter (without groups).  If you need to put the
>       same script in multiple locations, make sure to use links (hard or
>       soft) instead of copying the file.
> 
>     - As much as possible use "use" instead of "require" to load modules.
> 
>     - If your application involves multiple scripts in a single group,
>       make sure that all scripts "use" all the modules that the scripts
>       in that group will need.  That way no matter which script is started
>       first, the interpreter will compile into the parent all the
>       modules that group will need.
> 
>     - Upgrade to the latest version - there is more sharing of compiled code
>       in 2.20 and later, and there is better control on the number of
>       backends spawned.
> 
> 
> 
> 
>  > Thanks for taking the time to reply, Sam. I'm using the speedycgi apache=20
>  > module v2.11 with Apache/1.3.23 (Unix).
>  >  > As to the socket connections, with netstat -a the UDP connections are=20
>  > shown to be caused by the HTTPD process. There are around 100 virtual=20
>  > hosts.
>  >  > As I said the memory leaks are caused by the speedy childs not the=20
>  > backend. I have found the cause by now, it's not a leak but seems to be=20
>  > my misunderstanding of the group feature. Say, I have 10 domains running=20
>  > the same Perl application (named for this example "Tracker", utilizing=20
>  > identical modules) each out of their CGI-BIN, using the same speedycgi=20
>  > group id. Tracker's persistent vars are initiated only if undefined, as=20
>  > is a database sizing 3 MB that is then loaded into memory. So the domain=20
>  > that is first accessed launches Tracker and the speedycgi backend via a=20
>  > SSI call. This works as  documented - one backend, one child process=20
>  > (ore more depending on traffic).
>  >  > But my understanding was that the loaded speedycgi backend would treat=20
>  > all Trackers with the same group id as one application across all=20
>  > virtual hosts. Unfortunately, this is not the case as speedycgi seems to=20
>  > treat each domain's Tracker as an unique application in terms of=20
>  > Namespace and variables. The supposed "memory leak" is just caused by=20
>  > each domain's Tracker loading its own static vars and database instead=20
>  > of this being done once and globally by the first launched Tracker.
>  >  > Why is this so? How can one preload a set of modules to be reused by=20
>  > applications sharing the same group id? Or is this feature not=20
>  > implemented (yet :)?
>  >  >  > Thanks -- Ph. Wiede