[elasticsearch] 클러스터 관리에 필요한 내용 + plugin에 대한 짧막한 설명.

## hot thread api
* cpu사용일이 높을때 hot threads api를 통해 특정 프로세스가 블락되어 문제를 일으키고 있는지 확인 할 수 있음.
* _nodes/hot_threads
* response 내용
   * 첫줄 : 노드의 신원 정보(스레드 정보가 어느 cpu에 속하는지에 관한 기초적 정보)
   * 둘째줄 : 'search'스레드에 xx%사용중이라고 나옴. search, merge, index와같은 행동이 기술됨.
   * 마지막줄 : es가 같은 스택트레이스를 가지고 이는 스레드가 최근 몇밀리초내에 뜬 10개 스냅샷 중 10개에 있다는 것을 의미.
   * 블락된 스레드 확인 : 블락 사용율, waiting상태에 있는 스레드들에 대한 대기 사용율.


## thread pool
* cpu와 memory의 효율적 사용을 위해 각 노드는 스레드풀을 관리하고있음.
* 요청종류에 따라 bulk/index/search thread pool이 있음.
* threadpool.bulk.type:fixed
* threadpool.bulk.size
* threadpool.bulk.queue_size: 스레드수를 제어 (기본으로 cpu core * 5)

## 메모리
* heap크기, 필드와 필터 캐시.
* 집계와 필터에 메모리 사용.
* 필드데이터를 메모리에 올림으로써 필드데이터 접근 효율을 높임.
* 쿼리에 해당하는 문서만 올리는게 아니라 색인에 있는 모든 문서에 대한 값들을 로딩해서 쿼리가 엄청 빨라지는 것임.
* jvm ram의 50프로정도는 남겨
   * 루씬이 빈번하게 사용하는 파일 시스템 캐시를 위한 메모리 부족을 막기위해.
* 운영체제에 메모리가 부족하면 메모리페이지를 디스크로 내리는 스와핑이 발생할 수 있음. 급격한 성능저하로 이어지기때문에 스와핑은 끄도록.

## 필터와 필드 캐시
* 필터 캐시 : 필터와 쿼리 작업의 결과를 메모리내에 저장, 필터가 적용된 최초 쿼리 결과를 필터 캐시에 저장, 색인 수준으로는 사용 권장하지 않고. 노드수준의 사용을 권장 (LRU)
* 필트데이터 캐시 제한은 없음. 필드 데이터 서킷 프레이커 값에 도달까지 커질 수 있음.
* 케시 제거되는 것도 주의가 필요함. 비용이 큰 작업이고, 필드데이터가 너무 작게 설정되어있는건 아닌지 확인해볼필요가 있음.

## 운영체제 캐시
* 루씬 세그먼트는 불변 파일이고, os의 파일시스템 캐시를 적극 활용함.
  * 불변 파일이라느 것은 루씬에 의해 한번만 쓰이고, 여러번 읽힌다는 것을 의미.
* 루씬의 불변파일은 캐시 친화적. 기반이 되는 os에서 핫한 세그먼트에 빠른 접근이 가능하게 메모리에 상주시키도록 설계됨
* node.tag정보를 가지고 라우팅하여 특정색인을 성능좋은 장비로 위치시킬수있음.

## 플러그인
* 사이트 플러그인, 코드 플러그인이 있음.
* 사이트 플러그인은 추가적인 기능제공은 아니고, 단순히 es가 서비스하는 웹페이지를 제공하는 것. ex) head plugin
* 코드 플러그인은 es가 실행하는 jvm코드를 포함하는 플러그인으로. jar파일. 
   * es가 인터페이스 제공을 위해 서비스 할 수 있는 기본 html, 이미지 그리고 자바스크립트 파일 포함 가능함.
   * ex) marvel plugin