High ram-usage with multiple /16 ipv4 networks

Ruben Wisniewski ruben at freifunk-nrw.de
Mon Apr 20 15:14:21 UTC 2015


Dear list,


we use the isc-dhcp on virtual-servers, which are connected via tunnels
to open wifi-hotspots, which are spread all around in some citys.

We use a layer2 mesh-protocol, batman-adv, for routing from the servers
to the hotspots. So each city is one broadcast-domain and got a
ipv4 /16 subnet.

Shortened: We use the dhcp-server in a very dynamic enviroment, with
several thousand different clients per day. But since we got several
regional L2-Network, the clients usualy move around in the network
without asking the dhcpd for a new lease.

One of our smaller virtual servers got 512 MByte of ram, on this server
we got issues because of the ram-usage of the dhcp server:

[root at bragi ~]# /usr/bin/dhcpd --version
isc-dhcpd-4.3.2
[root at bragi ~]# pmap -x 3174
3174:   /usr/bin/dhcpd -4 -q -pf /run/dhcpd4.pid
Adresse            kByte     RSS   Dirty Modus Zuordnung
0000000000400000    2000     624       0 r-x-- dhcpd
00000000007f3000       4       4       0 r---- dhcpd
00000000007f4000      32      20      16 rw--- dhcpd
00000000007fc000     240      24      20 rw---   [ anon ]
0000000001709000   50980    2100     392 rw---   [ anon ]
00007f758d881000  472112  259264   15928 rw---   [ anon ]
00007f75aa58d000      44       0       0 r-x-- libnss_files-2.21.so
00007f75aa598000    2048       0       0 ----- libnss_files-2.21.so
00007f75aa798000       4       0       0 r---- libnss_files-2.21.so
00007f75aa799000       4       0       0 rw--- libnss_files-2.21.so
00007f75aa79a000    1636    1240       0 r-x-- libc-2.21.so
00007f75aa933000    2048       0       0 ----- libc-2.21.so
00007f75aab33000      16      12       0 r---- libc-2.21.so
00007f75aab37000       8       8       8 rw--- libc-2.21.so
00007f75aab39000      16      12      12 rw---   [ anon ]
00007f75aab3d000     136     124       0 r-x-- ld-2.21.so
00007f75aab67000    1964     252      64 rw---   [ anon ]
00007f75aad5d000       4       4       4 rw---   [ anon ]
00007f75aad5e000       4       4       0 r---- ld-2.21.so
00007f75aad5f000       4       4       4 rw--- ld-2.21.so
00007f75aad60000       4       4       0 rw---   [ anon ]
00007ffee1b13000     132      24      20 rw---   [ stack ]
00007ffee1bd4000       8       0       0 r----   [ anon ]
00007ffee1bd6000       8       4       0 r-x--   [ anon ]
ffffffffff600000       4       0       0 r-x--   [ anon ]
---------------- ------- ------- -------
kB gesamt         533460  263728   16468
[root at bragi ~]# du -h /var/lib/dhcp/dhcpd.leases
776K    /var/lib/dhcp/dhcpd.leases

Since the dhcpd uses this much ram, the system is swapping excessively,
and once an hour, when the dhcpd is writing it's leasefile to disk, the
dhcpd stuck for three minutes, without answering any request.

Our dhcp.conf looks like this, but with 25 subnets on different
interfaces:

ddns-update-style none;
ignore client-updates;
deny declines;
one-lease-per-client true;
ignore bootp;
default-lease-time 600;
max-lease-time 800;
min-lease-time 60;
ignore-client-uids true;
authoritative;
log-facility local7;

subnet 10.66.0.0 netmask 255.255.0.0 {
    range 10.66.11.1 10.66.20.255; #main
    pool {
        range 10.66.1.1 10.66.10.255;
        deny all clients;
    }
    pool {
        range 10.66.30.1 10.66.254.255;
        deny all clients;
    }
    option broadcast-address 10.66.255.255;
    option routers 10.66.11.0;
    option domain-name-servers 10.66.11.0;
    option ntp-servers 10.66.11.0;

    interface subnet-x;
}

[...]

The ram-consumption is the same when the daemon is starting with an
empty lease-file. And is constantly increasing on runtime:

http://i.imgur.com/60QgMe2.png


So my question is, it this much ram-consumtion expected or a bug? 


Best regards

Ruben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Digitale Signatur von OpenPGP
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150420/31975ed6/attachment.bin>


More information about the dhcp-users mailing list