Higher CPU Usage After Patching Messaging Server From 18.104.22.168 To 22.214.171.124
Last updated on JANUARY 26, 2018
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 126.96.36.199.20171204 64bit (built Dec 4 2017)
Observed higher CPU usage after patching Messaging Server from 188.8.131.52 to 184.108.40.206. 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 220.127.116.11.20171102, it ignores the one that is deleted and routes the message to the newly upgraded host1.
But on that host, running Messaging Server 18.104.22.168.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 22.214.171.124 and 126.96.36.199:
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.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms