티스토리 뷰
원문 : https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html
1. ES_HEAP_SIZE로 조절 가능
2. 메모리의 반은 Lucene에게 주어라, Elasticsearch의 core는 lucene으로 되어있다. ES에 모든 메모리를 할당하면 Lucene이 사용할 메모리가 줄어들어 성능이 더 안좋아진다. ES에 50%의 Memory를 주고 나머지는 Lucene이 사용할 수 있게 해라. 만약 ES에 많은 메모리가 필요 없을것 같다면, 최적화가 가능하다면 좀 더 작은 메모리를 사용해라.
3. 32GB 이상으로 할당하지 마라. 이는 JVM의 OOP 문제이다.
참고 : http://dev-punxism.tistory.com/entry/JVM-OOPSOrdinary-object-pointer
4. I Have a Machine with 1 TB RAM
32GB는 매우 중요하다. 될 수 있다면 큰 머신을 사용하지 마라.
용도에 따라 메모리를 할당하라.
full-text search를 한다면 32GB만 ES에 할당하고 나머지는 Lucene이 cache로 사용 할 수 있게 하라
not_analyzed 필드에 대해 sorting/aggregation을 한다면, 당신은 행운아. ES는 32G만 할당하고 나머지는 OS가 사용하도록 해라
analyzed string에 대해 soring/aggregation을 한다면 불행히도 당신은 heap이 필요하다 하지만 아직 50% 룰은 준수할만하다. 만약 128GB의 ram을 가졌다면 2개의 node를 만들어라. node를 쪼개고 쪼개라.
5. 메모리 스왚핑은 preformance의 죽음의 길이다.
elasticsearch.yml에 bootstrap.mlockall: true로 설정하라.
Lucene이 inmemory 기반이라 그런듯, GC가 발생해도 swap할지 말로 메모리상에서 해결 가능하게 해라..는 것 같음..
- Total
- Today
- Yesterday
- AWS
- Java
- kerberos
- Dynamodb
- oops
- authentication
- ranking
- JVM
- DESIGN
- CompressedOops
- GC
- Kafka
- OOP
- Intermediate Certificate
- Consumer
- Certificate Chain
- SSL
- shenandoah
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |