Memory Settings

 

Minimum Heap Space Allocation: Earlier versions of MailArchiva had a default heap space setting of 1512 MB. MailArchiva V4 now requires an absolute minimum of 2048 MB of heap. We recommend between 3072m and 5192m be allocated. If too little heap space is assigned, MailArchiva will run sluggishly, and CPU usage will spike to 100%.

 

 

Overview

 

MailArchiva requires three different types of memory:

 

  1. Heap space - this memory is used for allocating objects inside the Java runtime environment. When running the setup, you will be prompted for this value.
  2. Virtual memory - this memory is used for direct buffering. For performance reasons, it is allocated outside the confines of the Java runtime environment. It represents the remaining amount of memory.

 

 

Total Physical RAM = PermGen (Program Code) + Java Heap + Virtual Memory (Direct Buffering) + OS

 

OS Minimum: Kindly refer to the operating system minimum guidelines for information on its minimum memory requirements. For example, Windows 8 (32 bit) requires 1 Gigabyte. Windows 8 (64) requires 2 Gigabytes.


Since MailArchiva also allocates memory outside of the Java runtime environment, it necessary to leave at least 1/2 of available memory freely available. This memory is also needed for basic operating system functions.

 

Upgrade: When upgrading MailArchiva from earlier versions (e.g. version 2.x), it is necessary to change the memory configuration of the server.  Newer versions of the Lucene search engine library changed the way it allocated memory. It used to allocate memory as part of the heap. For performance reasons, it now allocates memory directly (using virtual memory, outside of the JVM). Thus it threw all our previous recommendations out of the window.
 

Suggested Memory Settings

 

Linux

 

8 GIG Physical RAM Spec - Typical Server

 

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

Java Heap Space: 5192MB

 

4 GIG Minimum Memory Spec - Small Server

 

If MailArchiva is expected to deal with very little volume and the goal is to conserve as much memory as possible, the below spec applies:

Java Heap Space: 2048MB

 

Windows

 

8 GIG Physical RAM Spec - Typical  Server

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

Java Heap Space: 5192MB

 

4 GIG Minimum Memory Spec - Small Server

 

If MailArchiva is expected to deal with very little volume and the goal is to conserve as much memory as possible, the below spec applies:

Java Heap Space: 2048MB

 

Too Much Memory Allocated? A common mistake is to allocate too much heap space to the MailArchiva server. While from a performance perspective, MailArchiva certainly enjoys an abundance of heap available, allocating too much heap puts strain on system resources and can be severely counterproductive. When there is a large amount of heap allocated, the Java garbage collector has to work harder to free objects in the huge pool of allocated memory.  In our experience, when using the default G1 garbage collector, the server starts to perform badly if more than 6GB is allocated on the heap. Therefore, in cases where more than 6 GB of heap is necessitated (e.g. 16 GB), careful tuning of the Java garbage collector is required. Contact support should you require further guidance in this regard.

 

Low Memory Symptoms: Symptoms of low/incorrectly configured memory settings: CPU usage may run at 120%, searching may be very slow, server may quit unexpectedly, archiving may be slow, server may observe strange errors.
 
Growth: The bigger the archive data and associated indexes grow, generally the more heap space and virtual memory will be required. Searching will slow down if there is not enough virtual memory to cope with large search engine indexes. Furthermore, the server may become unstable if there is not enough heap space to load the growing number of documents stored in the volume. That being said, the system does scale very well. It is useful to point this out, since if your server behaves very well, and then five years later doesn't behave in the same way, often adding more memory can help the situation tremendously.

 

How To Change Memory Settings

 

Checking the Total RAM Available - MailArchiva will always use the maximum amount of RAM that you specify

Change Heap Space - Increase heap space available to MailArchiva

 

Memory Problems: If you are experiencing trouble with MailArchiva running out of memory or feel that MailArchiva is using too much memory, please refer to Memory Issues.

 

PST Import: Due to the nature of the PST import routines, if there is a requirement to import very large PST files >2GB, your server will likely need more memory.

 

Checking Total RAM Available

 

Before, allocating more RAM, 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

 

 Note: If too little heap space is allocated, the server may run out of memory and archiving may stop entirely.

 

 Note: It is a mistake to fill up the physical memory with heap space. As discussed earlier, MailArchiva also requires virtual memory. As a guide, at least 1/2 of memory should be freely available for the operating system and MailArchiva's virtual memory requirements.

 

Max Heap Size: Currently, Java garbage collection algorithms are not so good at handling large heap sizes. As such, it is not normally recommended to allocate more than 6GB to the Java heap, without further JVM tuning. See further below for high load enterprise server tuning instructions.

 

  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!)

Refer to: http://java.sun.com/docs/hotspot/HotSpotFAQ.html#gc_heap_32bit for more information.

 

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

 

64 Bit OS Highly Recommended: To make full use of all of the available physical RAM, it may be necessary to install a 64 bit Operating System such as Windows Server 64 bit or Ubuntu Server 64 bit.

 

Free Space Tip: When allocating more RAM to MailArchiva, at minimum, you should always leave free memory for the Operating System to function effectively.

 

