pcp
[Top] [All Lists]

Secure sockets builds have high daemon memory utilisation

To: Dave Brolley <brolley@xxxxxxxxxx>
Subject: Secure sockets builds have high daemon memory utilisation
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Mon, 9 Jun 2014 23:26:59 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1847964481.23206323.1402368934163.JavaMail.zimbra@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: 6mNlgiod+A4WNgyXcV2spFjnIq3Jdw==
Thread-topic: Secure sockets builds have high daemon memory utilisation
Hi Dave,

I was staring at some memory stats this morning, thinking to
myself... hmm, ya know, I don't remember pmcd taking up quite
this much memory - what gives?

So, I tried a few different build combos, enabling/disabling
certain PMDAs and so on, but the biggest hit seems to be from
simply enabling secure sockets in the build.  This covers a
fair bit of territory (nspr, nss, ssl, sasl), so not sure if
its any particular one of them or the combination of all yet.

For comparison, first line below is a pmap memory summary for
a secure-sockets build, the second is --without-secure-sockets
- both measured just after pmcd startup:

[PID]   /usr/libexec/pcp/bin/pmcd
Address           Kbytes     RSS   Dirty Mode   Mapping
----------------  ------  ------  ------
total kB          262760   11704    1728
total kB          112868    2276     552

So, secure sockets gives a ~5x resident set size.  In the case
of pmproxy, its closer to 10x...  :(

[PID]   /usr/libexec/pcp/bin/pmproxy
Address           Kbytes     RSS   Dirty Mode   Mapping
----------------  ------  ------  ------
total kB          249560   12652    3324
total kB           99848    1284     228

Which is pretty disappointing, given that most people wont be
using encryption/non-af_unix authentication at all.  I wonder
if we could get crafty and load the secure sockets support in
an "on-demand" fashion?

We do have both forms of networking still there in the code of
course - could we find a way to bootstrap in the security libs
only if they are actually needed?  (i.e. run time linking, via
dlopen(3) trickery, instead of compile time linking).

Thoughts?

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>