I'm using ntpd in an embedded Linux system, just to discipline my own
local clock.  Many of my third party developers are complaining to me
about the ntpd process's memory usage.  Top is showing me RSS=3404
SHARED=2988, and when I run ntpd for the first time I'm seeing free
memory drop by 1.93MB.

I don't know why NTP should take almost 2MB for my simple
configuration.  I disable most of the drivers.  Here is my configure
invocation:

../configure --build=i386-pc-linux-gnu --target=mipsel-linux --host=mipsel-linux --disable-ACTS --disable-ACTS --disable-ARBITER --disable-ARCRON-MSF --disable-AS2201 --disable-ATOM --disable-CHRONOLOG --disable-CHU --disable-AUDIO-CHU --disable-DATUM --disable-DUMBCLOCK --disable-FG --disable-HEATH --disable-HOPFSERIAL --disable-HOPFPCI --disable-HPGPS --disable-IRIG --disable-JJY --disable-JUPITER --disable-LEITCH --disable-LOCAL-CLOCK --disable-MSFEES --disable-MX4200 --disable-NEOCLOCK4X --disable-NMEA --disable-ONCORE --disable-PALISADE --disable-PCF --disable-PST --disable-PTBACTS --disable-RIPENCC --disable-SHM --disable-SPECTRACOM --disable-TPRO --disable-TRAK --disable-TRUETIME --disable-TT560 --disable-ULINK --disable-USNO --disable-WWV --disable-ZYFER --disable-COMPUTIME --disable-DCF7000 --disable-HOPF6021 --disable-MEINBERG --disable-RAWDCF --disable-RCC8000 --disable-SCHMID --disable-TRIMTAIP --disable-TRIMTSIP --disable-WHARTON --disable-VARITEXT --disable-audio --without-crypto --program-prefix=

Here is my ntp.conf:

  server <server address>
  disable monitor
  restrict default nopeer

Can anyone recommend steps I can take to reduce ntpd's memory
requirement?

Thanks,
Dave

In article <m3acmvropb.fsf@bfnet.com>,
David Wuertele <dave-gnus@bfnet.com> wrote:

> Can anyone recommend steps I can take to reduce ntpd's memory
> requirement?

Reduce the size of libc by eliminating things that are not actually required
by your application.  ntpd locks itself into RAM and given the bloated size
of Red Hat's libc, this means locking a lot of library code into RAM.  The
2988 shared represents libc (and maybe some smaller shared libraries).

Not quite so good an alternative is to statically link ntpd.  That will
likely use more RAM than a libc that reflects the system's real needs.
Having a libc that does reflect true needs will mean that the shared
component of the footprint may actually not cost any RAM for ntpd.

David> Reduce the size of libc by eliminating things that are not
David> actually required by your application.  ntpd locks itself into
David> RAM and given the bloated size of Red Hat's libc, this means
David> locking a lot of library code into RAM.  The 2988 shared
David> represents libc (and maybe some smaller shared libraries).

I don't know how to determine how much of that 2988 is actually used
by other apps --- I expect a lot of it is, and in any case I don't
have control or even visibility into what those apps need because I
have a lot of third party developers using the platform.

But there's also 1.9MB that is *not* shared by other apps, and it
seems excessive to me.  That won't get reduced by trimming libc or
statically linking ntpd.  Is there any way I can cut this down to
something more respectable?

Dave

In article <m3is1irdqm.fsf@bfnet.com>,
David Wuertele <dave@rokulabs.com> wrote:

> But there's also 1.9MB that is *not* shared by other apps, and it
> seems excessive to me.  That won't get reduced by trimming libc or

Most of this is in libc and *will* be reduced by pruning libc.  SHARED
means that the region from which the memory comes from is shared and
the pages are resident for the specific process.  It doesn't mean that
the pages are resident for multiple processes.  The memory increase is
the total of the size of ntpd, and of the size of library code and
data that is in the library but hasn't been loaded into the working
set of any other application.

> statically linking ntpd.  Is there any way I can cut this down to

Most of that will *not* get linked in with the static link.  However, the
static link will duplicate pages that are common to other applications.

> something more respectable?

The actual size of ntpd is less than 500K on your figures, and a significant
part of that may be data associated with unused libc code.

Your only other choice is to not lock ntpd into RAM, in which case timing
accuracy will be severely compromised as ntpd poll intervals will almost
certainly guarantee that it will be entirely paged out between polls on
a system that does any significant "disk" I/O.

Please see http://ntp.isc.org/bin/view/Dev/NewNtpConfFormat#Memory_locking
because on *some* platforms we can control how much memory we lock.

If you are Comfortable with knowing how your system will behave, you can
also build NTP with this locking disabled (edit config.h) which will do what
you want.  You can also wait for (or help fix) the open bug on sntp
https://ntp.isc.org/bugs/show_bug.cgi?id=370 (And I think Anil is waiting
for me to get him access so he can fix it) and try that instead.

Note that we are expecting some changes to the SNTP code as the NTP IETF WG
makes more progress there (http://ntp.isc.org/IETF) .

H