☰

클라우드 인스턴스에서 높은 소프트웨어 중단 비율의 근본 원인 찾기

tag-icon • tag-icon top
클라우드 인스턴스에서 높은 소프트웨어 중단 비율의 근본 원인 찾기

top을 사용하여 검사할 때 이상한 로드 패턴을 보여주는 클라우드 인스턴스가 있습니다.

top - 21:39:28 up 456 days,  8:39,  2 users,  load average: 1.44, 1.19, 1.10
Tasks: 100 total,   1 running,  99 sleeping,   0 stopped,   0 zombie             
%Cpu(s):  5.2 us,  0.7 sy,  0.0 ni, 57.5 id,  1.7 wa,  0.0 hi, 34.9 si,  0.0 st
KiB Mem : 16134024 total,   160756 free,  3009108 used, 12964160 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 12620768 avail Mem

위 제목에서 알 수 있듯이 SI(소프트웨어 중단) 비율은 35%입니다.

소프트웨어 인터럽트를 확인해보니 60초 동안 약 20K가 증가했기 /proc/interrupts때문에 범인일 가능성이 높습니다 .Rescheduling interrupts

지금 내가 갇힌 부분은 어떤 프로세스가 이러한 수준의 재배열을 야기했는지 알아내려고 노력하는 것입니다.

무엇을 해야할지나알아내다근본 원인실행 중인 서비스를 건드리지 마세요.?

추가 정보:

  • vCPU 2개, 16G 메모리 KVM 기반 클라우드 인스턴스의 AWS 기반 Debian 9(스트레치).
  • Linux ip-10-0-0-138 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux
  • 이 인스턴스는 다른 서비스에 대한 LB를 갖고 실행됩니다 nginx.varnish

편집하다: 근본 원인을 파악하기 전에 다른 운영자가 인스턴스를 다시 시작했습니다. 다시 시작한 후에도 동일한 부하에 대해 %SI1.5%를 초과하지 않았으며 Rescheduling interrupts60초 이내에 이전 값의 3분의 1 미만으로 떨어졌습니다.

답변1

60초에 약 20K입니다.

초당 400개 미만이며, 많은 코어가 잠자고 정기적인 작업을 수행하는 시스템에서는 대략적으로 이러한 작업이 주기적으로 깨어납니다.

그러나 2코어(CPU 코어 1개와 하이퍼스레드 2개 이상) 서버에서는 라이브 오디오 시스템(예: 잭)을 실행하지 않을 수도 있습니다. 또한 최대 절전 모드로 전환할 수 있는 코어는 하나만 있습니다.

vCPU 2개, 16G 메모리 KVM 기반 클라우드 인스턴스의 AWS 기반 Debian 9(스트레치).

아하!

실제 인터럽트 핸들러 소스 코드의 주석 비교커널 버전에서:

/*
 * KVM uses this interrupt to force a cpu out of guest mode
 */

즉, 가상 머신이나 소프트웨어에 전혀 문제가 없을 수도 있습니다. 단지 KVM 하이퍼바이저가 다른 작업을 수행하기 위해 현재 가상 머신에서 사용 중인 CPU 코어 중 하나를 전환하려고 한다는 것입니다.

아마도 이는 로드가 가볍고 Amazon은 지속적으로 CPU 코어의 전체 성능을 기대하지 않기 때문에 더 많은 사용자에게 동일한 CPU 시간을 판매할 수 있다고 생각하기 때문일 것입니다.

실험을 해보세요: 그것을 실행 stress -c 2하고 높은 부하(의심할 바 없이 페이로드 성능에 나쁜 영향)가 일정 조정 인터럽트 횟수를 크게 줄이는지 확인하십시오.

그러나 실제로 얻을 수 있는 효과는 매우 작습니다. AWS는 낭비된 시스템에 더 높은 성능을 보상할 것이라고 생각합니다. 따라서 문제는 이러한 일정 조정 중단이 용납될 수 없는지 여부입니다. 이는 주로 두 CPU의 절반보다 적은 리소스를 사용할 때 발생할 수 있습니다. 스레드.

관련 정보