It is hard to know why the service is consuming so much CPU, but it does not settle down on its own.
On one of the first events, restarting the service seemed to be insufficient, so now I reboot the entire server. This clears the race condition and the machine restarts with normal load.
In our configuration, the same workload should be present before and after the reboot. All of the incoming traffic will be queued up at the incoming gateway, and all outgoing traffic will be queued up in SmarterMail. So the evidence seems to point away from workload as an explanation.
The problem has not happened often enough to develop a clear pattern, and we have not had sufficient instrumentation in place to find the cause when it does happen. When it does occur, the priority is to get the system running again rather than collecting data. But having it happen at all creates fear.
If it occurs on the next release, I will open a ticket and we can try to configure instrumentation to catch the problem.