-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bgpd: generate json by default for [l]communities and aspaths #16654
Closed
pguibert6WIND
wants to merge
4
commits into
FRRouting:master
from
pguibert6WIND:trial_separate_permanent_from_non_permanent
Closed
bgpd: generate json by default for [l]communities and aspaths #16654
pguibert6WIND
wants to merge
4
commits into
FRRouting:master
from
pguibert6WIND:trial_separate_permanent_from_non_permanent
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
By default, json representation of AS paths is only done if the user uses the json keyword when using show command. Add a configuration command to change this behavior, at BGP initialisation. The behavior is kept unchanged. Signed-off-by: Philippe Guibert <[email protected]>
By default, json representation of large communities is only done if the user uses the json keyword when using show command. Add a configuration command to change this behavior, at BGP initialisation. The behavior is kept unchanged. Signed-off-by: Philippe Guibert <[email protected]>
By default, json representation of communities is only done if the user uses the json keyword when using show command. Add a configuration command to change this behavior, at BGP initialisation. The behavior is kept unchanged. Signed-off-by: Philippe Guibert <[email protected]>
2 tasks
The show bgp ipv4 detail json command takes a lot of memory, and on Linux, when reading a full route, the resulting VM size of the bgp daemon has increased from 10.2 GB to 19.2 GB (the measure has been done with the pathch of the below link. The hypothesis is that the memory management is culprit: on Linux, pages are allocated to host memory blocks. When those memory blocks are no more used, any empty page should be made available. If the page is not freed, this probably means that some memory blocks have not been freed. The troubleshooting shows that some data of bgp entries store the json format when the usage is requested. That would imply that for a given page, some memory blocks will remain after the show, and others not. In order to separate both usages on a shared page, do choose to allocate the json output of bgp aspath, bgp communities, and bgp large communities at startup. The number of additional allocations done at startup is measured: - 130472 aspaths - 18471 communities - 1308 large communities The memory measurement is given for information and does not show any significative improvement since only the initial VM size has changed frmo 1663832 KB to 2137220 KB. > root@dut-sureau-nianticvf:~# ps -aux | grep bgpd > root 7702 83.3 14.5 1663832 1485640 ? Ssl 08:14 1:56 /usr/bin/bgpd -A 127.0.0.1 -M snmp -M rpki -M bmp > root@dut-sureau-nianticvf:~# time vtysh -c "show bgp ipv4 json detail" > /tmp/showbgpipv4detailjson.txt > > real 0m30.286s > user 0m2.796s > sys 0m5.565s > root@dut-sureau-nianticvf:~# ps -aux | grep bgpd > root 7702 75.7 19.2 2137220 1959064 ? Ssl 08:14 2:23 /usr/bin/bgpd -A 127.0.0.1 -M snmp -M rpki -M bmp Link: FRRouting#16498 Signed-off-by: Philippe Guibert <[email protected]>
pguibert6WIND
force-pushed
the
trial_separate_permanent_from_non_permanent
branch
from
August 26, 2024 09:45
22afecb
to
388e62d
Compare
ton31337
reviewed
Aug 26, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this more like a demonstration? How the "default" can be changed (if this not for demonstration-only)?
This is for demonstration. I would have expected better improvements. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The show bgp ipv4 detail json command takes a lot of memory, and
on Linux, when reading a full route, the resulting VM size of the
bgp daemon has increased from 10.2 GB to 19.2 GB (the measure
has been done with the pathch of the below link.
The hypothesis is that the memory management is culprit: on Linux,
pages are allocated to host memory blocks. When those memory
blocks are no more used, any empty page should be made available.
If the page is not freed, this probably means that some memory
blocks have not been freed. The troubleshooting shows that some
data of bgp entries store the json format when the usage is
requested. That would imply that for a given page, some memory
blocks will remain after the show, and others not.
In order to separate both usages on a shared page, do choose to
allocate the json output of bgp aspath, bgp communities, and
bgp large communities at startup.
The number of additional allocations done at startup is measured:
The memory measurement is given for information and does not show
any significative improvement since only the initial VM size has
changed frmo 1663832KB to 2137220 GB.
Link: #16498