-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Crazy memory usage #2527
Comments
Can we get a |
Kernel: 4.9.0-6-amd64
I won't be posting 700k lines (for |
|
Thanks. FRR always used slightly more memory than bird (around ~400MB for a full table with fib export on bird2, around ~ 1.5GB for that on frr) but suddenly allocating a steady 8GB can't be right. |
some more commands to run |
I have a recreate: |
I've just set up a FRR 5.0 (RPKI package version for debian 9 as published on the github release page). Does this happen immediatly? Can you post config and exact version (ie "show version" if built on your own, otherwise where you got the package) |
This commit gathers data from the client->obuf_fifo and puts it all into the buffer for writing. This will address the fact that the multiple events created caused the memory of zebra to grow to unrealistic levels of usage when we are redistributing data to other protocols. Recreate Memory: robot# show memory Memory statistics for zebra: System allocator statistics: Total heap allocated: 1930 MiB Holding block headers: 16 MiB Used small blocks: 0 bytes Used ordinary blocks: 1911 MiB Free small blocks: 1968 bytes Free ordinary blocks: 19 MiB Ordinary blocks: 5210 Small blocks: 58 Holding blocks: 1 New Zebra Memory: Memory statistics for zebra: System allocator statistics: Total heap allocated: 478 MiB Holding block headers: 16 MiB Used small blocks: 0 bytes Used ordinary blocks: 415 MiB Free small blocks: 1968 bytes Free ordinary blocks: 63 MiB Ordinary blocks: 4909 Small blocks: 58 Holding blocks: 1 New show threads cpu for Zebra: robot# show thread cpu Thread statistics for zebra: Showing statistics for pthread main ----------------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 0 6465.766 801 8072 54775 10810 225356 T work_queue_run 1 0.096 4 24 37 24 38 R vtysh_accept 0 8.690 533 16 54 154 6286 W zserv_flush_data 0 254.102 290 876 2224 971 6958 W zserv_write 0 1992.936 7854 253 115333 266 116288 E &zserv_process_messages 1 1.351 6 225 245 226 249 R zebra_accept 1 0.152 8 19 22 19 23 T zebra_ptm_connect 1 0.124 7 17 24 18 24 R kernel_read 1 121.460 122 995 107273 1021 108707 R vtysh_read 6 686.460 7854 87 150 93 6006 R zserv_read 0 0.040 1 40 40 39 39 T zebra_route_map_update_timer 0 0.412 6 68 170 499 1520 T if_zebra_speed_update Fixes: FRRouting#2527 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
@sybevnao -> If you have the ability to try this branch, I believe this will fix your issue. |
@sybevnao If you have a chance to test the fix from Donald, then feel free to use the packages here: These are the packages built based on Donald's fix. Feedback would be very welcome. |
This commit gathers data from the client->obuf_fifo and puts it all into the buffer for writing. This will address the fact that the multiple events created caused the memory of zebra to grow to unrealistic levels of usage when we are redistributing data to other protocols. Recreate Memory: robot# show memory Memory statistics for zebra: System allocator statistics: Total heap allocated: 1930 MiB Holding block headers: 16 MiB Used small blocks: 0 bytes Used ordinary blocks: 1911 MiB Free small blocks: 1968 bytes Free ordinary blocks: 19 MiB Ordinary blocks: 5210 Small blocks: 58 Holding blocks: 1 New Zebra Memory: Memory statistics for zebra: System allocator statistics: Total heap allocated: 478 MiB Holding block headers: 16 MiB Used small blocks: 0 bytes Used ordinary blocks: 415 MiB Free small blocks: 1968 bytes Free ordinary blocks: 63 MiB Ordinary blocks: 4909 Small blocks: 58 Holding blocks: 1 New show threads cpu for Zebra: robot# show thread cpu Thread statistics for zebra: Showing statistics for pthread main ----------------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 0 6465.766 801 8072 54775 10810 225356 T work_queue_run 1 0.096 4 24 37 24 38 R vtysh_accept 0 8.690 533 16 54 154 6286 W zserv_flush_data 0 254.102 290 876 2224 971 6958 W zserv_write 0 1992.936 7854 253 115333 266 116288 E &zserv_process_messages 1 1.351 6 225 245 226 249 R zebra_accept 1 0.152 8 19 22 19 23 T zebra_ptm_connect 1 0.124 7 17 24 18 24 R kernel_read 1 121.460 122 995 107273 1021 108707 R vtysh_read 6 686.460 7854 87 150 93 6006 R zserv_read 0 0.040 1 40 40 39 39 T zebra_route_map_update_timer 0 0.412 6 68 170 499 1520 T if_zebra_speed_update Fixes: FRRouting#2527 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
I've just upgraded the frr package using the packages provided by @mwinter-osr, after successfully installing & restarting all services, massive decrease in memory usage can be observed: Linux "free"
zebra
bgpd
BGP summary
@donaldsharp indeed seems to have spot the culprit and current usage is more than reasonable. Thanks to @donaldsharp and @mwinter-osr for your effort and the super-quick responses and follow-ups! |
@sybevnao -> If you are not using pim, then shutting it off would reduce some memory usage in zebra. ( See 6298b1f ) that I just filed. |
@donaldsharp there indeed seems to be a bit of an improvement after setting zebra
Additionally, I've just taken a look at the CPU usage of the entire system now, which seems to outperform BIRD on a system with similar specifications now: frr
bird
Good job. My hypothesis here is that frr deals better with occasional bgp updates. |
@sybevnao good to hear. I believe we still have some serious room for improvements ;) |
This commit gathers data from the client->obuf_fifo and puts it all into the buffer for writing. This will address the fact that the multiple events created caused the memory of zebra to grow to unrealistic levels of usage when we are redistributing data to other protocols. Recreate Memory: robot# show memory Memory statistics for zebra: System allocator statistics: Total heap allocated: 1930 MiB Holding block headers: 16 MiB Used small blocks: 0 bytes Used ordinary blocks: 1911 MiB Free small blocks: 1968 bytes Free ordinary blocks: 19 MiB Ordinary blocks: 5210 Small blocks: 58 Holding blocks: 1 New Zebra Memory: Memory statistics for zebra: System allocator statistics: Total heap allocated: 478 MiB Holding block headers: 16 MiB Used small blocks: 0 bytes Used ordinary blocks: 415 MiB Free small blocks: 1968 bytes Free ordinary blocks: 63 MiB Ordinary blocks: 4909 Small blocks: 58 Holding blocks: 1 New show threads cpu for Zebra: robot# show thread cpu Thread statistics for zebra: Showing statistics for pthread main ----------------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 0 6465.766 801 8072 54775 10810 225356 T work_queue_run 1 0.096 4 24 37 24 38 R vtysh_accept 0 8.690 533 16 54 154 6286 W zserv_flush_data 0 254.102 290 876 2224 971 6958 W zserv_write 0 1992.936 7854 253 115333 266 116288 E &zserv_process_messages 1 1.351 6 225 245 226 249 R zebra_accept 1 0.152 8 19 22 19 23 T zebra_ptm_connect 1 0.124 7 17 24 18 24 R kernel_read 1 121.460 122 995 107273 1021 108707 R vtysh_read 6 686.460 7854 87 150 93 6006 R zserv_read 0 0.040 1 40 40 39 39 T zebra_route_map_update_timer 0 0.412 6 68 170 499 1520 T if_zebra_speed_update PR=59228 Fixes: FRRouting#2527 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> (cherry picked from commit 3734642) Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Could anyone here explain why the memory usage of the version 5 release is literally crazy? I'm exporting one full table to a virtual machine with 8GB of memory and the entire memory is filled by that from zebra, including a fair amount of swap as well.
Memory usage for a full table used to be below 4GB in older releases.
What's the point + reason for this increase? Makes any usage of frr useless and turns anyone who doesn't want to literally and unnecessarily waste memory use bird.
The text was updated successfully, but these errors were encountered: