The imapd Process Leaks mmap Regions (Doc ID 1590086.1)

Last updated on APRIL 08, 2024

Applies to:

Symptoms

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:

Changes

Cause

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