Memory allocation

 

Overview

 

MailArchiva allocates memory in two different memory spaces:

 

  1. Heap space - space for objects allocated in memory managed by the Java runtime environment. When running the product setup, you will be prompted to specify this value.
  2. Virtual memory - direct memory allocated outside the confines of the Java runtime environment. It is suggested to leave 1/2 to 1/3 of memory freely available for this purpose.

Total Physical RAM = PermGen (program code) + Java heap + Virtual Memory (direct memory) + OS

 

Activities consuming the most amount of memory include:

 

  1. Indexing the contents of large attachments such as Word and Excel documents. 
  2. Searching over extremely large indexes with many millions of documents
  3. Importing data from extremely large PST files (>2GB). We rely on third-party libraries to parse the PST file format. The memory consumption characteristics of these libraries are not under our control.

 

Memory settings

 

8 GIG Physical RAM Spec - Typical  Server

 

Assuming a server machine with 8 gigabytes of physical RAM, the following apply:

 

Java Heap Space: 5192MB

 

4 GIG Minimum Memory Spec - Small Server

 

If little email volume is expected, and the goal is to conserve as much memory as possible, the below spec applies:

 

Java Heap Space: 1512MB

 

How to change memory settings

 

Checking the total RAM available - Determine the amount of physical RAM available

Change heap space - Increase heap space available to MailArchiva

 

Checking the total RAM available

 

Before allocating the amount of heap space, please check the physical amount of RAM that you have available.

 

1. Windows 7:

   a) Click Start

   b) From the search box, type 'ram' without the quotes

   c) Click "Show how much RAM is available on this computer"

 

2) Linux

   a) Type "top" in a terminal window


Change heap space

 

While MailArchiva generally performs well with an abundance of heap space, a balance between the amount of heap space allocated and available CPU resources must be struck. With a large amount of heap space allocated, the Java garbage collector has to work harder to free unused objects in the huge pool of allocated memory.  

 

If too little heap space is allocated, the server may run out of memory and server behavior may become unpredictable.  Conversely, it is not recommended to fill up all available physical memory with heap space. At least 1/2 to 1/3 of memory should be freely available for the operating system and direct memory allocation.

 

  1. Linux: From the commandline:

   a) Run the "configure" script as follows:
 

[program directory]/server/configure

 

  b) Restart the MailArchiva server

 

systemctl stop mailarchiva
systemctl start mailarchiva

 

  1. Windows:

    a) Right click task tray applet, click Configure...
    b) Select Java tab
    c) Enter a higher amount for the maximum memory size
    d) Restart the MailArchiva Service (this is required for the changes to take effect!)

After allocating more memory, do not be alarmed if the MailArchiva process is using the full extent of memory allocated. This is normal behavior for Java-based applications. For more information on common memory usage patterns in Java-based applications, please refer to Out Of Memory.

 

Enterprise memory settings

 

MailArchiva runs inside a Java Virtual Machine (JVM). The garbage collector (GC) is responsible for freeing up unused objects residing on heap memory. Different garbage collectors perform different strategies for clearing memory in the heap.  By default, Java software runs using the G1 garbage collector. A new high performant collector named ZGC has recently been made available with the advent of Java 21 (the Java runtime used by MailArchiva). While it seems likely that the ZGC collector offers performance advantages over the default G1 collector, its use with MailArchiva hasn't yet been extensively tested. To experiment with the use of the ZGC collector, add "-XX:+UseZGC" to CATALINA_OPTS.

 

Note: Earlier versions of the G1 collector had trouble allocating large sized heaps. This issue is now resolved. It is generally not necessary to modify the G1 collector's default parameters.

 

In enterprise deployments with hundreds of millions of emails archived, it is often desirable/necessary to allocate a large heap (e.g. 25 GB) (see startserver.sh):

 

export CATALINA_OPTS="-Dstorage.diskCache.bufferSize=7200 \
        -Xms25g -Xmx28g -Xss1024k -Djava.awt.headless=true -server \
        -Dproxy=yes -Dversion=enterpriseedition \
        --add-exports java.xml/com.sun.org.apache.xerces.internal.impl=microsoft.exchange.webservices"

 

 

 

© 2005 - 2024 ProProfs

Found this information useful? Visit mailarchiva.com to learn more about MailArchiva.

-