Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 557
    • Issues 557
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 65
    • Merge requests 65
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • KeaKea
  • Issues
  • #415
Closed
Open
Issue created Jan 16, 2019 by Michal Nowikowski@godfrydContributor

there are memory leaks found by valgrind in case of Kea and Radius configuration

I have performed some memory testing of Kea with Radius configuration. I configured Radius with 50.000 clients. I enabled Radius access and accounting in Kea configuration. Then I run perfdhcp this way:

sudo perfdhcp -4 -bmac=08:00:27:f9:00:01 -l enp0s10 -R 49000 -d1000 -r 1000 -f 1000 -t 4

I'm not sure if it was working as I expected. I expected that:

  • perfdhcp will sent DHCP Discovers for 49000 clients starting from MAC 08:00:27:f9:00:01
  • it will be sending 1000 requests / 2 and the same rate for renewals
  • as results it will force Kea to make lots of access and accounting requests to Radius

The results are attached as kea-mem.png. Memory usage was continuously growing. kea-mem

Then I used valgrid to check for leaks:

sudo  valgrind --leak-check=yes kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf

7 minutes of testing generated attached report. It finds some memory leaks:

==26647== LEAK SUMMARY:
==26647==    definitely lost: 264,624 bytes in 6,971 blocks
==26647==    indirectly lost: 27,138,956 bytes in 232,087 blocks
==26647==      possibly lost: 11,954 bytes in 41 blocks
==26647==    still reachable: 72,722 bytes in 23 blocks
==26647==         suppressed: 0 bytes in 0 blocks

valgrind-report.txt

Edited Jan 16, 2019 by Francis Dupont
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking