I resolved the issue, documenting here in case someone finds this useful.
1. I connected to OMV via SSH and ran the lsblk command. lsblk will list all the partitions. The ones we are interested in are the ones that btsync uses.
2. I then ran lsof <path to media bt sync uses>. Example, lsof /media/B20AA9E80AB9AA2D.
This showed me the process (btsync) and which files it was accessing. I found that the process was stuck on a large 26GB image file I had.
3. I removed the problematic folder from btsync and then re-added it. The high CPU usage continued. However, the bt sync GUI showed that it was indexing the re-added folder so this was fine. I let it run for a few hours and then CPU usage dropped back down to normal.
You can confirm that bt sync is no longer stuck by periodically re-running the lsof <file path> command and checking that it's not on the same file for too long. Of course, you must be a bit patient if the file is really large, but it shouldn't be stuck on any file too long. I indexed 230GB worth of stuff overnight.