5.5.1, 6.0.0, 184.108.40.206, 6.5.0, 220.127.116.11, 6.5.1, 6.5.2, 18.104.22.168, 22.214.171.124, 126.96.36.199, 5.5.2, 7.0.0, 6.5.3, 7.0.1
When performing a recording where the service config may be dump, one may end up using a lot of memory while this is being done during production gathering. As memory demands will conflate GC activity, we should be more careful with memory use: Example:
When doing upgrade on a large service, the UpgradeServices.writeBackup will serialize the whole AM configuration (taking 2X the string representation of the LDAP in memory ie: basically saying like needing 2-4 times the AM config in memory) and this itself may cause upgrade to be slow or need extremely large JVM size (compared to normal runtime) to get the AM upgraded.
Similar issue may happen on SSOADM (probably another tracking bug but same for exporting service config)
As can be seen in those thread dump, the service config dump reads the whole services branch into a String (1st storage ~ 1.5 bytes per string string *representation of the AM config ) and then later does a toBytes(UTF) to dump to file. Note also that converter to byte cannot work for large string too. Definitely not good when performing AM recording for diagnostic collection.
- A dozen realm with huge number Agents, SAML (huge metadata) and many stuff.
- Install AM (default with dc=openam, dc=forgerock, dc=org)
- Create a realm tmp, tmp001, tmp002, tmp003
- Download tmp.ldif.bz2
- Load to the Directory on each realm (below is for tmp realm)
- bzcat tmp.ldif.bz2 | sed 's/tmp/tmp/g' | ldapmodify -p 10389 -D"cn=Directory Manager" -w dirmanagerpwd -c
- Repeat for tmp001
- bzcat tmp.ldif.bz2 | sed 's/tmp/tmp001/g' | ldapmodify -p 10389 -D"cn=Directory Manager" -w dirmanagerpwd -c
- Repeat until step 7 for realm tmp002 to tmp003.
- The above create 1000 OAuth2 agent each with 32K size.
- You may deactivate these realms. So that they do not use memory.
- Now do any config config or dump. You will not be able to do this with JVM memory < 2GB
config export may pass with smaller JVM.