Project

General

Profile

Actions

Architecture #14923

open

Dynamic groups with regex on software are long to build delaying generation

Added by François ARMAND almost 5 years ago. Updated about 2 years ago.

Status:
New
Priority:
N/A
Category:
Performance and scalability
Target version:
-
Effort required:
Name check:
Fix check:
Regression:

Description

When we have a dynamic group built from a regex on software (name or version), the group can be long to resolve (several seconds).
If you have a hundred such group, rebuilding all dynamic group time explodes.
This is especialy problematic because since #

The reason is that we can't handle regex on the server side, so the logic is:

- 1/ get all software (which mean: LDAP request, get result, translate them to entries, filter entries - so we have a lot of data on net, GC churn, etc)
- 2/ filter by regex in rudder.

Softwares are problematic because we commonly have several tens of thousand of them.

This is even worse because we never trim software, so we may have irrelevant entries.

We already change trivial regex like .*something.* into "match substring" requests.

I don't see any simple way to enhance the performance on one request, but two things that can be better for sequence of requests:

- trim software. Less software mean better perf, and it's just pure technical debt to not do it.
- add a local cache of software for the duration of updating dyngroups as soon as at least one dyn group need it (ie: a lazy evaluated parameter for that). It does not seems harder to do it for all search request. It is a big change.

Also, we should be able to know exactly what groups need to be regenerated at any point in time.
Here, our strategy is "rebuild everything" which is correct but extremelly inefficient (first level).
The second level is "only rebuild dyn groups if there's an indice they need to (ex: if no modification in any part of node inventories / nodes properties since last groupe update... we can just skip it).
The third level is to have the real dependency graph, and only rebuild groups which are changed by a mod as a consequence of that change.

Level 3 is a big change. It will go with commitid logic.
Level 2 is really not that hard, we already have the information about changes in nodes, so it's just a matter of using it correctly.

This ticket is an header ticket, I will open children for the ones we want to adress independently.


Subtasks 2 (0 open2 closed)

Bug #14924: Cleanup unreferenced software from past inventoriesReleasedNicolas CHARLESActions
Bug #15069: Merge error in parent broke the buildReleasedFrançois ARMANDActions

Related issues 2 (1 open1 closed)

Related to Rudder - Bug #9609: Deleted node should be periodically fully erased in LDAP (after some ttl)ReleasedNicolas CHARLESActions
Related to Rudder - Architecture #14939: Inefficient storage of software in LDAP directory NewActions
Actions #1

Updated by Nicolas CHARLES almost 5 years ago

  • Related to Bug #9609: Deleted node should be periodically fully erased in LDAP (after some ttl) added
Actions #2

Updated by Nicolas CHARLES almost 5 years ago

Indexes

index osName eq
index container,software eq
index ipHostNumber eq

# Software search
index   cn,softwareVersion  eq


improve also performance, going from 1min25 to 1min10 for all groups computation

Actions #3

Updated by Nicolas CHARLES almost 5 years ago

indexes

index osName eq

index   isEnabled,isDynamic,isModified,isSystem eq
index   uuid eq

index  container,software eq

# Software search
index   cn,softwareVersion  e

leads us to 1m for dyn group update

Actions #4

Updated by François ARMAND almost 5 years ago

I'm setting it to major because there is a lot of insidious side effects, among them: consumption of more an more spaces ; slow down in UI ; etc.

Actions #5

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.12 to 5.0.13
Actions #6

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.13 to 5.0.14
Actions #7

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.14 to 5.0.15
Actions #8

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.15 to 5.0.16
Actions #9

Updated by Alexis Mousset about 4 years ago

  • Target version changed from 5.0.16 to 5.0.17
Actions #10

Updated by Vincent MEMBRÉ almost 4 years ago

  • Target version changed from 5.0.17 to 5.0.18
Actions #11

Updated by François ARMAND over 3 years ago

  • Target version changed from 5.0.18 to 6.2.0~beta1
  • Severity set to Major - prevents use of part of Rudder | no simple workaround
  • User visibility set to Operational - other Techniques | Rudder settings | Plugins
  • Priority changed from 0 to 22

I'm setting it to "major" since once it's hit, there little that can be done, and the consequences are systemic. Little can be done here, though, without a major change in rudder architecture. Linking to #14939.

Actions #12

Updated by François ARMAND over 3 years ago

Actions #13

Updated by Vincent MEMBRÉ over 3 years ago

  • Target version changed from 6.2.0~beta1 to 6.2.0~rc1
  • Priority changed from 22 to 43
Actions #14

Updated by François ARMAND over 3 years ago

  • Target version deleted (6.2.0~rc1)
Actions #15

Updated by François ARMAND about 2 years ago

  • Tracker changed from Bug to Architecture
  • Severity deleted (Major - prevents use of part of Rudder | no simple workaround)
  • User visibility deleted (Operational - other Techniques | Rudder settings | Plugins)
  • Priority deleted (43)
Actions

Also available in: Atom PDF