Memory Usage:
Only one cert/key. All secure access is done with the userdirs
directive https://secure.domain.com/~username the http is accessed
through the ip virtual host. Now I am using <VirtualHost
_default_:443>, I wonder if I should use a specific IP instead?
Hanging Children:
On the children hanging I believe the POST issue is directly related
because the children are shown in a keep-alive state. I will let you
know if the 2.2.5 doesn't fix the problem.
To duplicate the problem all I do is an install per your FOR JOE
AVERAGE, start the server, access the apache documention through https
with an IE4.0 browser and then click refresh on the browser rapidly
while holding the ctrl key to do a complete refresh. Within 30 secs or
so I get a hung child process. Not very scientific but repeatable.
Next time I will keep the post to a single subject to advoid confusion,
sorry......
BTW, I really appreciate your efforts to provide the internet community
with SSL in a simple way.
John
> -----Original Message-----
> From: Ralf S. Engelschall [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 17, 1999 8:52 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Runaway Children & Memory Usage (PR#120)
>
>
> On Sat, Mar 13, 1999, John Hamlik wrote:
>
> > The memory usage seems to be related to virtual hosts. If
> a person only
> > has a few virtual hosts memory usage is roughly identical.
> In my case
> > with 500+ IP virtual hosts the child process is 3 times the
> size of a
> > equilalent setup under mod_ssl-2.0.13-1.3.3. Apache 1.3.4
> configured
> > without mod_ssl-2.2.4-1.3.4 with the same number of virtual hosts
> > doesn't show a significant memory usage difference vs. Apache 1.3.3.
>
> Ok, for 500 virtual hosts you've around 500 certs/keys,
> right? Then it's
> clear: since mod_ssl 2.1 the certs/keys are cached in memory
> for restarts, and
> because a cert or key is around 1KB, the server needs approx.
> 2*500*1KB = 1MB
> more memory. And addtionally SSLeay has to cache the
> certs/keys internally for
> operation. So you again have one more 1MB. In other words,
> for each cert/key
> your server process grows about 4KB and with 500 of them
> you've 2MB more.
>
> OTOH this shouldn't harm, because the 2MB of data are created
> on startup time
> and after the fork() they are used read-only. So with all
> modern Unix kernels
> (copy-on-demand!) you do not actually waste 2MB per httpd
> process, of course.
>
> > I still believe there is a problem regarding the children hanging.
>
> Children hanging? But what has the above memory usage to do
> with children
> which hang? Sorry, seems I've lost the context.
>
> > I just built a new RedHat5.2 server and installed apache-1.3.4,
> > mod_ssl-2.2.4-1.3.4 and openssl-0.9.c with just the default
> configuration
> > per FOR JOE AVERAGE. In less than two minutes under light
> https load child
> > processes will start to hang. I have yet to hang a child
> on http traffic. I
> > just can't believe I am the only one having trouble with
> this, aargh!...
> > Anyway for now I guess I just have to stick with apache-1.3.3 and
> > mod_ssl-2.0.13-1.3.3 which has been up and stable in our
> clusters since Oct
> > 15. I am really tempted to build a FreeBSD box just to
> check it out.
>
> Hmmm.... I don't know, but perhaps the hangs you discovered
> are related to the
> POST-problems I've now fixed. You should try again with 2.2.5
> when it comes
> out. OTOH, how can I see this myself? Is there any
> deterministic way to
> reproduce this hangs? I currently cannot reproduce it with the current
> 2.2.5-pre version.
> Ralf S. Engelschall
> [EMAIL PROTECTED]
> www.engelschall.com
> ______________________________________________________________________
> Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
> Official Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
