Elasticsearch memory allocation settings detailed __elk

Elasticsearch The default installed memory is 1GB, for any real business, this setting is too small. If you are using this default heap memory configuration, your cluster configuration may soon be problematic.

There are two ways to modify the Elasticsearch heap memory (The following is good memory), the simplest way is to specify the ES_HEAP_SIZE environment variable. The service process reads this variable at startup and sets the size of the heap accordingly. The settings command is as follows:

Export es_heap_size=10g

In addition, you can pass the memory size to it when the program starts by using the command line argument:

./bin/elasticsearch-xmx10g-xms10g

Note: Make sure that the size of the XMX and XMS is the same, the purpose of which is to be able to reduce the pressure on the size of the scale heap by wasting resources without having to separate the size of the compute heap after the Java garbage collection mechanism has cleaned up the heap area.
Generally, setting es_heap_size environment variables is better than writing-xmx10g-xms10g directly.

give the half of the memory to Lucene

A common problem is to configure a large memory, assuming you have a 64G memory machine, in accordance with normal thinking, you may think that the 64G memory to Elasticsearch better, but the reality is this, the bigger the better.

Of course, memory is absolutely important for elasticsearch, for more memory data to provide faster operation, and there is a large memory consumer-lucene.

Lucene is designed to cache data in the underlying OS into memory. Lucene's segments are stored separately in a single file that will not change, so it is good for caching, and the operating system caches these pieces of files for faster access.

The performance of Lucene depends on the interaction with the OS, and if you allocate all of your memory to Elasticsearch and leave it to Lucene, your Full-text search performance will be poor.

The final standard recommendation is to give 50% of the memory to the Elasticsearch, the remaining 50% will not be useless, Lucene will soon swallow the rest of this memory for the file cache.

do not exceed 32G

There is another reason for not allocating large memory to elasticsearch, in fact the JVM uses a Memory object pointer compression technique when memory is less than 32G.

In Java, all objects are allocated on the heap, and then a pointer references it. The size of the pointer to these objects is usually the size of the length of the CPU, not 32bit or 64bit, depending on your processor, and the pointer points to the exact position of your value.

For 32-bit systems, your memory can be used for up to 4G. For 64 systems, you can use a larger amount of memory. But a 64-bit pointer means a bigger waste, because your pointer itself is big. Wasting memory doesn't count, and worse, larger pointers take up more bandwidth when moving data between main memory and the cache (such as LLC, L1, etc.).

Java uses a technique called memory pointer compression to solve this problem. Its pointer no longer represents the exact position of an object in memory, but represents an offset. This means that 32-bit pointers can reference 4 billion objects, not 4 billion bytes. In the end, this means that the heap memory is up to 32G of physical memory, or it can be represented by a 32bit pointer.

Once you cross the boundary of that magical 30-32g, the pointer will cut back to the normal object's pointer, and each object's pointer will be longer, using more CPU memory bandwidth, which means you actually lost more memory. In fact, when the memory reaches the 40-50GB, the effective memory is equivalent to using the Memory object pointer compression technology 32G memory.

This description means that even if you have enough memory, try not to exceed 32G because it wastes memory, lowers CPU performance, and allows the GC to deal with large memory.

1TB Memory Machine

32GB is an es a memory set limit, then if your machine has a lot of memory how to do it. Now that the machine memory is generally growing, you can now see the machine with 300-500GB memory.

First, we recommend coding the use of such a mainframe
Second, if you already have such a machine, you have two options:

Do you mainly do full-text search? Consider giving Elasticsearch 32G memory, the rest to Lucene as the operating system of the file system cache, all the segment cache, will speed up Full-text search.

You need more sorting and aggregation. You want a larger heap of memory. You can consider creating two or more ES nodes on a single machine instead of deploying a node that uses 32+GB memory. Still adhere to the 50% principle, assuming you have a machine with 128G memory, you can create two node, using 32G memory. That is to say, 64G memory to the ES heap memory, the remaining 64G to Lucene.

If you choose the second type, you need to configure Cluster.routing.allocation.same_shard.host:true. This prevents the primary copy of the same shard from being on the same physical machine (because the high availability of the replica is not available on a machine).

swapping is the graveyard of performance

This is obvious, but it's important to be clear that memory swapping to disk is fatal to server performance. Think of a memory operation that must be fast.


If the memory is switched to disk, a 100-microsecond operation can turn into 10 milliseconds, and then add up to the 10-microsecond operation. It's not hard to see how scary swapping is for performance.

The best way to do this is to disable swapping completely in your operating system. This can be temporarily disabled:

Swapoff-a

To permanently disable it, you may need to modify the/etc/fstab file, referring to your operating system-related documentation.

If you disable swap completely, it is not feasible for you. You can lower the swappiness value, which determines how often the operating system swaps memory. This prevents the exchange from occurring normally. However, the OS is still allowed to swap in case of an emergency.

For most Linux operating systems, this can be configured in Sysctl:

vm.swappiness = 1

Note:swappiness set to 1 is better than 0, because in some kernel versions, swappness=0 can cause oom (memory overflow)

Simply put, this parameter defines the system's propensity to swap, with a default value of 60, and a larger value indicates a preference for swap. can be set to 0, which does not prohibit the use of swap, but minimizes the possibility of using swap.

The current settings for the parameter can be viewed through sysctl-q vm.swappiness.

The way to modify the parameters is to modify the/etc/sysctl.conf file, join the vm.swappiness=xxx, and reset the system. This action is equivalent to modifying the/proc/sys/vm/swappiness file in the virtual system and changing the value to the XXX number.

If you do not want to restart, you can dynamically load the/etc/sysctl.conf file through Sysctl-p, but it is recommended that you empty swap before doing so.

Finally, if none of the above methods can be done, you need to open the Mlockall switch in the configuration file, which is to run the JVM to lock the memory and prevent the OS from swapping out. The ELASTICSEARCH.YML configuration is as follows:

Bootstrap.mlockall:true