This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Polling Engine Capacity Planning?

I am trying to figure out how to do some capacity planning with my polling engines.  I have found several posts on how this may be done but I don't see any solid conclusions on a methodology.  Specifically, I need to know how this would be done when running multiple SolarWinds modules on these engines, not just NPM.  We are currently running NPM, SAM, IPAM and NCM and I need to know how to understand where my capacity limitations are and plan out when I will need to add an additional poller.

Can somebody at SolarWinds please provide some insight on this, preferable a KB article or White Paper but just a response here would be a good start, thanks!

  • My experience is that there are no hard and fast numbers to be able to pull to get the modeling you are talking about. I've got 8 pollers running NPM and SAM. On some of them they are spiked to 90% utilization (SolarWinds calculation of that) with 8000 elements. On another poller (same installation) I have 9000 elemnets but 70% utilization. Ditto for the SAM side of things.

    I know that can be a maddening answer, but some of it has to do with the complexity of the devices on the poller, the response time of the devices (an old 6509 will take much longer to report it's CPU than a new 2900); some has to do with the complexity of the data you are collecting (custom UnDP, SAM templates, etc); some has to do with teh polling frequency if you are adjusting it on a per-box basis; and some has to do with the module (NetFlow COULD hammer your system depending on how much data is being exported).

    ...and so on...

    My suggestion is to call your sales rep, get him to set up a conference with one of the engineers who is familiar with all the modules you have (or are considering) and they can give you a sense of what to expect.

    THEN as you are implementing, you need to keep a watchful eye on the stats. I have a custom report that pulls all the data into a single screen for all the pollers, so I can see at-a-glance how healthy my pollers are and when it's time to either move items around or load up a new one.

  • Thanks for taking the time to respond with that much detail; for better or worse that was my understanding as well.

    I would absolutely love to see the dashboard you have created if it's something you can and are willing to share.

    P.S.  With that many pollers I really feel bad for you when Orion upgrades are necessary.

  • Geez and I felt bad for adding a 4th poller today.....I agree this is something I'd love to see SW produce.  I monitor my polling engines about once a month to see where we stand.

  • What I think would be nice is being able to install an Orion update on the platform system and then have all of the pollers auto-magically pick up and install the updates from the platform system.  I know I taking an over simplified view of things when suggesting this but as a user it would really be nice.

  • It sounds like the 8k - 10k elements is still one of the best data points to use when figuring capacity for NPM; the polling engines page does a great job of showing you this number.

    Next question is how to factor SAM into the picture; I don't know how to figure how many component monitors I have on each poller and/or what the threshold numbers for those are.  I want to say I have seen 10k application components as the threshold per poller, if so is that in addition to the 8k - 10k NPM elements?

  • Honestly it's not that bad. The upgrade to SAM 5.5 (including a MIB file update) took about 3 hours including validation and babysitting.

  • I uploaded it to content exchange a while ago, but here's an updated version:

  • Glad to help. Don't forget to like the content. I'm 410 points away from 11th level!

    emoticons_happy.png