Running the --processqueue command sets a queue process into operation.
By default this only runs at midnight and midday but it has a limit on how much it actually processes (these are all of the internal de-duplication processes and transactions which get queued and the process comitts them)
On a busy system it can get behind so the queue just gets bigger and bigger which slows the system down.
Keeping it trimmed down to a small size will help the system run well
When it said "OK" it has started one or added one to its process queue.
The more times it gets run the smaller the queue gets - usually you have one running and one queued and once both have finished check how how it is doing. The size is in bytes (or is it kb?) so it is nice to have a queue no more than 5 digits.
Yours looks to be struggling as when you first showed the command the queue was up to Mon May 5 12:19:51 2014 but 5 hours later it has not got any newer so was still processing.
When that run had finished it would do the new one due - or the one you fired off manually - it should have done the midday and midnight ones since then too - so lets see what your queue is this morning to see if it is catching up and if it has any waiting (so do --processqueueinfo and --queueinfo)
The /disk/etc/puredisk/contentrouter.cfg is exactly where it says it is ... /disk/etc/puredisk/contentrouter.cfg
If you are doing accelerator backups you really should use 128 for the WorkerThreads value.
It looks like you are doing a lot to one appliance - how is the disk space doing? Show us the output of:
/usr/openv/pdde/pdcr/bin/crcontrol --dsstat
and also tell us what the sizes show under the disk pool section of the admin console
Once a de-dupe pool gets above 80% full performance starts to degrade
