요청 빈도가 감소 할 때 왜 응답 시간이 폭발합니까?

수정 : 응답 시간 ( %D)은 ms가 아닙니다! 1

이것은이 패턴의 기이함에 대해서는 아무 것도 바꾸지 않지만 실제로는 덜 파괴적이라는 것을 의미합니다.

응답 시간이 요청 빈도와 반비례하는 이유는 무엇입니까?

요청 처리량이 적을 때 서버가 더 빠르게 응답하지 않아야합니까?

Apache가 적은로드로 "이용"하는 방법에 대한 제안이 있습니까?

이 패턴은 주기적입니다. 즉, 심야부터 이른 아침까지 노출이 분당 약 200 건 미만으로 감소하면 (자연적인 사용자 활동으로 인해) 표시됩니다.

요청은 1000 자 미만의 JSON을 전송하는 매우 간단한 POST입니다.이 JSON은 텍스트 파일에 추가됩니다. 답장은 "-"입니다.

그래프에 표시된 데이터는 Apache 자체로 기록되었습니다.

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

이것은 데이터 센터에서 일반적인 동작입니다. 응답 시간이 느린 시간은 일반적으로 배치 창이라고하는 것과 일치합니다. 이 기간은 사용자 활동이 적고 배치 프로세스를 실행할 수있는 기간입니다. 이 기간 동안 백업도 수행됩니다. 이러한 활동으로 인해 서버 및 네트워크의 리소스가 손상되어 성능 문제가 발생할 수 있습니다.

문제를 일으킬 수있는 몇 가지 리소스가 있습니다.

• 높은 CPU로드 이로 인해 아파치가 시간 조각이 요청을 처리 할 때까지 대기 할 수 있습니다.
• 메모리 사용량이 많습니다. 이를 통해 아파치가 디스크에서 리소스를 읽지 않고도 리소스를 제공 할 수있는 버퍼를 플러시 할 수 있습니다. 또한 아파치 작업자의 페이징 / 스왑이 발생할 수 있습니다.
• 디스크 활동이 많습니다. 이로 인해 콘텐츠를 제공하는 데 지연이 발생하여 디스크 I / O 작업이 대기 될 수 있습니다.
• 높은 네트워크 활동. 이로 인해 패킷이 전송 대기열에 들어가고 재 시도가 증가하며 서비스가 저하 될 수 있습니다.

나는 sar이와 같은 문제를 조사 하는 데 사용 합니다. 데이터를 매일 데이터 파일로 atsar수집 sar하는 데 사용할 수 있습니다 . 이것들은 성능이 정상인 낮 동안의 시스템 동작이 어떤지, 성능이 가변적 일 때 과장된지를 확인하기 위해 조사 될 수 있습니다.

munin자원 이용률을 수집하고 그래프로 표시하는 다른 시스템이나 다른 시스템으로 시스템을 모니터링하는 경우 일부 표시기가있을 수 있습니다. 나는 여전히 sar더 정확한 것을 발견한다 .

같은 도구가 있습니다 nice및 ionice그 영향을 최소화하기 위해 일괄 처리에 적용 할 수 있습니다. CPU 또는 I / O 문제에만 효과적입니다. 메모리 또는 네트워크 활동 관련 문제를 해결하지 못할 것입니다.

백업 활동을 별도의 네트워크로 옮기고 네트워크 경합을 줄입니다. 일부 백업 소프트웨어는 사용될 대역폭을 제한하도록 구성 할 수 있습니다. 네트워크 경합이 해결 될 수 있습니다.

배치 프로세스가 트리거되는 방식에 따라 병렬로 실행되는 배치 프로세스 수를 제한 할 수 있습니다. 이렇게하면 동일한 리소스 경합이 발생할 수 있으므로 배치 프로세스의 성능이 실제로 향상 될 수 있습니다.

요청 발신자가 새 요청을 제출하기 전에 이전 요청이 완료되기를 기다리는 경우 다른 방향으로 발생할 수 있습니다. 이 경우 클라이언트 측 큐잉으로 인해 요청 시간이 늘어 나면 (어떤 이유로 든) 트래픽이 줄어 듭니다.

또는 측정 결과가 될 수 있습니다. 위의 그래프 에 도착한 요청 과 달리 완료된 요청이 표시 되면 요청 처리 시간이 증가함에 따라 비율이 감소합니다 (유한 용량 : D 가정).

@BillThor의 대답 이 맞을 수도 있지만,로드가 적은 기간이 백업 프로세스에 의해 전체적으로 취해지는 것 같지 않습니다 (예 : 기간이 정확하게 일치 함).

