흑연이 무작위로 데이터 수집을 중지 함

수집, 통계, JMXTrans를 통해 데이터를 수집하는 Graphite 서버가 있습니다. 우리가 여전히 가지고있는 데이터를 살펴보면 카본 캐시 크기가 50K에서 4M으로 증가하는 것을 볼 수 있습니다. 수집 된 메트릭 수가 증가하지 않습니다 (수신 된 메트릭은 약 300K로 안정적 임). 평균적으로 쿼리 수가 1000 개에서 1500 개로 증가했습니다.

이상하게도 캐시 크기가 증가하면 CPU 사용량이 100 % (CPU 4 개)에서 50 %로 약간 감소합니다.

이상하게도, 디스크에서 옥텟을 읽을 경우 숫자가 증가하고 쓴 옥텟 수가 감소합니다.

우리는 주로 기본값으로 탄소 구성을 가지고 있습니다 :

• MAX_CACHE_SIZE = inf
• MAX_UPDATES_PER_SECOND = 5000
• MAX_CREATES_PER_MINUTE = 2000

분명히, 우리 시스템에서 어떤 변화가 있었지만, 우리는이 원인을 어떻게 찾을 수 있는지 또는 어떻게 이해할 수 없습니다 ...

어떤 도움?

이것은 흑연 스택의 버그가 아니라 IO 병목 현상입니다. 아마도 스토리지의 IOPS가 충분하지 않기 때문일 것입니다. 이로 인해 대기열이 계속 구축되고 4M에서 오버플로됩니다. 이 시점에서 대기열에있는 많은 양의 데이터가 손실됩니다. 이 데이터는 나중에 그래프에서 임의의 '갭'으로 반영됩니다. 시스템은 메트릭을 수신하는 규모에 따라 유지할 수 없습니다 . 계속 채워지고 넘칩니다 .

이상하게도 캐시 크기가 증가하면 CPU 사용량이 100 % (CPU 4 개)에서 50 %로 약간 감소합니다.

IO 대기로 인해 시스템이 스와핑을 시작하고 CPU가 많은 '유휴 시간'을 갖기 때문입니다.

컨텍스트를 추가하기 위해 약 40K 메트릭을 수신하는 시스템에서 AWS에 500 개의 프로비저닝 된 IOPS가 있습니다. 대기열은 50K로 안정적입니다.

다른 응답자는 디스크 I / O 병목 현상을 언급했습니다. 이 문제의 또 다른 원인으로 네트워크 병목 현상에 대해 이야기하겠습니다.

내 환경에서는 프런트 엔드 UI 서버 클러스터 (httpd, memcached)를 실행합니다. 중간 계층 릴레이의 또 다른 클러스터 (전달 및 집계를 수행하는 탄소-중계 릴레이); 백엔드 계층 (httpd, memcached, carbon-c-relay 및 carbon-cache) 각 클러스터는 EC2의 여러 인스턴스와 총 프로세스에서 분당 1,500 만 메트릭으로 구성됩니다.

집계 "합계"함수에 의해 생성 된 메트릭에 대해 차이가 발생하고 집계 된 값이 잘못되었습니다 (너무 낮음). 중간층에서 탄소 -c- 릴레이를 다시 시작하면 문제가 완화되지만 몇 시간 후에 간격이 다시 나타나기 시작합니다.

중간 계층과 백엔드 계층 모두에서 집계가 이루어졌습니다 (백엔드 계층은 중간 계층에서 전달 된 집계 된 메트릭을 집계했습니다).

중간 계층 호스트는 CPU 바운드가 아니고 디스크 바운드가 아니며 메모리에 대한 제약이 없습니다. 이것은 릴레이 절차를 다시 시작한 후 몇 시간 만에 문제가 발생한다는 사실과 결합하여 네트워크 병목 현상이 발생했음을 의미합니다. 우리의 솔루션은 단순히 중간 계층에 더 많은 호스트를 추가하는 것입니다. 이렇게하면 집계 된 메트릭이 올바르게 작동하고 차이가 발생하지 않습니다.

병목 현상이 발생한 네트워크 스택의 정확한 위치는? 당신에게 말할 수 없었습니다. 리눅스 호스트에 있었을 수도있다. 아마존쪽에 있었을 수도 있습니다.