The imapd Process Leaks mmap Regions
(Doc ID 1590086.1)
Last updated on MARCH 18, 2020
Applies to:Oracle Communications Messaging Server - Version 7.0.0 to 7.0.4 [Release 7.0.0]
Oracle Solaris on SPARC (64-bit)
Oracle Solaris on x86-64 (64-bit)
We suspect there is a memory leak in the imapd processes. The VSZ and RSS reported by ps or prstat grows over time. Eventually ZFS performance begins to degrade because of increased read activity due to reduced memory available for ZFS cache.
The virtual and resident memory use of the imapd processes will grow and shrink over time. The imapd process uses the mmap() syscall to map message store files into its process virtual address space. It normally uses munmap() to unmap them. The file system includes such mapping in the count of the inode being in use. So the storage cannot be freed from disk until the last process has closed (or unmapped) the file.
The size of the imapd process growing soon after startup would be normal. The problem described in this article is that after the normal quick growth after startup, the size continued to grow every day.
Using the pmap command on the imapd processes, showed a growth in the number of segments in the process, which continued to grow at a rate of hundreds or thousands per day.
On a busy system, because imapd uses mmap() and munmap() frequently, the pmap command may fail with an "address space is changing" error message.
How to count the number of segments in the imapd process
To simply count the number of segments in the process address space, you could use the following shell script:
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
|How to count the number of segments in the imapd process|
|How to run pmap on the imapd processses|
|Duplicate mappings of the same files|
|How to identify the filesystem from the device major and minor numbers|
|How to find the file on the filesystem|