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.

Any other users have large amounts of groups/nested groups (Long Running Query issues)


I just wanted to get a feel for other users to see if they are having the same hardships as we are.

Since 10.7 we have been plagued with "Long Running Query" issues.  These typically get addressed with "Buddy Drop" fixes... but future upgrades had the same issues (requiring new Buddy Drops).  Every time we would upgrade, we would have massive performance problems until these fixes were addressed by development (sometimes weeks later).

We are a large retailer with many stores and we organized them by group when we initially set up SolarWinds.

We've come to realize that this was a really bad idea and we are in the process of rethinking how we have everything organized because NPM doesn't seem to be coded to accommodate this mentality by default (although there are options for it).

You would THINK it would be a really organized to group this way...

Stores

     PA Stores

          Store00001

               Network Devices

                    Switches

                         (node) Switch 1

                         (node) Switch 2

                    Routers

                         (node) Router 1

                         (node) Router 2

               Workstations

                    Registers

                         (node) Register 1

                         (node) Register 2

                         (node) Register 3

                    Back Office Workstation

                         (node) Device 1

                         (node) Device 2

               Servers

                    (node) Server 1

                    (node) Server 2

How we saw it, was we could build dashboards and have them view limit based off of "group of groups" and get all the data we care about.

This turns out to be a horrific idea because of how NPM queries things... It doesn't play nicely with nested groups (causing these long running query problems).

SolarWinds developers would prefer you use a completely flat group for all of your stores and put all of your store equipment into that folder for maximum performance.

Does anyone else use lots of groups or lots of nested groups?  Are you having the same performance problems we have when trying to use view limitations based off of "group of groups"?

I'd love to hear your thoughts if you have the time.

Thanks in advance.

  • We have 484 containers.

    most of these are built off filter like this:

    Group name:     Filter

    'MC HMC'     filter:/Orion.Nodes[CustomProperties.Building='HMC' AND CustomProperties.Sector='MC']

    ---

    we have a smaller number (<<10) of groups eg 'MC' that contain all of the 'MC xxx' groups added as individual members

    the UW has ~320 members groups, MC about 50 memeber groups, K20 has a deeper hierarchical structure with ~10 members at each level

    There are about 40,000 managed objects in the 484 containers.

    ---

    experience: group of groups is horrible, performance is really bad. the SQL queries looked to be deadlocking on various tables and blocking each other from completing.

    I was in the middle of a live demo to the medical center IT managers when it really slowed down, so I had to work in 15 minute coffee break to solve the problem [check out my job title]

    Solution: we used the Account Limitation builder to build account limitations based directly off the [same] custom properties we use to build the group membership.