Higher CPU Usage After Patching Messaging Server From 8.0.1.3 To 8.0.2.1 (Doc ID 2350687.1)

Last updated on MAY 03, 2023

Applies to:

Symptoms

Using:  Oracle Communications Messaging Server 8.0.2.1.20171204 64bit (built Dec 4 2017)

Observed higher CPU usage after patching Messaging Server from 8.0.1.3 to 8.0.2.1.  The average low for idle CPU over the last 3 days after patching has been 80%.
So if the current trend continues into peak load, we expect the system will get down to 20% idle. The system should still be working, but this is a significant change from previous behavior.

Also noticed entries such as these in the mail.log_current log:

On the MTA, running Messaging Server 8.0.2.1.20171102, it ignores the one that is deleted and routes the message to the newly upgraded host1.

But on that host, running Messaging Server 8.0.2.1.20171204, ims_master seems to be stuck in a loop of using the one that does not have a mailhost.

The uid=jdoe has been deleted for some time and has not been modified since: modifytimestamp: 20171114020624Z.
The uid=jdoe8 has been been receiving mail on host1 for some time and although the modify time is recent (modifytimestamp: 20171213171413Z), the mail attribute has not been changed in some time.

Changes

Changes between Messaging Server 8.0.1.3 and 8.0.2.1:

Assuming mmap contention was a bottleneck and we reduced that by 10%, an increase in CPU is not unexpected. Processes that were slowed by mmap contention can now do more work faster and thus may have higher CPU use, especially if traffic is bursty. The non-mmap FETCH code works the way the POP server works. It either uses the OS sendfile() API (only possible on non-SSL/non-transcript connections) which may be less work than mmap or it uses standard read/write operations which will involve an extra data copy and more CPU work than the mmap implementation. That's ok; we're deliberately increasing throughput (and decreasing risk of a slowdown) at a cost of total CPU use.

We also now have more abstraction in the store APIs between 8.0.1.x an 8.0.2.x. It's possible the additional abstraction consumes more CPU.

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.