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.

Abnormally High Percent Utilization

I'm getting percent utilization readings that are much higher than they should be.  I assume that whatever is polling them is misinterpreting the information somehow, but I'm not sure how to fix this.

An example of what I'm seeing.  More nodes than just this one do this, but they don't all do it all the time.

High%.png

  • Some more info.

    Only 2 out of 3 interfaces show the ridiculous utilization; this is normal, the one interface has never shown high utilization.  Maybe there is an issue gathering information about the interfaces?

    Interfaceuse.png

  • Without seeing the interface name or type, I'm making an assumption here that the interface is likely a 10GB interface or loopback interface.

    • If 10GB interface, NPM probably didn't discover the interface speed on it, and set it to the default 10MB.  You'll have to edit the interface in NPM, and use the custom speed field to get it reporting correctly.
    • If its a loopback interface, these interfaces use dynamic speed settings.  That is to say, since they are only internally used, they adjust to whatever speed they need to be to get the application using it to perform optimally.  I typically don't monitor these, but they are a pretty good indicators of a SQL server issue (if you have SQL in your environment).

    D

  • The interface speeds are both set to 10.0 Gbps, but we do have an SQL server.

    I saw some stuff about SQL in another thread, but if these are loopback interfaces with dynamic speed settings, would the Configured Interface Speed even show up in NPM?

    I see one and/or two possibilities here. 

    1. NPM is reading loopback interfaces as interfaces with a static speed

    2. I have to change some settings on the SQL server.

  • So, this is a loopback?  You can't really set it to a static speed, the OS dynamically adjusts the speed to accommodate the applications; which is why I (and most network folks) typically don't monitor them for stats.  However, if its a SQL server loopback, I do monitor them but don't alert on them; and only look at them if someone is having issues with SQL latency.  You'll probably notice NPM has discovered the the interface as a 10MB speed as well (because it couldn't determine a real speed), and depending on how heavy the server is used, this is usually enough (unless there is an issue).

    D

  • I went to edit interface, and the bandwidth was set as follows:

    bandwidth.png

    Even if it had discovered it as 10 Mbps, the custom bandwidth is set far higher, so I don't think I should be getting this issue.

    I saw this thread: http://thwack.solarwinds.com/docs/DOC-169067

    and am thinking maybe that's what I need to do.  But if the custom bandwidth here is already so high, I don't see how changing it through the SQL Server will make a difference.

  • I've experienced that posting personally, as well as your issue (same issue); that's why I knew to ask about the 10GB and loopback interfaces...those are typically the culprits.  Since you already set the custom bandwidth, and that didn't fix it; have you tried to unmanage the interfaces and re-manage them?  After a device or interface is re-managed, NPM performs a rediscovery process that sometimes corrects issues like this.  I don't know the difference between a standard polling cycle rediscovery and this unmanage/remanage rediscovery.  If that doesn't correct it, you might have to unselect it from being managed at all, and re-add it.

    D

  • Unmanaging/remanaging didn't resolve the issue.  I think the answer lies within SQL.