[elasticsearch] performance tuning (성능 튜닝)

elasticsearch 1.4.3 으로 테스트해봤던 내용 공유

1. refresh_interval 값 성능

전에, refresh_interval 값이 성능에 영향이 있다고 해서 테스트해보았다. 

refresh_inteval 로 주어진 값은 인덱싱(색인)을 얼마나 하는 주기를 의미한다. 일종의 flush 같은 개념인데, 

길면 길수록 성능은 좋아지고, 짧을 수록 성능은 좋지 않다. 

확실히 짧게 주는 것보다는 길게 주는 것이 좋다. cpu 5~15% 차이가 발생 했다.

그러나, 문제는 서비스의 영향도가 있어서 짧게 줄 수 없다.. 

로그 수집하는 정도나. refresh_interval을 길게 줄 수 있을 듯 하다.

curl -XPUT localhost:9200/movies/_settings -d '{

    "index" : {

        "refresh_interval" : "30s"

    } }'

(좋은 참고 : http://blog.sematext.com/2013/07/08/elasticsearch-refresh-interval-vs-indexing-performance/ )

2. optimize 옵션 주기

optimize옵션을 주면 빠른 검색이 되도록 최적화 인덱싱을 한다. 호출 순간에서는 성능이 안좋아질 수 있으나, 장기적으로는 성능이 좋아진다.

cpu 1~3% 정도로 성능이 좋아졌다.

$ curl -XPOST 'http://localhost:9200/movie/_optimize'

(좋은 참고 : http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-optimize.html#optimize-parameters)

3. 삭제시 좋은 성능이 나오도록 튜닝 요소

인덱스를 이루는 세그먼트가 삭제로 인해서 큰 세그먼트로 compatction이 일어나도록 잘 튜닝할 수 있다. 

서비스 성격에 맞게 변경해야 한다. 

index.merge.async: true

index.merge.policy.merge_factor: 10

index.merge.policy.expunge_deletes_allowed: 10

index.merge.policy.floor_segment: 1mb

index.merge.policy.max_merge_at_once: 8

index.merge.policy.max_merge_at_once_explicit: 2

index.merge.policy.max_merged_segment: 1gb

index.merge.policy.segments_per_tier: 10

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-merge.html

https://groups.google.com/forum/#!topic/elasticsearch/-j7bpgNMHMQ

4. Sorting 성능 개선

Sorting 성능을 개선할 수 있다. 서비스 성격에 맞게 변경해야 한다.

index.fielddata.cache: soft 

indices.fielddata.cache.size: 80%

indices.fielddata.cache.expire: 24h

https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-fielddata.html

5. 검색 ThreadPool 설정

threadpool:

    index:

        type: fixed

        size: 30

        queue_size:-1 

https://www.elastic.co/guide/en/elasticsearch/reference/1.x/modules-threadpool.html

6. (Data Node) JVM GC 알고리즘 

다양한 방식으로 여러 GC 방법 (CMS, G1)으로 테스트 해봤으나, elasticsearch에서 제공하는 디폴트의 jvm 옵션(cms)이 최강이었음. 

JVM8 최신으로 G1 알고리즘으로 Full GC 시간을 좀 줄일 수 있지만, 자주 조금 줄일 수 있었지만, CPU가 상당히 높게 나왔다. CMS는 다양한 옵션으로 했지만, 디폴트 옵션만큼의 CPU와 Full GC 시간을 이길 수 없었따. 

(참고 : http://blog.sematext.com/2013/06/24/g1-cms-java-garbage-collector/)

7. (Data Node) JVM 메모리

JVM 메모리가 많을 수록 유리할 수 있지만, Full GC 시간이 점점 길어졌다. 한 JVM의 메모리는 작은 것이 가장 성능이 좋았다.

인터넷의 여러 회사 블로그에서 대용량 트래픽을 elasticsearch 대용량 메모리로 처리했다는 내용(linked, stackoverflow)을 참조해고 해봤는데, 서비스의 성격(CRUD)에 따라 다른 것 같다.