Performance Tuning For Big Migrations - tsgrp/OpenMigrate GitHub Wiki
This document are some of the tricks and tips tried to monitor and increase performance.
General
- When possible, use OM Tracker to monitor the migration and help determine if bottlenecks exists in source, mapping, or target.
- Run the migration with one instance and single threaded (1 source, 1 mapping and 1 target thread). Observe the debug log and see which method is possibly the bottleneck.
- Increase thread counts till you are maximizing the utility of your CPU.
- Increase JAVA_HEAP if you have the capacity to do so.
- Garbage collection. This was added to a client project (might need to be tweaked)
-XX:+UseParNewGC -XX:+CMSConcurrentMTEnabled -XX:+UseConcMarkSweepGC -XX:MetaspaceSize=256M -XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark -XX:+PrintGCTimeStamps -Xloggc:<folder-path>/gc-metadata.log -XX:+PrintGCDetails -XX:CMSInitiatingOccupancyFraction=65 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSWaitDuration=300000 -XX:+CMSClassUnloadingEnabled
- Reduce logging - make OM_QUIET=true in your setenv and/or THRESH.STDOUT=ERROR in log4j-om.properties.
- For JDBC Connections make sure you are not using the singleDataNodeConnection and instead using the apache DBCP2 and fine tune your connection pool based on availability.
Alfresco
- Prevent setting the versionable aspect on node: (if you don't need versions)
Set an attr on the node with value
NONE
and then pass that attribute as theversionTypeAttr
in MigrationTargetAlfrescoCMIS bean. - Turn Renditioning off.
- Turn automatic thumbnail generation off.
system.thumbnail.generate=false
- When possible, use the CMIS 1.1 binding instead of 1.0 - it's more efficient
- Use in-place migration.