High ram-usage with multiple /16 ipv4 networks

Tue Apr 21 11:18:28 UTC 2015

When I delete the "deny all clients" rules, the ram-footage is reduced
to 35 MByte:

[root at bragi ~]# pmap -x 30521
30521:   /usr/bin/dhcpd -4 -q -pf /run/dhcpd4.pid
Adresse            kByte     RSS   Dirty Modus Zuordnung
0000000000400000    1996    1004       0 r-x-- dhcpd
00000000007f2000       4       4       4 r---- dhcpd
00000000007f3000      32      20      20 rw--- dhcpd
00000000007fb000     240      24      24 rw---   [ anon ]
0000000001eeb000    4712    4676    4676 rw---   [ anon ]
00007f9b9c8d7000   19532   19528   19528 rw---   [ anon ]
00007f9b9dbea000      44       0       0 r-x-- libnss_files-2.21.so
00007f9b9dbf5000    2048       0       0 ----- libnss_files-2.21.so
00007f9b9ddf5000       4       4       4 r---- libnss_files-2.21.so
00007f9b9ddf6000       4       4       4 rw--- libnss_files-2.21.so
00007f9b9ddf7000    1636    1380       0 r-x-- libc-2.21.so
00007f9b9df90000    2048       0       0 ----- libc-2.21.so
00007f9b9e190000      16      16      16 r---- libc-2.21.so
00007f9b9e194000       8       8       8 rw--- libc-2.21.so
00007f9b9e196000      16      16      16 rw---   [ anon ]
00007f9b9e19a000     136     112       0 r-x-- ld-2.21.so
00007f9b9e1c4000    1964    1956    1956 rw---   [ anon ]
00007f9b9e3ba000       4       4       4 rw---   [ anon ]
00007f9b9e3bb000       4       4       4 r---- ld-2.21.so
00007f9b9e3bc000       4       4       4 rw--- ld-2.21.so
00007f9b9e3bd000       4       4       4 rw---   [ anon ]
00007fffe680d000     132      20      20 rw---   [ stack ]
00007fffe689f000       8       0       0 r----   [ anon ]
00007fffe68a1000       8       4       0 r-x--   [ anon ]
ffffffffff600000       4       0       0 r-x--   [ anon ]
---------------- ------- ------- ------- 
kB gesamt          34608   28792   26292

So where can I file this bug?

Best regards

Ruben

Am Tue, 21 Apr 2015 13:07:36 +0200
schrieb Ruben Wisniewski <ruben at freifunk-nrw.de>:

> Am Mon, 20 Apr 2015 18:48:12 +0200
> schrieb Peter Rathlev <peter at rathlev.dk>:
> 
> > Hmm... I'm not sure I understand the configuration:
> > 
> > On Mon, 2015-04-20 at 17:14 +0200, Ruben Wisniewski wrote:
> > > 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;
> > >     }
> > 
> > Wouldn't the "deny all clients" statements make those ranges a
> > no-op? So each subnet has just 2558 available leases? But maybe
> > this is just testing?
> We need this deny all clients statement because of our
> routing-protocol.
> 
> The protocol is rerouting all dhcp traffic to the dhcpd-server which
> have the best connection. So all other dhcp-servers does not get the
> DHCPINFORM/DHCPREQUEST. So we need to activly deny the
> other ranges, because no other dhcp-server will respond to the querys.
> 
> Example:
> 
> The client knows the network, 10.66.0.0/16 and had the 10.66.11.2 the
> last time.
> 
> Our routing-protocol is routing the DHCPREQUEST to the server we
> discuss about.
> 
> The dhcpd get an DHCPREQUEST for 10.66.11.2 which is out of his range
> but in the subnet-definition and silently ignore the request, because
> he thinks he is not responsible for this requests.
> 
> Since we know, no other dhcpd will get this client-packages, we need
> to activly respond with DHCPNAK to change the client's status about
> his ip-address.
> 
> Now the client ask for a new lease and the dhcpd respond with an
> ip-address out of his range.
> 
> If we remove this "deny all clients" rule out of our configs, the
> clients ask several times for the old ip-address, destroy any roaming
> in the network. Any reconnect takes 12-15 seconds, depend on the
> client's implementation of dhcpd. With this rule we got an ip in under
> 1 second.
> 
> > What part is it that you see constantly increasing in that graph? I
> > see the swap doing something that looks like an asymptotic increase
> > towards some number around 1 GBytes or thereabout. Similar for
> > "committed", whatever that is in this context.
> "committed" is not used but reserved memory and can be ignored.
> 
> I think the part which is constantly increasing is the nameserver's
> cache.
> 
> > Is this a failover setup? The configuration doesn't say that, but
> > in a failover setup the servers always create all leases from the
> > beginning. The only thing that make the memory usage grow is
> > whatever extra information is added to the leases, and there might
> > even already be memory reserved for some of that in advance.
> Well not in the dhcpd-meaning. Each dhcp-server has it's range and
> just got requests for the clients he has to care about, which got be
> determined by routing protocol.
> 
>  > I'd say it looks normal. Running a DHCP server for 1.5 million
>  > leases
> > is no small feat. Running a server at all with just 512 MBytes of
> > RAM sounds like asking for trouble anyway. (RAM inflation, I know,
> > but RAM is cheap these days.)
> Actually we just use the 2558 leases, not the 1.5 million ones. Since
> the config says, that no client will ever use the other pool.
> 
> 
> 
> 
> 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/20150421/4a543701/attachment-0001.bin>