The imapd Process Leaks mmap Regions
Last updated on JUNE 29, 2017
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:
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