Apache Ignite Documentation

GridGain Developer Hub - Apache Ignitetm

Welcome to the Apache Ignite developer hub run by GridGain. Here you'll find comprehensive guides and documentation to help you start working with Apache Ignite as quickly as possible, as well as support if you get stuck.

 

GridGain also provides Community Edition which is a distribution of Apache Ignite made available by GridGain. It is the fastest and easiest way to get started with Apache Ignite. The Community Edition is generally more stable than the Apache Ignite release available from the Apache Ignite website and may contain extra bug fixes and features that have not made it yet into the release on the Apache website.

 

Let's jump right in!

 

Documentation     Ask a Question     Download

 

Javadoc     Scaladoc     Examples

Performance Tips

Simple cache configuration tips to optimize your cache performance.

Overview

Apache Ignite performance and throughput vastly depends on the features and settings you use. In almost any use case, the cache performance can be optimized by simply tweaking the cache configuration.

Disable Internal Events Notification

Ignite has a rich event system to notify users about various events, including cache modification, eviction, compaction, topology changes, and a lot more. Since thousands of events per second are generated, it creates an additional load on the system. This can lead to significant performance degradation. Therefore, it is highly recommended that you enable only those events that your application logic requires. By default, event notifications are disabled.

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    ... 
    <!-- Enable only some events and leave other ones disabled. -->
    <property name="includeEventTypes">
        <list>
            <util:constant static-field="org.apache.ignite.events.EventType.EVT_TASK_STARTED"/>
            <util:constant static-field="org.apache.ignite.events.EventType.EVT_TASK_FINISHED"/>
            <util:constant static-field="org.apache.ignite.events.EventType.EVT_TASK_FAILED"/>
        </list>
    </property>
    ...
</bean>

Tune Durable Memory

Tune Durable Memory and its Ignite persistence referring to Memory Configuration and Durable Memory Tuning sections.

Tune Data Rebalancing

Make sure that thread pool and throttling parameters are tuned for the data rebalancing for your specific scenario.

Configure Thread Pools

Ignite uses several thread pools which size is calculated as max(8, total number of cores) by default. This default suits for most of the use cases resulting in few context switches and exploiting CPU caches more efficiently. However, if you are expecting that your jobs will block for I/O or any other reason, it may make sense to increase the size of specific pools. The example below shows how to change the size of public and system pools:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    ... 
    <!-- Configure internal thread pool. -->
    <property name="publicThreadPoolSize" value="64"/>
    
    <!-- Configure system thread pool. -->
    <property name="systemThreadPoolSize" value="32"/>
    ...
</bean>

Use Collocated Computations

Ignite enables you to execute MapReduce computations in memory. However, most computations usually work on some data which is cached on remote grid nodes. Loading that data from remote nodes is very expensive in most cases. It is a lot cheaper to send the computation to the node where the data resides. The easiest way to do it is to use the IgniteCompute.affinityRun() method or the @CacheAffinityMapped annotation. There are other ways, including Affinity.mapKeysToNodes() methods. The topic of collocated computations is covered in much detail in the Affinity Collocation section which contains proper code examples.

Use Data Streamer

If you need to upload lots of data into cache, use IgniteDataStreamer to do it. Data streamer will properly batch the updates before sending them to remote nodes and will properly control the number of parallel operations taking place on each node to avoid thrashing. It provides 10x better performance than doing a bunch of single-threaded updates. See Data Loading section for more details and examples.

Batch Up Your Messages

If you can send 10 bigger jobs instead of 100 smaller jobs, you should always choose to send bigger jobs. This will reduce the number of jobs going across the network and may significantly improve the performance. Similarly, for cache entries, always try to use API methods that take collections of keys or values instead of passing them one-by-one.

Tune Garbage Collection

Refer to JVM and System Tuning for the guidence on the GC tuning.

File Descriptors

System File Descriptor Limit

When running a large number of threads accessing the grid as in the case of large-scale server-side applications, you may end up with a large number of open files used both on client and server nodes. It is recommended that you increase the default values to the max defaults.

Misconfiguring the file descriptors settings will impact application stability and performance. For this we have to set both “System level File Descriptor Limit” and “Process level File Descriptor Limit”, respectively, by following these steps as a root user:

  1. Modify the following line in the /etc/sysctl.conf file:
fs.file-max = 300000
  1. Apply the change by executing the following command:
/sbin/sysctl -p

Verify your settings using:

cat /proc/sys/fs/file-max

Alternatively, you may execute the following command:

sysctl fs.file-max

Process File Descriptor Limit

By default, Linux OS has a relatively small number of file descriptors available and max user processes (1024) configured. It is important that you use a user account which has its maximum open file descriptors (open files) and max user processes configured to an appropriate value.

📘

A good maximum value for open file descriptors is 32768.

Use the following command to set the maximum open file descriptors and maximum user processes:

ulimit -n 32768 -u 32768

Alternatively, you may modify the following files accordingly:

/etc/security/limits.conf

- soft    nofile          32768
- hard    nofile          32768

/etc/security/limits.d/90-nproc.conf

- soft nproc 32768

📘

See increase-open-files-limit for more details.

Updated about a year ago

Performance Tips


Simple cache configuration tips to optimize your cache performance.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.