MailArchiva v2.8.0 And Lower: When the email archive server is upgraded from one version to another, the heap size settings may revert back to the defaults. Please ensure that MailArchiva's heap size settings are correct after each upgrade.

 

32bit / 64bit JVM: As of v1.9.5, the Enterprise Edition for Windows and Linux incorporates both a 32bit and a 64bit JVM. It will automatically detect the appropriate JVM based on the architecture of your operating system.

 

Large Enterprise Server

 

 

Warning: The below material is highly technical. Some knowledge of Java memory management is required. Contact us if there any doubt regarding the tuning of the MailArchiva software in your environment.

 

MailArchiva runs inside a Java Virtual Machine (JVM). As such, its performance is subject to the effectiveness of the chosen garbage collection (GC) algorithm. The garbage collector (GC) is responsible for freeing up allocated memory. Different garbage collectors perform different strategies for clearing memory. Since freeing up memory is in of itself a (potentially) resource intensive process, both in terms of time and CPU cycles, GC has the potential to put a drag on application performance.

 

By default, MailArchiva is configured to use the G1 garbage collector. It is tuned as follows (see startserver.sh):

 

export CATALINA_OPTS="-Dversion=enterpriseedition -Xmx768m -Xms256m -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:SurvivorRatio=3 -XX:+AggressiveOpts"

 

In large enterprise deployments with hundreds of millions of emails archived, it is often desirable/necessary to allocate a large heap (e.g. 16GB). In such cases, the use of the default G1 garbage collector is not suitable. The chart below illustrates what happens when the default G1 collector is used in combination with a large amount of allocated heap. As is illustrated, this server spends more time collecting items in the heap, than doing useful work.

 

Bad Garbage Collection

Thus using the G1 collector combined with a large amount of allocated memory, will likely cause MailArchiva to become unresponsive due to an excessive amount of time spent on major collections.

 

In contrast, the illustration below (left chart), garbage collector activity (indicated by the thin blue line at the bottom) is kept to a minimum. 

 

Garbage Collection

 

FYI: The settings below are known to work well on an enterprise server with 32GB of RAM or more. This particular server has several hundred million emails archived, with excellent response times.

 

export CATALINA_OPTS="-Dversion=enterpriseedition -server -Xms10g -Xmx10g -XX:NewSize=1g -XX:MaxNewSize=1g -XX:+UseParNewGC -XX:MaxTenuringThreshold=2 -XX:SurvivorRatio=8 -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=32768 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:+CMSClassUnloadingEnabled  -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly -XX:+AlwaysPreTouch -XX:-OmitStackTraceInFastThrow -XX:-UseSplitVerifier"

 

The above settings can be modified by editing the startserver script (Linux) or right click task tray applet, click Configure..., select Java tab, enter the parameters Java Options panel. Thereafter, restart the MailArchiva service for the changes to take effect. 

 

20K Mailbox Example Configuration

 

The below example memory config applies to larger installations of > 20K mailboxes.

 

cat /opt/mailarchiva/server/startserver 

 

#!/bin/bash
# MailArchiva Enterprise Edition Start Server Script
# Visit http://www.mailarchiva.com for more information on this product
umask 022
MAILARCHIVA_HOME=/opt/mailarchiva
#LD_PRELOAD_64=/usr/lib/64/libumem.so
# tune glibc memory allocation, optimize for low fragmentation
# limit the number of arenas
export MALLOC_ARENA_MAX=2
# disable dynamic mmap threshold, see M_MMAP_THRESHOLD in "man mallopt"
export MALLOC_MMAP_THRESHOLD_=131072
export MALLOC_TRIM_THRESHOLD_=131072
export MALLOC_TOP_PAD_=131072
export MALLOC_MMAP_MAX_=65536
export JAVA_HOME=$MAILARCHIVA_HOME/jre64
export JRE_HOME=$MAILARCHIVA_HOME/jre64
#export LD_PRELOAD_64;
export CATALINA_PID=$MAILARCHIVA_HOME/mailarchiva.pid
export CATALINA_HOME=$MAILARCHIVA_HOME/server
export CATALINA_BASE=/var/opt/mailarchiva/tomcat
export JAVA_OPTS="-d64 -Dfile.encoding=UTF-8"
export JAVA_ENDORSED_DIRS=$CATALINA_HOME/endorsed
export PATH=$JAVA_HOME/bin:$PATH
export CATALINA_OPTS="-server -XX:+AggressiveOpts -Dversion=enterpriseedition -Dhardmount=yes -Xms64g -Xmx64g
-XX:MaxDirectMemorySize=512g -Dgraphdb.cache.size=64 -Dstorage.diskCache.bufferSize=8192
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:+CMSConcurrentMTEnabled -XX:+CMSClassUnloadingEnabled
-XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark
-XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly
-XX:+AlwaysPreTouch -XX:-OmitStackTraceInFastThrow
-Xloggc:/var/log/gc-$(date +%Y_%m_%d-%H_%M).log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime
export LC_ALL=en_US.UTF-8
ulimit -n 128000
ulimit -v unlimited
bash $MAILARCHIVA_HOME/server/bin/startup.sh
Was this information helpful?

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

The page cannot be found

The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. Please make sure you spelled the page name correctly or use the search box.