다른 설명은 단순히 캐싱입니다. 지정된 스크립트 / 데이터베이스 / 최근에 사용되지 않은 것이 있으면 나머지 운영 체제의 메모리를 확보하기 위해 캐시 된 관련 데이터가 삭제되었을 수 있습니다. 데이터베이스의 인덱스이거나 파일과 관련된 O / S 버퍼 또는 이와 유사한 것입니다. 그런 다음 마지막 쿼리 이후로이 정보가 오래 되었다면 쿼리는이 정보를 재구성해야합니다. 사용량이 많은 기간에는 마지막 쿼리가 빈번하게 발생하므로 발생하지 않습니다. 당신이 낮은 응답 시간보고있는 이유도 설명 할 수 및 바쁜 기간 동안 높은 응답 시간을.

당신이보고있는 것은 통계 문제 일 수있는 것처럼 보입니다. @BillThor의 대답이 옳을 수도 있지만 완벽을 기하기 위해 게시 할 것입니다.

반응 시간 그래프는 백분위 수입니다. 800-1000 요청의 샘플 풀은 이에 대한 좋은 샘플 수이며 50-100 요청 풀은 그리 많지 않을 수 있습니다.

느린 요청의 수가 요청 볼륨의 선형 함수가 아니라고 가정하면 요청의 수의 증가가 느린 요청의 수의 증가를 초래하지 않으면 요청의 양이 많아지면 평균 요청 시간이 줄어 듭니다.

거짓말, 큰 거짓말 및 통계가 있습니다.

내 가설 : 세 가지 범주의 요청이 있습니다.

1. 대부분의 요청을 포함하고 이러한 요청은 모두 200-300 μs 내에 완료되는 정규 가변 스트림입니다.
2. 분당 약 20 개의 요청 (밤에도)의 일정한 속도의 작은 스트림. 각각 완료하는 데 약 2.500 μs가 걸립니다.
3. 분당 약 10 개의 요청 (밤에도)의 일정한 속도로 작은 스트림. 각각 4.000 μs 이상을 차지합니다.

밤에는 분당 50 개의 요청이 20 + 20 + 10에 해당합니다. 따라서 50 % 백분위 수의 결과는 이제 스트림 2의 결과에 크게 좌우됩니다. 그리고 95 % 백분위 수는 스트림 3에 의존하므로 그래프에도 표시 할 수 없습니다.

낮에는 스트림 2 + 3이 95 % 백분위 수 위에 숨겨져 있습니다.

더 많이 볼수록 데이터 수집에 문제가 있다고 생각하는 경향이 있습니다.

우선, TPS와 관련하여 정말 이상한 일이 있습니다. 전체 패턴이 정상인 것처럼 보이지만 오후 9 시쯤에 다시 오전 7시에 매우 급격한 중단이 발생합니다. 피크가 아닌 시간으로 전환하는 동안 일반 차트가 훨씬 매끄 럽습니다.

이는 프로파일에 변경 사항이 있으며 두 가지 유형의 클라이언트가있을 수 있음을 나타냅니다.

1. 오전 7시에서 오후 9시 사이에 대량으로 운영되는
2. 다른 것은 아마도 낮은 볼륨에서 24 시간 내내 작동 할 것입니다.

두 번째 힌트는 약 18:00입니다. 전후에 대부분의 시간, 우리는이 높은 고 TPS 및 낮은 지연 시간 - 볼륨 프로파일을. 그러나 약 18:00에 800-1000 RPM에서 400 RPM 미만으로 급격히 떨어졌습니다. 그 원인은 무엇입니까?

세 번째 힌트는 5 번째 백분위 수 응답 시간의 감소입니다. 실제로 최소 응답 시간을보고 선호 (그러나 5 백분위 가능성이 더 낫다) 두 가지 이유 : 그것은 나에게 말한다 서비스 시간 (즉, 응답 시간 - 대기를) 및 응답 시간은 이블 분포를 따르는 경향이있는 것을 의미 모드 (또는 가장 일반적인 값)이 최소값 바로 위에 있습니다.

따라서 5 번째 백분위 수의 스텝 다운은 시리즈에 갑작스러운 중단이 있으며 분산과 평균 응답 시간이 크게 증가하더라도 실제로 서비스 시간이 단축되었다고 말합니다.

다음 단계

이 단계에서 나는 로그 전과 후의 대량 샘플과 비교하여 18:00의 낮은 볼륨 샘플과 다른 점을 찾기 위해 로그를 자세히 살펴볼 것입니다.

나는 찾을 것이다 :

• 지리적 위치의 차이 (대기 시간이 $ request_time에 영향을 미치는 경우)
• URL의 차이 (없어야 함)
• HTTP 방법의 차이 (POST / GET) (없음이어야 함)
• 동일한 IP의 반복 요청
• 그리고 다른 차이점들 ...

BTW, 18:00 "이벤트"는 데이터 센터 정체 / 활동과 관련이 없다는 증거입니다. 그러기 위해서는 혼잡으로 인해 TPS가 18:00에 떨어질 수 있지만 오후 9시에서 오전 7시 사이에 10 시간 동안 TPS가 지속적으로 매끄럽게 감소하지는 않을 것입니다.