Upgrade path from 2.x to 3.2 : some tuning and recommendations (Part 2)

Previous post : Upgrade path from 2.x to 3.2 : some tuning and recommendations (Part 1)

Here are some other tuning recommendations that might help you to reduce the time of the Alfresco upgrade path, from 2.x to 3.2:

Please note that we have tested some of these “tuning” and that some of them, or a combination of some of them, could have a negative impact on the time of the upgrade path…So I recommend that you test these options carefully one by one first, and that you select only those which are relevant in your case:

——————————–
1/ If you experience OOM:

– Simply give more memory the heap (Xmx), if possible,
– Use the -XX:+HeapDumpOnOutOfMemoryError option so that the cause of the OOM can be analyzed afterwards through yourkit or other tools understanding hprof dumps (this cause no overhead, as heapdump file is created only if OOM occurs).

——————————–

2/ Increase transactional caches:

During upgrade path, you might see some log traces as follows:

18:14:01,264 WARN [org.alfresco.repo.cache.TransactionalCache.org.alfresco.storeAndNodeIdTransactionalCache] Transactional update cache ‘org.alfresco.storeAndNodeIdTransactionalCache’ is full (10000).

In our case, the support recommendation was to increase Cache Size as follows:

In cache-context.xml, increase maxCacheSize for the following:

authorityTransactionalCache from 100 to 5000

org.alfresco.personTransactionalCache from 1000 to 10000

org.alfresco.storeAndNodeIdTransactionalCache from 10000 to 50000

But do not set the ehcache caches too high or you’ll accumulate uncollectable cached objects in the JVM old gen, leading to more and more full GCs and leaving less room for the rest. Even if they is enough memory you’ll spend a large amount of time processing weak refs. it’s a memory / performance tradeoff.(see also next recommendation below).

—————

2/ Increase transactional caches can have a bad impact on JVM memory:

Increasing Transactional Cache can help in some cases, but on the condition that it does not fill up your old generation, which you cannot guess unless there is proper JVM monitoring and/ or heap dumps…

However, in some other cases, it might make sense, instead of increasing caches, to rather disable hibernate’s L2 cache for the upgrade path scenario…
This can be done by setting hibernate.cache.use_second_level_cache=false in alfresco-global.properties.

So clearly, this recommendation is not consistent with the previous one….But this is not surprising, since there is no “one true set” of settings that are written in stone. So test this option carefully, and use it only if you can see the improvement in your context.

——————————–
3/ Another option to try is to “make the hibernate session size resource interceptors more aggressive”:

You can try to make the hibernate session size resource interceptors more aggressive (see beans sessionSizeResourceInterceptor and sessionSizeResourceManager): as a result, the caches will be flushed more frequently (more frequent commit) and the old gen accumulation will grow more slowly (assuming that stateful persistence contexts associated with the threads might be an issue in your context):

By default, you should have:

<bean id=”sessionSizeResourceInterceptor”
class=”org.alfresco.repo.transaction.SingleEntryTransactionResourceInterce
ptor” <property name=”methodResourceManagers”>
<list>
<ref bean=”sessionSizeResourceManager”></ref>
</list>
</property>
<property name=”elapsedTimeBeforeActivationMillis”>
<value>10000</value>
</property>
<property name=”resourceManagerCallFrequencyMillis”>
<value>5000</value>
</property>
</bean>
<bean id=”sessionSizeResourceManager”
class=”org.alfresco.repo.domain.hibernate.SessionSizeResourceManager”>
<property name=”sessionFactory”>
<ref bean=”sessionFactory” />
</property>
<property name=”writeThreshold”>
<value>2000</value>
</property>
<property name=”readThreshold”>
<value>50000</value>
</property>
<property name=”retentionFactor”>
<value>3</value>
</property>
</bean>

You can try to set values as follows:

<beans>
<bean id=”sessionSizeResourceInterceptor” >
<property name=”methodResourceManagers”>
<list>
<ref bean=”sessionSizeResourceManager”></ref>
</list>
</property>
<property name=”elapsedTimeBeforeActivationMillis”>
<value>10000</value>
</property>
<property name=”resourceManagerCallFrequencyMillis”>
<value>100</value>
</property>
</bean>

<bean id=”sessionSizeResourceManager”>
<property name=”sessionFactory”>
<ref bean=”sessionFactory” />
</property>
<property name=”writeThreshold”>
<value>200</value>
</property>
<property name=”readThreshold”>
<value>200</value>
</property>
<property name=”retentionFactor”>
<value>0</value>
</property>
</bean>
</beans>

This config will allow to free more space in the old gen at each collection.

Don’t forget to use this setting only for the upgrade, not for production / runtime.

It may or not help, so once again, try it and use it only if this leads to upgrade time improvements….

——————————–
4/ Tuning the Linux swap threshold:

During the test of the upgrade path you should also check that the system is not swapping.

If it’s linux this can be controlled with the “vm.swappiness” kernel parameter, which can be set
safely to 10 (meaning don’t swap anything until ram is 90% full).
By default on Linux, this parameter is set to 40, which mean that system will swap as soon as memory is 60% full.

Note: we have not tested this tuning option during our upgrade path test.

——————————–

Hope this series of post will help you to complete a succesfull (and quicker) data migration !

Advertisements

One Response to Upgrade path from 2.x to 3.2 : some tuning and recommendations (Part 2)

  1. Manish Trivedi says:

    Hello,

    I was wondering if you faced any issue with deployment receiver migration. There was a major code refactoring post 3.1

    If you have any information on that, please share.

    Thanks,
    manish

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: