Hi Support,
Last weekend , I did a re-index of JIRA, but it took 9h 55m, why it took so long ? Database size is only 7GB.
Could you please give me some advices so that I can investigate this issue ?
Much appreciated !
Hi Tony,
Are you running Windows or Linux? Is there antivirus software running on your JIRA server? What type of hard disk are you running? Is the index file stored on the same server? Are you running the recommended hardware requirements - https://confluence.atlassian.com/jira/jira-requirements-185729596.html#JIRARequirements-JIRAServerHardwareRecommendations?
Thanks,
Jared - Design Industries
Hi Jared, Thanks for your response ! My account doesn't have any points , so I can only add comment once. this is my colleague's account . Currently, our JIRA server is a VM running on Hyper-v platform. VM information : windows server 2008R2SP1, Memory 60GB, 6 virtual processors. fixed disk no aitivirus software in JIRA server mysql server is also a VM and mysql and jira are running in the same hypervisor.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Tony (Neo) I just up-voted your question, so you should have enough points to comment again :) How much RAM has been allocated to the JIRA server? Is the hyper-v server running more than just a VM for JIRA and a VM for MySQL? A re-index is an index file located on a hard disk. If the read/write speeds of the hard drive are slow, then this can cause the re-index process to take significantly longer. You could by identifying what speed (MB/s) your servers hard disks are running at and/or IOPS (input/output operations per second). I suspect that this might be the root cause of your re-index performance problem Thanks, Jared.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jared, You are really kind ! Thank you very much ! 60GB RAM has been allocated to the jira server, and yes, there are more than 20 VMs also running in this hyper-v server About the read/write speeds , we didn't enable QOS on disk in hyper-v settings ,but we will check this later, BTW, how would us set IOPS if we want a better performance ? During re-indexing, I found Log Files in JIRA get flooded with errors (after re-indexing, these errors still keep occuring) : LexoRankReindexer:thread-1 Warn ServiceRunner [jira.issue.index.defaultissueDocumentFactory] Error indexing issue POD-906: Dropping 'customfield_14899' LexoRankReindexer:thread-1 Warn ServiceRunner [jira.issue.index.defaultissueDocumentFactory] Error indexing issue POD-906: Dropping 'customfield_14900' LexoRankReindexer:thread-1 Warn ServiceRunner [jira.issue.index.defaultissueDocumentFactory] Error indexing issue POD-906: Dropped [customfield_14899;customfield_149000] More information , we had dropped two tables before we did this re-index ,these two tables were used by a plugin which had been disabled for two years, and we found the size of the two tables was 13GB, so we dropped them.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Tony, You should be able to identify the customfield that is being Dropped (as indicated in the logs). This might help provide more information there. As for LexoRank - this is related to JIRA Agile (formerly GreenHopper) Are you running any calculated or scripted fields? In regards to more IOPS - this is more an informational number to identify how fast your hard disks can read/write. If this number is low, then I would Thanks, Jared.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jared, thanks for your help . We will enable Qos on the disk to see if it works. Tony
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.