Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. RE: Server hangs at startup - issue with lock file
(Jeremy C. Reed)
2. Re: kea-dhcp4 - benchmarks (memfile and mysql) (Tomek Mrugalski)
3. RE: Server hangs at startup - issue with lock file
(Chaigneau, Nicolas)
4. RE: kea-dhcp4 - benchmarks (memfile and mysql)
(Chaigneau, Nicolas)
5. RE: kea-dhcp4 - benchmarks (memfile and mysql)
(Chaigneau, Nicolas)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Sep 2014 10:47:22 -0500 (CDT)
From: "Jeremy C. Reed" <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: Server hangs at startup - issue with lock file
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 16 Sep 2014, Chaigneau, Nicolas wrote:
> Here is the output of "autoreconf -vv --install" (until it hangs):
Thanks.
...
> : command not found
> : command not found
I still don't see in there what was missing. Maybe you can run the parts
step by step to see if can identify where problem is:
aclocal
libtoolize --copy # or glibtoolize
autoheader
automake --add-missing --copy
autoconf
------------------------------
Message: 2
Date: Tue, 16 Sep 2014 21:18:13 +0200
From: Tomek Mrugalski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>, kea-dev
<[email protected]>
Subject: Re: kea-dhcp4 - benchmarks (memfile and mysql)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 16.09.2014 16:15, Chaigneau, Nicolas wrote:
> Hello again, and first thanks for the detailed answer.
>
> First about the memfile mode.
>
> I agree the 4100 leases/s I measured is a good value, probably more
> than enough. Note that at that rate, I'm running at a bit less than
> 100% CPU on the core handling the process. I don't experience any
> packet loss (if I try a higher lease rate/s, then I reach 100% CPU,
> and at this point things start to get ugly).
>
> For reference, this was with a lease file on RAMDISK, replicated
> through DRBD in order to ensure there is no data lost in case of
> hardware failure.
>
> I also tested the memfile with "persist" set to false (disk
> operations disabled); in this case, I get up to 4900 leases/s.
> Again, the limiting factor for me is the CPU; I assume I would get
> more on a more powerful hardware.
Interesting. Our 8000 value was measured almost a year ago. We did add
extra code since then, but I would have thought the impact would be
smaller. But the differences are probably due to other hardware
configuration.
> About the possibility of writing the lease file only on shutdown:
> that may be interesting to some, but that's not a compromise we can
> settle with. Hardware failures can happen, even sometimes software
> crash (not to say it would happen with Kea, but we have to assume
> the worst). We want to be able to recover the leases in such a case.
Sure. This is not something we would recommend users to do in normal
circumstances, just as mitigation/recovery technique for a disaster that
already happened. But I see that the performance gain (extra 800
leases/sec) is not that big, so maybe it isn't worth the effort...
> About postgreSQL: I have no plans to test with postgreSQL for now.
> (not that it's not a good DB, but time is limited, so unless there
> are very good reasons to assume it would be better than MySQL, I
> won't be able to... sorry)
Understood.
> The fact that Kea is not multi-threaded is disappointing. Our server
> has 24 cores, 23 of which are hence sitting idle... and only one at
> almost 100% CPU (when testing the limit on a memfile). I hope you
That's somewhat disappointing, I agree. On the other hand, if you get
the performance you need on a single core, the desire to use other cores
is somewhat lessened. Also, as Francis said, it's not about explicitly
going for multiple threads, just to be able to use more cores.
> can add support for multiple cores in the future :) (any idea when
> this "one day" might be ? I won't hold you to it, this is just to get
> a rough estimate)
We will do it for sure, the question is not if, but when. Obviously, I
can't make any specific promises, but for now we have plans made until
summer 2015 and multi-process support is currently not expected in that
timeframe. After we reach 1.0, we'll definitely be looking at the next
feature to implement and taking advantage of multiple cores is
definitely one of potential next features.
Personally, I'm a bit hesitant to implement multi-core support as soon
as possible. There are large deployments that could benefit from it, but
a typical user will never need it and the current performance should be
sufficient. On the other hand, there will be lots of complications with
multi-process architecture, so we're likely looking at additional pains
experienced by both developers and users.
Having said that, we're an open source shop. It is unlikely, but
possible that someone will develop such support and send us a patch. On
the other hand, ISC is actively looking for Kea sponsors. It is possible
that someone come in to us and say: Here's $$$$, do the multi-core thing
sooner.
Tomek
------------------------------
Message: 3
Date: Wed, 17 Sep 2014 07:05:13 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "Jeremy C. Reed" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: Server hangs at startup - issue with lock file
Message-ID:
<ab94b0b675bdf14189cd5a861db36c841418e...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
The first command (aclocal) hangs.
I've tried to run it with strace; I noticed the following (I don't know if it's
a problem or not):
stat("acinclude.m4", 0x20dd130) = -1 ENOENT (No such file or directory)
And just before it hangs, the following errors:
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd6159ce0) = -1 EINVAL (Invalid
argument)
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> On Tue, 16 Sep 2014, Chaigneau, Nicolas wrote:
>
> > Here is the output of "autoreconf -vv --install" (until it hangs):
>
> Thanks.
>
> ...
> > : command not found
> > : command not found
>
> I still don't see in there what was missing. Maybe you can run the parts step
> by step to see if can identify where problem is:
>
> aclocal
> libtoolize --copy # or glibtoolize
> autoheader
> automake --add-missing --copy
> autoconf
>
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
------------------------------
Message: 4
Date: Wed, 17 Sep 2014 08:52:19 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Tomek Mrugalski <[email protected]>, kea-dev <[email protected]>
Subject: RE: kea-dhcp4 - benchmarks (memfile and mysql)
Message-ID:
<ab94b0b675bdf14189cd5a861db36c8414193...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
Some update (and very good news).
I've run again the benchs with MySQL, with only one parameter changed, as you
suggested:
innodb_flush_log_at_trx_commit = 2
(instead of the default of 1)
This changes *everything*.
I'm now able to serve 800 leases/s (instead of 50, with the default value of
innodb_flush_log_at_trx_commit).
As compared to 4900 with a memfile with lease file on RAMDISK.
(And 70 for dhcpd with lease file on RAMDISK).
This is a simple preliminary bench scenario with only DORA for new clients, but
still valid as a comparison standpoint.
And it's promising :)
I understand that changing this parameter entails that we're not "ACID"
anymore, and can lose about 1 second of data in case of a crash.
This means losing at most 800 leases, which is acceptable.
Thanks again for your help.
Regards,
Nicolas.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
------------------------------
Message: 5
Date: Wed, 17 Sep 2014 08:58:15 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>, Tomek
Mrugalski <[email protected]>, kea-dev <[email protected]>
Subject: RE: kea-dhcp4 - benchmarks (memfile and mysql)
Message-ID:
<ab94b0b675bdf14189cd5a861db36c8414193...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
> Hello,
>
>
> Some update (and very good news).
>
> I've run again the benchs with MySQL, with only one parameter changed, as you
> suggested:
>
> innodb_flush_log_at_trx_commit = 2
>
> (instead of the default of 1)
>
>
>
> This changes *everything*.
>
> I'm now able to serve 800 leases/s (instead of 50, with the default value of
> innodb_flush_log_at_trx_commit).
> As compared to 4900 with a memfile with lease file on RAMDISK.
4100, not 4900 (4900 is without writing the leases to disk).
> (And 70 for dhcpd with lease file on RAMDISK).
>
> This is a simple preliminary bench scenario with only DORA for new clients,
> but still valid as a comparison standpoint.
> And it's promising :)
>
>
>
> I understand that changing this parameter entails that we're not "ACID"
> anymore, and can lose about 1 second of data in case of a crash.
> This means losing at most 800 leases, which is acceptable.
>
>
>
> Thanks again for your help.
>
>
> Regards,
> Nicolas.
>
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 6, Issue 12
**************************************
