The purpose of this document is to provide a workaround for customers using Confluence version 2.2.x and who are experiencing slow search performance and/or Too many open files error in their logs.

This problem has been properly addressed as of Confluence 2.3. If upgrading is an option for you, we recommend upgrading to the latest stable version.

The workaround

The workaround for this problem involves two steps.

1. Reducing the frequency of index optimisation

Index optimisation is performed over your entire search index periodically to maintain good search performance. However, this process will lock down the index for the entire duration that it occurs. Searching will not be possible during this time. For small Confluence instances with small indexes, optimisation time is negligible. However, for larger instances, where optimisation is potentially expensive to perform, it could cause a noticeable inconvenience for users.

In Confluence 2.2.x, index optimisation is scheduled to occur every time the index queue is flushed (every minute). Optimisation does not need to performed this regularly. To fix this:

  1. Extract DefaultConfluenceLuceneIndexManager.zip to your confluence/WEB-INF/classes/com/atlassian/confluence/search/lucene directory. This patch will allow you to specify a JVM parameter to adjust the frequency of optimization. For example if you want it to occur on every 20th flush of the index queue start Confluence with this JVM parameter:
    -Dconfluence.optimize.index.modulo=20
    
    Setting it back to 1 will revert back to normal behaviour (optimize on every flush).
  2. Restart Confluence

2. Apply a patched bonnie jar

To address the Too many open files issue, you need to download the patched bonnie jar attached to this issue: http://jira.atlassian.com/browse/CONF-7401. Copy the jar to your {[confluence/WEB-INF/lib}} directory and remove the old one. Now restart and rebuild the index.

If are still experiencing problems after this, please file a support request at http://support.atlassian.com and we'll investigate the issue further.

  • No labels