Speed up reindex in Confluence

[stankopp-ni]

Hello,

we had outage with our confluence instance and need now start reindex again, the problem is it' extremely slow, we have about 291100 objects and in one hour only about 4000 were reindexed (that's just 1%).

Is there a way somehow speed it up? I know Jira have mode to block all users and run internal tasks with high prio.

I'm using Confluence 5.10.7 on Debian Jessie with 16GB RAM and 10 CPU cores.

CATALINA_OPTS="-Xms1024m -Xmx8192m"

Thanks,

Stan

UPD: Workaround in https://jira.atlassian.com/browse/CONF-41010 has helped. ('DROP INDEX `c_status_idx` ON `confluence`.`CONTENT`')

Reindex was done after 80 minutes 

[Mike Rathwell]

Stan,

This does have a big component of DB speed in it; which database server are you running? The other thing that leaps out at me is to set you Xms to the same value as Xmx. I can't remember where I ran across that little tidbit but I did see it in a Confluence tuning page that suggested that as a way to have the space and get around some of the speed hits of garbage collection. That made a big diff in mine. 

I am running Debian 8.6 with 8GB RAM, and 4 cores with PostgreSQL 9.3 as the RDBMS. The CATALINA_OPTS are -Xms5120m -Xmx5120m -XX:+UseG1GC. My instance isn't as big as yours (only ~45k objects) but it rebuilt in less than 30 mins total time.

NOTE, however, that if you haven't re-indexed for a while those first records can be painfully slow and it does pick up speed as it gets to newer (and maybe less borked) entries.

[stankopp-ni]

Hi Mike, thanks for info, I've updated CATALINA_OPTS. In my case the workaround in https://jira.atlassian.com/browse/CONF-41010 has helped (I'm using mysql 5.5)

[Mike Rathwell]

Glad that helped Stan. Also, unless you have a specific reason for using MySQL, I heartily recommend moving to PostgreSQL; it is MUCH faster. When I moved from MySQL to PostgreSQL, one of the pages I turned up when looking at how to do such had the comment, "There are lots of pages saying how to move from MySQL to PostgreSQL but very few going the other way".