Higher CPU Usage After Patching Messaging Server From 22.214.171.124 To 126.96.36.199
(Doc ID 2350687.1)
Last updated on FEBRUARY 24, 2019
Applies to:Oracle Communications Messaging Server - Version 8.0.2 and later
Information in this document applies to any platform.
Using: Oracle Communications Messaging Server 188.8.131.52.20171204 64bit (built Dec 4 2017)
Observed higher CPU usage after patching Messaging Server from 184.108.40.206 to 220.127.116.11. 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 18.104.22.168.20171102, it ignores the one that is deleted and routes the message to the newly upgraded host1.
But on that host, running Messaging Server 22.214.171.124.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 between Messaging Server 126.96.36.199 and 188.8.131.52:
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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document