On what hardware are you running this? If the par2/unrar has such an impact, I would expect it's lower-spec hardware?
On which OS are you running this? Some remarks below are meant for Linux.
Approach #1: change the priorty
See if setting 'ionice' in the SAB parameters helps. If not, try lowering the priority of par2 / unrar, or of SABnzbd as a whole.
Approach #2: the API programming way: let a script run each minute: move anything in the download-queue with a short ETA (< 3 minutes) to a lower position in the queue (or lower queue priority) *if* there is stuff with longer ETA. The result of this is that big downloads are always on top, and that downloads will only reach unpack / unrar if there is nothing big to download anymore.
Approach #3: another API programming way: only add stuff to the queue in Download-only mode. As soon as the download is complete and it reaches the History queue, and *if* there is nothing else to download, change the option to Unpack/Repair so that SAB puts it again in the queue and starts the unpack/repairt. HOWEVER, SABnzbd seems not to offer to do that last action: once done in History, you seem not to be able to do more processing on it :-(
EDIT: the SAB-API seems to offer a History-Retry option:
http://wiki.sabnzbd.org/api#toc43 . That could be interesting: Download-only everything into the queue. Then, each x minutes, let a crontab script check if the Download-Queue is empty, and if so, get something from the History queue that has Downloaded-only, 'retry' it into the Download-queue, and change Download-only to full processing.
EDIT 2: Pity: the Retry-option in the History-overview is only selectable if something went wrong in the download. So not for the above use case #3.