Project

General

Profile

Bug #15858

Computing dynamic groups is very memory intensive, and can lead to FGC or OOM

Added by Nicolas CHARLES 4 months ago. Updated about 2 months ago.

Status:
Released
Priority:
N/A
Category:
Performance and scalability
Target version:
Severity:
User visibility:
Effort required:
Priority:
0

Description

When dynamic groups are updated, it uses a lot of memory, and can completly prevent a policy generation to finish
We need to find a way to make it less memory consuming

Note: my tests uses a lot of regex and and/or in software, it might be a cause of issue


Files

Screenshot from 2019-10-04 13-48-05.png (890 KB) Screenshot from 2019-10-04 13-48-05.png Nicolas CHARLES, 2019-10-04 13:48
without.png (1.56 MB) without.png Nicolas CHARLES, 2019-10-06 00:39
with.png (1.55 MB) with.png Nicolas CHARLES, 2019-10-06 00:39

Associated revisions

Revision e1d98277 (diff)
Added by Nicolas CHARLES 4 months ago

fixup! Fixes #15858: Computing dynamic groups is very memory intensive, and can lead to FGC or OOM

Fixes #15858: Computing dynamic groups is very memory intensive, and can lead to FGC or OOM

Revision e4551684 (diff)
Added by Nicolas CHARLES 4 months ago

Fixes #15858: Computing dynamic groups is very memory intensive, and can lead to FGC or OOM

History

#1

Updated by Nicolas CHARLES 4 months ago

AgentTypes.scala:256 com.normation.inventory.domain.AgentInfoSerialisation$.parseJson(String, Option) 1585 2021260 847048904 is a strong contender in memory usage

#2

Updated by Nicolas CHARLES 4 months ago

We could use Circe or Spray-Json or Jsoniter to lower memory footprint (see https://circe.github.io/circe/performance.html , https://github.com/plokhotnyuk/jsoniter-scala)

#3

Updated by Nicolas CHARLES 4 months ago

  • Status changed from New to In progress
  • Assignee set to Nicolas CHARLES
#4

Updated by Nicolas CHARLES 4 months ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Nicolas CHARLES to François ARMAND
  • Pull Request set to https://github.com/Normation/rudder/pull/2504
#5

Updated by Nicolas CHARLES 4 months ago

  • Category deleted (Performance and scalability)
  • Target version deleted (5.0.15)

We could do much better than that:
process returns a Seq[Nodenfo], by converting the result of the QueryAndCheckNodeId, and converting the NodeEntry, InventoryEntry and Machine to a NodeInfo; but we are throwing it all away to keep only the id in computeDynGroup, so we could make a new method which would return only the NodeIds, and save a lot of hassle

#6

Updated by Nicolas CHARLES 4 months ago

  • Target version set to 5.0.15
#7

Updated by Nicolas CHARLES 4 months ago

  • Category set to Performance and scalability
#8

Updated by Nicolas CHARLES 4 months ago

ok, i don't have the finished computed part without, because the close tabs is so f***ing close to selecting the tab itself, but screenshot with and without the change
Note how with the change, only ldap uses memory, will without, the parsing takes half of allocated memory

So it tooks 1.5GB to compute dynamic group with the change, and more than 3.5 GB (it wasn't finished) without the change

#9

Updated by Nicolas CHARLES 4 months ago

  • Status changed from Pending technical review to Pending release
#15

Updated by Vincent MEMBRÉ about 2 months ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 5.0.15 which was released today.

Also available in: Atom PDF