In my experience, I've seen this happen in three broad cases. Obviously, this is limited to my experience, so it could well be something else I have not encountered.
1. Swap
When a java process uses up too much RAM, it will cause the OS to make heavier use of "swap" space - using disk for things it can't keep in RAM.
If your people are triggering processes that outstrip the memory available, then you will see disk io massively increase while the Java process needs the extra space. The io should however drop back to normal when the process has finished.
This will also happen if you have something with a "memory leak". With a leak though, the disk access will not reduce. A memory leak means something is being allocated memory to work with, but it never releases that memory for other things to use. As more and more memory gets blocked out like that, your OS will increasingly use swap space, so you'll see io increasing until the system can't cope with it.
2. People
There are some functions in Jira that absolutely hammer your disks, notably the xml backup, indexing, and exports. Could your people be triggering actions that chew up the disk io?
3. Incorrect infrastructure
Someone put the index on a shared file system. Don't do that. It guarantees problems like the one you are seeing and can eventually corrupt your data.
I would look for those first, but even if you don't, my answer would not be to try to improve the disk performance, it would be to look at why Jira is doing this. That means looking at what files are being created/updated/destroyed during a period of high io.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.