Project

General

Profile

Bug #15858

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

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

Status:
Pending release
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 about 1 month 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 about 1 month ago

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

History

#1

Updated by Nicolas CHARLES about 2 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 about 2 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 about 2 months ago

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

Updated by Nicolas CHARLES about 2 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 about 2 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 about 2 months ago

  • Target version set to 5.0.15
#7

Updated by Nicolas CHARLES about 2 months ago

  • Category set to Performance and scalability
#8

Updated by Nicolas CHARLES about 2 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 about 1 month ago

  • Status changed from Pending technical review to Pending release

Also available in: Atom PDF