체크1
샤드 구성은 p(primary) 10개로 r(replica) 10개로 분포되도록 한다.
체크2
1개의 샤드 내부에는 여러개의 segment 로 구성되어 있다. 샤드에 대해 쿼리 요청이 다수 발생했을때
search.concurrent_segment_search.mode: all
를 설정해서 병렬쓰레드(core 를 최대한 활용)로 검색할 수 있도록 한다.
체크3
concurrent_segment_search 사용을 위해 cpu limit 올린다. 이번의 경우 클러스터에서 cpu 가 많이 필요한 경우가 없어 limit 설정없이 노드의 cpu 모두를 다 사용할 수 있도록 했다.
체크4
lucene 이 page cache(OS 캐시)에 의존한다.
세그먼트 파일을 mmap 으로 열어서 검색 시 인덱스 데이터를 jvm heap 이 아닌 page cache 에서 읽는다.
16Gi limit 상태에서
- heap: 4Gi ("-Xms4g -Xmx4g") 사용
- jvm off-heap(heap 빼고 jvm 이 사용하는 메모리): ~3Gi (netty direct buffer, metaspace, thread stack, gc 구조체 등) 사용
- 나머지 ~9Gi(이게 page cache 가 쓸 수 있는 상한)
page cache(file)가 부족한 경우 질의 마다 디스크 read하게 된다.
하지만 이번의 경우 48h로 늘려도 추가 16Gi limit 에서 문제가 되지 않았다.
체크5
장비 스펙을 비교해보니 메모리 대역폭에서 pm 약 68% 대역폭이 좋아서 빠를 수 있다.
[pm 장비] 5대
Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz(Broadwell 아키텍쳐, 2017년 3분기 출시)
32코어
32G RAM(DDR4-2400, 115.2 GB/s)
[k8s node] 5대
Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz(Skylake 아키텍쳐, 2016년 1분기 츨시)
32코어
64G RAM(DDR4-2133, 68.3 GB/s)
comments:
댓글 쓰기