1. 홈
  2. 질의 응답
  3. ElasticSearch 100 % CPU

ElasticSearch 100 % CPU

2017-09-25 1 views
0

더 나은 질문 범위를 만들려면 topic을 만드십시오.ElasticSearch 100 % CPU

Windows 서비스로 ElasticSearch 5.4.0 사용. 16GB RAM의 Windows Server 2016

명령을 통해 설치 : elasticsearch - service.bat 관리자

Java 옵션 :

-Xms8g 
-Xmx8g 
-XX:+UseConcMarkSweepGC 
-XX:CMSInitiatingOccupancyFraction=75 
-XX:+UseCMSInitiatingOccupancyOnly 
-XX:+DisableExplicitGC 
-XX:+AlwaysPreTouch 
-Xss1m 
-Djava.awt.headless=true 
-Dfile.encoding=UTF-8 
-Djna.nosys=true 
-Djdk.io.permissionsUseCanonicalPath=true 
-Dio.netty.noUnsafe=true 
-Dio.netty.noKeySetOptimization=true 
-Dio.netty.recycler.maxCapacityPerThread=0 
-Dlog4j.shutdownHookEnabled=false 
-Dlog4j2.disable.jmx=true 
-Dlog4j.skipJansi=true 
-Delasticsearch 
-Des.path.home=C:\elasticsearch 
-Des.default.path.logs=C:\elasticsearch\logs 
-Des.default.path.data=C:\elasticsearch\data 
-Des.default.path.conf=C:\elasticsearch\config

초기 메모리 풀 : 8,192메가바이트

최대 메모리 풀 : 8,192메가바이트

스레드 스택 크기 : 1024KB.

norconex 크롤러를 사용한 색인 작성 후 데이터로 한 번 채워짐. 작업이 끝나면 항상 작업 관리자에서 거의 100 % 진행됩니다. 언젠가는 0 % 또는 25 %로 낮아 지지만 1 분 후에는 95 %로 되돌아갑니다.

[2017-09-25T16:23:13,166][INFO ][o.e.m.j.JvmGcMonitorService] [Zugx4zq] [gc][9415] overhead, spent [364ms] collecting in the last [1s] 
[2017-09-25T16:23:14,534][INFO ][o.e.m.j.JvmGcMonitorService] [Zugx4zq] [gc][9416] overhead, spent [647ms] collecting in the last [1.3s] 
[2017-09-25T16:23:15,550][INFO ][o.e.m.j.JvmGcMonitorService] [Zugx4zq] [gc][9417] overhead, spent [397ms] collecting in the last [1s] 
[2017-09-25T16:23:16,708][WARN ][o.e.m.j.JvmGcMonitorService] [Zugx4zq] [gc][9418] overhead, spent [657ms] collecting in the last [1.1s] 
[2017-09-25T16:23:17,745][INFO ][o.e.m.j.JvmGcMonitorService] [Zugx4zq] [gc][9419] overhead, spent [494ms] collecting in the last [1s]

요청이 너무 길거나 exeption에 실패 실행 :

ElasticSearch.log 파일은 이러한 유형의 기록으로 가득

org.elasticsearch.transport.RemoteTransportException: [Zugx4zq][127.0.0.1:9300][indices:data/read/search[phase/query]] 
Caused by: org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of [email protected] on EsThreadPoolExecutor[search, queue capacity = 1000, [email protected]fa409f[Running, pool size = 7, active threads = 7, queued tasks = 1000, completed tasks = 93134]] 

org.elasticsearch.transport.RemoteTransportException: [Zugx4zq][127.0.0.1:9300][indices:data/read/search[phase/query]] 
Caused by: org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of [email protected] on EsThreadPoolExecutor[search, queue capacity = 1000, [email protected]fa409f[Running, pool size = 7, active threads = 7, queued tasks = 1000, completed tasks = 118501]]

내가 이해하지 말자 사람로드의이 종류를 생성 이 서비스에 이 모든 작업은 어디에 있습니까 (대기 작업 = 1000)? 서비스로드 모니터링 방법 어떤 종류의 서비스가 내가 놓친 미세 조정? 전 DevOps 또는 전문 시스템 관리자가 아닙니다. 저는 .net 프로그래머입니다. 그래서이 모든 Java 어플리케이션은 저에게 어두운 목재입니다.

UPDATE

서버 RAM은 최대 32GB 증가했다. 힙 크기가 24GB로 변경되었습니다. CPU 사용률이 최소값으로 낮아졌습니다. 17k 문서와 크기가 1.1GB 인 색인은 힙 크기가 8GB 크기가 아니라는 이상한 점입니다.

출처

2017-09-25 aleha

답변

0

실제로 시간을 어디에서 보내고 있는지 알고 싶습니다. 가장 쉬운 방법은 모니터링 플러그인을 사용하는 것입니다. Kibana 및 X-Pack 모니터링 플러그인 (무료로 제공)이 필요합니다 (일부 스크린 샷의 경우 https://www.elastic.co/products/x-pack/monitoring 참조).

추신 : 빠른 모양에서 기본 JVM 옵션을 사용하고 있습니다. 일반적으로 좋습니다. 야생 개조를 시작하지 마십시오. 상황을 악화시키는 경우가 많습니다. 세드릭

출처

2017-09-27 09:12:22 xeraa

+0

하나의 비틀기가 설치 키바를 서버의 RAM의 크기를 증가 24 기가 바이트 힙 크기를 증가시키는 것이다 + x-pack은 이제 부드럽게 작동합니다. – aleha

관련 문제

 관련 문제