2018.10.9 온라인에서 엘라스틱 리서치의 쓰기 속도가 매우 느린 것을 발견했는데, 원래 주범은 아리운이 서비스하는 OSS의 냄비였는데...

문제 설명:

프로젝트 계획에 따라 오늘 로그 시스템을 온라인으로 배치합니다(온라인의 모든 로그를 수집하여 문제 조사에 편리하게)

운영은 이전의 배치 과정에 따라elasticsearch를 배치했다. 배치가 끝난 후에 x-pack의monitor를 통해elasticsearch의 인덱스 속도는 몇 백 초의 인덱스 속도에 불과하고 같은 설정보다 훨씬 작으며 최적화된 다른es집단이 없다는 것을 발견했다.문제가 생겼는데, 무슨 이유일까

질문 포지셔닝:

오후에 바빠서 리허설 시간이 없어서 다른 동료에게 리허설을 시키고 오후에 퇴근할 때 무슨 이유를 물어보라고 했습니다. 동료가 저에게logstash 문제라고 말했습니다. 저는 믿었습니다. 왜냐하면 그는 이전의logstash 설정을 비교했기 때문입니다. 소비kafka 주제의 설정은 이전의 topics_pattern=>["server1.history", "server2.history"] topics_로 변경pattern => [".*history"];이 대답에 대해 나는 믿었다. 나는 그에게 비교 테스트를 했느냐고 물었다.긍정적인 대답을 했다고 대답하다.좋아, 문제를 찾으면 밥 먹으러 갈 수 있어..

.결국 저녁 8시에 회사 밖으로 돌아왔는데 동료가 와서 나에게 문제가 있다고 말했다

마침 내가 시간이 있어서 내가 직접 조사할게. 비록 과정이 좀 번거롭지만

우선 저는 동료가 말한 카프카의 데이터가 느린 문제를 조사했습니다.나는 스스로 소비 명령으로 생산 데이터가 많은 토픽의 최신 데이터, 카프카-console-consumer를 소비한다.sh --bootstrap-server:localhost:9092 --topic server.history ;육안으로 보면 뚜렷한 데이터의 발생이 결코 느리지 않다.그럼 문제는 카프카 문제가 아니야.나도 카프카에 큰 문제가 생기는 것을 본 적이 없다

그리고 logstash의 소비 속도 문제를 조사합니다.나는 logstash의 출력을 stdout로 설정했다.육안으로 봐도 소비가 느리지 않다.그럼 문제는logstash의 소비가 느린 문제도 아니에요

나머지 조사점은 바로 logstash의 output 문제입니다.elasticsearch로 바꾼 후에 elasticsearch에 들어간 데이터가 몇 백/초라는 것을 발견했는데 문제가 매우 크다는 것을 알 수 있다

나는 과감하게logstash의output 목표를 다른 정상적이고 속도가 빠른elasticsearch 집단에 주었다.바로 이 집단elasticsearch의 인덱스 속도는 단번에 수천 초(아직 최적화되지 않았고 후기 최적화 이후에는 몇 만 초)이다.문제가 새로운elasticsearch 집단에 있음을 설명합니다

집단 설정을 간단하게 비교한 결과 큰 차이가 없고 그룹에서'새로운elasticsearch 집단과 이전의 집단이 어떤 차이가 있느냐'는 질문을 보냈다.나는 답을 얻을 줄 알았다. "다르지 않다"

그 결과 답은 "이번에 사용한 디스크는 아리운의oss디스크"였다.나는 어쨌든 이것이 무슨 디스크인지 모른다.그리고 나서 나는 엘라스틱 검색 서버에 올라가 보았다

[root@online-log-elasticsearch-002 ~]# top

top - 21:53:28 up 1 day, 10:30,  1 user,  load average: 2.16, 1.98, 1.65

Tasks:  94 total,   2 running,  92 sleeping,   0 stopped,   0 zombie

%Cpu(s):  15.4/12.0   27[|||||||||||||||||||||||||||                                                                         ]

KiB Mem :  8010196 total,   507524 free,  7048124 used,   454548 buff/cache

KiB Swap:        0 total,        0 free,        0 used.   702952 avail Mem

add filter #1 (ignoring case) as: [!]FLD?VAL

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                               

21285 elastic   20   0 1850420  36896   1812 S 102.2  0.5 736:00.98 ossfs online-all-log /data/ -ourl=http://oss-cn-hangzhou-internal.aliyuncs.com                        

16719 elastic   20   0  9.857g 6.518g  11656 S  11.0 85.3   3:24.11 /usr/jdk1.8.0_162/bin/java -Xms6g -Xmx6g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75+

top에서 볼 수 있듯이 21285 elastic 20 1850420 36896 1812 S 102.2 0.5 736:00.98 ossfs online-all-log/data/-ourl=http://oss-cn-hangzhou-internal.aliyuncs.comossfs 서비스는 100% 상하의 cpu를 차지한다.문제가 포지셔닝되었다.메일을 보냈어요

다음날 운영 디스크를 다시 교체합니다.디스크를 바꾼 후에문제 해결..

문제 해결 과정 반성:

문제를 배열하고 한 걸음 한 걸음 문제점을 확정해야만 문제를 해결할 수 있다.추측은 문제를 해결할 방법이 없다.그리고 논증하러 가야 한다고 추측했다

다음으로 전송:https://www.cnblogs.com/ytys/p/9810604.html

이 내용에 흥미가 있습니까?

현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:

다양한 언어의 JSON

JSON은 Javascript 표기법을 사용하여 데이터 구조를 레이아웃하는 데이터 형식입니다. 그러나 Javascript가 코드에서 이러한 구조를 나타낼 수 있는 유일한 언어는 아닙니다. 저는 일반적으로 '객체'{}...

텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.

CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.

2018.10.9 온라인에서 엘라스틱 리서치의 쓰기 속도가 매우 느린 것을 발견했는데, 원래 주범은 아리운이 서비스하는 OSS의 냄비였는데...

좋은 웹페이지 즐겨찾기