shibd Memory Usage

[Andy Bennett]

Hi,

>>> That said, you can certainly check and make sure you're not running
>>> Apache
>>> prefork to rule that out as a source of RAM spikes.
>>
>> We're not running Apache at all.
>>
>> We use the FastCGI binaries but all the memory usage is by shibd.
> 
> That isn't my point; there is no thread pool maximum in shibd, so if you
> spike it with dozens of requests, it will spin up dozens of threads, each
> with a one meg stack. That gets to be a problem if dozens turns into
> hundreds. Whether that applies to FastCGI I couldn't say, probably depends
> on the web server. Under even high load by a threaded web server, the
> number of actual simultaneous requests to shibd won't exceed a couple
> dozen and it's not noticeable.

Oh yes, I see. We're not seeing much concurrency because we only access
the FastCGIs during an actual Shibboleth Login event rather than on
every page load. Indeed, we've only got one of each of the authorizer
and responder actually running at the moment so I'd imagine that would
limit the number of threads in shibd to around 2?


>> Yes: we see it eat into swap but it doesn't degrade performance. That
>> would correlate with unused pages being swapped out and never touched
>> again.
> 
> Sounds like it. The stack spikes become a problem because it essentially
> exhausts and crashes, so if that's not the case, it's probaby not spiking.

I've never seen shibd crash.



Thanks for the help.




Regards,
@ndy

-- 
andyjpb at knodium.com
http://www.knodium.com/