[closed] Any tricks to speeding up reindex?
I frequently see DOORS NG instances that have broken indexes due to improper shutdown since the application would never shut down cleanly after 5 minutes and I just had to just kill it. This often results in the indexes being broken. To repair the indexes, there are many confusing reindex commands which even with all the Jazz.net articles still seem to baffle the administrators as to which index is broken and which order or commands are required to be ran. The reindexing can often run hours even on high powered hardware.
Can someone please explain why these index architecture is so complex, fragile, and extremely slow to repair?
Is there any hope of improvements in reducing complexity to the administrator, making it less broken, and faster to rebuild if required?
Are there any tips or workarounds to speed things up?
Can someone please explain why these index architecture is so complex, fragile, and extremely slow to repair?
Is there any hope of improvements in reducing complexity to the administrator, making it less broken, and faster to rebuild if required?
Are there any tips or workarounds to speed things up?
The question has been closed for the following reason: "Problem is not reproducible or outdated" by rschoon Sep 28 '21, 10:19 a.m.
3 answers
I'll leave the explanation and potential improvements open. But "Are there any tips or workarounds to speed things up?"
1. You could check and rule out slow connections to the database which would make a rebuild of the indices slow
2. If you have a large data-set (and indices dir), you might potentially be able to speed up the repotools-reindex command by:
a. Stopping server.
b. In [SERVER_INSTALL]/server/repotools-jts or /repotools-rm file locate the following properties:
VMARGS="$VMARGS -Xmx1500M"
#VMARGS="$VMARGS -Xgcpolicy:gencon"
Modify (depending on the size of your data and memory available on the server) as follows, for example:
VMARGS="$VMARGS -Xmx4096M"
VMARGS="$VMARGS -Xms4096M"
VMARGS="$VMARGS -Xmn1024M"
VMARGS="$VMARGS -Xgcpolicy:gencon"
1. You could check and rule out slow connections to the database which would make a rebuild of the indices slow
2. If you have a large data-set (and indices dir), you might potentially be able to speed up the repotools-reindex command by:
a. Stopping server.
b. In [SERVER_INSTALL]/server/repotools-jts or /repotools-rm file locate the following properties:
VMARGS="$VMARGS -Xmx1500M"
#VMARGS="$VMARGS -Xgcpolicy:gencon"
Modify (depending on the size of your data and memory available on the server) as follows, for example:
VMARGS="$VMARGS -Xmx4096M"
VMARGS="$VMARGS -Xms4096M"
VMARGS="$VMARGS -Xmn1024M"
VMARGS="$VMARGS -Xgcpolicy:gencon"
Yes definitely try increasing those argument values if you have the memory available.
We have an RM server with 32 GB so we upped the values for the following properties to 24GB
VMARGS="$VMARGS -Xmx4096M"
VMARGS="$VMARGS -Xms4096M"
VMARGS="$VMARGS -Xmn1024M"
VMARGS="$VMARGS -Xgcpolicy:gencon"
and saw vast improvement in the reindexing speed, not to mention out of memory errors
We have an RM server with 32 GB so we upped the values for the following properties to 24GB
VMARGS="$VMARGS -Xmx4096M"
VMARGS="$VMARGS -Xms4096M"
VMARGS="$VMARGS -Xmn1024M"
VMARGS="$VMARGS -Xgcpolicy:gencon"
and saw vast improvement in the reindexing speed, not to mention out of memory errors
Comments
Don Yang
Jun 28 '15, 7:55 p.m.Personally, I like the two articles explaining how the index architecture is and how to backup and restore:
https://jazz.net/library/article/1271
https://jazz.net/library/article/1272
If you have proper backup before shutting down, then it will be easy to restore them if something is wrong.