cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 8

Request: Look into improving performance of IPAM_spTouchGroupCounts Stored Procedure

Jump to solution

Hi,

I've noticed for a while now that the time it takes for IPAM to make a modification to an IP Address seems to depend on how deep the IP Address is nested in the subnet hierarchy. Which is to say, performance is reasonable if the IP Address is only one or two Subnet/Supernet deep, but if it's 7 or 8 subnets deep, it can take up to 15 seconds to commit a change to a single entry. During this long commit time the CPU on the Database server is generally pegged at 100%.

I've done the ususal troubleshooting, and am fairly convinced it's just the way IPAM works. The database server meets reccomended specs, and ipam performs well under all other circumstances.

I did some digging with SQL Profiler etc, and came to the conclusion that the culprit (as in taking well over 90% of the duration of a commit) is the 'IPAM_spTouchGroupCounts' stored procedure. From what i can tell, this stored procedure recursively hops back up the tree structure in order to calculate the number of allocated/free IP's on every subnet/supernet along the tree. This makes sense - the larger the subnet/supernet tree the longer it takes as it will find more subnets to calculate.

Not sure if much can be done about it, but it does cause dealing with bigger network topologies to be a pain. It's probably not something that most run into - this topology is pretty big. Approx 8000 rows in the IPAM_Group table and 450,000 in the IPAM_Node table.

Perhaps there could be an option to disable IPAM from running this stored procedure after every change and for it to be put on a nightly/weekly schedule. I know that given the option between always accurate subnet counts and a responsive GUI, we would defiantly prefer a more responsive GUI.

Regards,

Luke

0 Kudos
1 Solution
Level 11

Luke, which IPAM version do you use? The performance of the IPAM_spTouchGroupCounts stored procedure was significantly improved in IPAM 3.0 which was released few weeks ago. If this is the version you use, please send me a personal message here on thwack. We would like to investigate this issue further, but first we need more information about your environment.

Thanks

Jan

View solution in original post

0 Kudos
2 Replies
Level 11

Luke, which IPAM version do you use? The performance of the IPAM_spTouchGroupCounts stored procedure was significantly improved in IPAM 3.0 which was released few weeks ago. If this is the version you use, please send me a personal message here on thwack. We would like to investigate this issue further, but first we need more information about your environment.

Thanks

Jan

View solution in original post

0 Kudos

Hi Jan,

Thanks for the info.

I was running 2.0.1. You are correct regarding version 3.0's performance increase on this stored procedure, we've noticed a very significant speed increase when making changes to nodes in long chains of nested subnets. It's gone from 10-20 seconds to around 2-3.

Cheers,

Luke

0 Kudos