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.

SAM Polling Rate after update to NPM 11.5 / SAM 6.2.0

Since the update to NPM 11.5 and SAM 6.2.0, including Orion Core 2015 Hot Fix #4 and SAM 6.2 Hot Fix #1 the polling rate for SAM has been inaccurately stuck at 100%. I have even rebuilt the poller entirely and the value went from 103% to 100%. The reason I'm pretty sure this is inaccurate is that it is polling less about the same as my other servers and the busiest I have is 61% SAM with the VM only having 10 cores. I've even doubled the VM's resources from 8 cores to 16 and it didn't dent that number despite the VMWare Performance counters looking much better, the host counters looking much better, and the CPU rarely spiking above 30%. I suspect there is another threading value somewhere that I need to change. On this poller we had to change the amount of Synchronization threads (found by support for an issue where NextPoll was consistently in the past) from 3 to 15 as it is a remote site however all of the nodes that it is assigned are local. Prior to the update SAM was no where near 100%.If anyone has an idea on things to try, that would be great.

This is the problem poller in question. Let's call it "A". Was 103% with 8 vCPUs, increased to 16 vCPUs without change. Took a reinstall to move from 103% to 100%.

2015_04_04_13_25_09_Daedalus_daedalus_Remote_Desktop_Connection.jpg

Here's the numbers expected, Let's call it "B".

2015_04_04_13_27_31_Daedalus_daedalus_Remote_Desktop_Connection.jpg

Thanks in advance!

  • It's hard to get a sense for the number of component being monitored from poller details view. Can you post a screenshot of the SAM License Summary View [Settings -> SAM Settings -> SAM License Summary]

    SAM License Summary.png

  • Allowed Number of Component Monitors: unlimited

    Total Number of Component Monitors: 21490

      Licensed Component Monitors: 21490

      Unlicensed Component Monitors: 0

    Available Component Monitors: unlimited

  • I got it to drop to 70% by deleting just about everything. Still not quite making sense to me. Doubling the cores should have dropped that value significantly just like it did on the other pollers.

  • How many if any additional pollers do you have? Each poller (including the primary) can support upwards of 8-10k components. 20,000+ components would require at least one Additional Poller.

  • We have 4. I did a lot of housekeeping and usage is almost nothing on most of the boxes, except for that same questionable box.

    1. This is another remote site within 8ms latency of the poller in question.

    Polling Completion99.99
    Elements4659
    Network Node Elements410
    Volume Elements2409
    Interface Elements1840
    SAM Application Polling Rate12% of its maximum rate.» Learn more
    Polling Rate36% of its maximum rate.» Learn more
    Hardware Health Polling Rate1% of its maximum rate.» Learn more
    VIM.VMware.Polling2
    UnDP Polling Rate0% of its maximum rate.» Learn more
    Routing Polling Rate0% of its maximum rate.» Learn more
    Fibre Channel Polling Rate0% of its maximum rate.» Learn more
    UCS Polling Rate0% of its maximum rate.» Learn more
    Total Job Weight1430
    Number of HW Health Monitors46
    Number of HW Health Sensors2625

    2. This is the poller that is over representing its load.

    Polling Completion100
    Elements7198
    Network Node Elements1433
    Volume Elements2844
    Interface Elements2921
    SAM Application Polling Rate70% of its maximum rate.» Learn more
    Polling Rate56% of its maximum rate.» Learn more
    Fibre Channel Polling Rate0% of its maximum rate.» Learn more
    Routing Polling Rate0% of its maximum rate.» Learn more
    UCS Polling Rate0% of its maximum rate.» Learn more
    UnDP Polling Rate0% of its maximum rate.» Learn more
    Hardware Health Polling Rate1% of its maximum rate.» Learn more
    VIM.VMware.Polling7
    Total Job Weight3664
    Number of HW Health Monitors55
    Number of HW Health Sensors1696

    3. This is our primary sever. We are in the middle of a failover right now so the low polling completion is fine.

    Polling Completion77.27
    Elements5980
    Network Node Elements1023
    Volume Elements2878
    Interface Elements2079
    SAM Application Polling Rate7% of its maximum rate.» Learn more
    SAM Windows Scheduled Tasks Polling Rate9% of its maximum rate.» Learn more
    Hardware Health Polling Rate6% of its maximum rate.» Learn more
    Polling Rate49% of its maximum rate.» Learn more
    IPAM.Dhcp.Polling0
    Fibre Channel Polling Rate0% of its maximum rate.» Learn more
    Routing Polling Rate0% of its maximum rate.» Learn more
    UnDP Polling Rate0% of its maximum rate.» Learn more
    VIM.VMware.Polling30
    Total Job Weight2806
    Number of HW Health Monitors219
    Number of HW Health Sensors5559

    4. Additional server for primary site.

    Polling Completion99.99
    Elements6449
    Network Node Elements1346
    Volume Elements2414
    Interface Elements2689
    SAM Application Polling Rate38% of its maximum rate.» Learn more
    SAM Windows Scheduled Tasks Polling Rate0% of its maximum rate.» Learn more
    Hardware Health Polling Rate7% of its maximum rate.» Learn more
    Polling Rate52% of its maximum rate.» Learn more
    Routing Polling Rate0% of its maximum rate.» Learn more
    Fibre Channel Polling Rate0% of its maximum rate.» Learn more
    UCS Polling Rate0% of its maximum rate.» Learn more
    VIM Hyper-V Polling Rate0% of its maximum rate.» Learn more
    VIM.VMware.Polling108
    Total Job Weight5486
    Number of HW Health Monitors221
    Number of HW Health Sensors12878
  • It looks like the overwhelming majority of the servers you are monitoring with SAM are on the 2nd poller listed above, with the 70% polling rate. The other three pollers are hardly utilized from a SAM perspective. Instead of deleting/removing items from monitoring you can move some of those those server nodes from the 2nd poller to your other polling engines. This will help distribute the load more evenly across your four pollers.

  • The Short:

    Try confirming if the polling intervals are whats expected by going to 'Edit Properties' on an individual node or interface. 

    The Long:

    Not sure if this was the same issue or not, but I ran into something similar today with NPM when changing my polling intervals from 60sec to 30sec using Orion Polling Settings.  I updated both 'Default Node Poll Interval' and 'Default Interface Poll Interval'.  It appeared to work fine as I saw my polling rates spike on all three pollers to include one that went over 100%.  I then switched back to 60sec polling intervals and saw no decreases in the polling rates.  After monitoring for a while to see if the rates would drop, they had all remained the same.  I then went into my 'Edit Properties' and found that the individual nodes were still showing 30sec, even though my Polling Settings were set to 60sec.  After updating the polling rates on all of my individual nodes and interfaces using 'Manage Nodes' I then saw polling rates come back down to their expected levels.

  • This is also my problem....

    How can I check if how many components are already used in each poller server? Thank you.

  • FYI. Just created the report that will display the application name, number of components, and Pollers emoticons_happy.png

    hi aLTeReGo‌, so the maximum components per poller are 8-10K components only?

  • Correct. That is the recommended limit per-polling engine. SAM 6.2+ supports upwards of 150,000 components per-Orion instance. Stacked pollers can be used to achieve 20,000 components per-server.