Hi list,
Sorry for raising another thread on the topic. This is the original thread:
https://lists.quagga.net/pipermail/quagga-dev/2014-November/011795.html
The 6WIND VRF patch uses one daemon to manage all protocol instances/VRFs,
named here *all-inst-in-1-daemon* or *N-in-1*.
There's another thought saying why not just starting multiple daemons, each
daemon for one protocol instance, called here *1-daemon-per-inst* or
*1-for-1*.
The main discussion is around which is better, N-in-1 or 1-for-1? While,
many
comments indicate the preference with support from only experiences.
So I raise this new thread to place the practice/test statistics and then
lighten the choice.
Any comment and test result are appreciated.
This is the test topology (per VRF):
NUT1 zebra with 5 static routes
| ospfd advertising the static routes
|
| virtual ethernet
|
| zebra with 5 static routes
NUT2 ospfd advertising the static routes
I have two same machines, with Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
(4 cores) and 4G memory on each machine.
If the number of instance (I mean the instance pair zebra + ospf here) is N,
then:
for N-in-1: there will be (1 zebra + 1 ospfd)
for 1-for-1: there will be (N zebra + N ospfd)
- Memory consumption:
Num. of inst N-in-1 1-for-1
============ ====== =======
1 90M 90M
30 200M 2.7G
100 520M --
For 1-for-1, I can not start more instances if the required memory
exceeds 4G.
- Time consumption to starting all daemons:
Num. of inst N-in-1 1-for-1
============ ====== =======
1 <1s <1s
30 <1s 3s
100 <1s --
For 1-for-1, it took about 1s to start (10 zebra + 10 ospfd) in
average.
- CPU load: very low in both cases.
From my point of view:
(1) For those users who need only several instances (memory consumption MAY
be sensitive), which would be preferred, 100M or 1G?
(2) For those users who need tens of instances, which would be preferred,
300M or 5G?
(3) For those users who need 1K instances, which would be preferred, 1G or
90G?
(4) How about 2K instances?
So I prefer the solution N-in-1.
While I know N-in-1 has the shortage that it will get more harder to keep
the stable adjacencies when there are a lot of instances (e.g 1K), though
we have technical solutions.
But, how can I know 1-for-1 does *not* have the same shortage? With N-in-1
we at least can let user have 1K instances with low memory consumption and
acceptable CPU load. But with 1-for-1, we can not even test it in the lab
(sorry, we have no machines with 100G memory).
So what in my mind is:
- For most of use cases, N-in-1 is enough, with low memory consumption and
acceptable CPU load.
- For special use cases which need amount of instances (e.g. 2K), we may
need N-in-N, that is:
1 zebra + M protocol daemons (N instances in each daemon)
This is mostly the mix of N-in-1 and 1-for-1 - and this should be the
final status.
(An explanation: I made the tests with 6WIND quagga, where each daemon needs
about 45M bytes. Presently the open source quagga daemon needs about
only 22M
bytes. But, I believe that the memory consumption will grow bigger and
bigger
when we are adding new features.)
Thanks and best regards,
Feng Lu
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
