☰

내 서버 부하가 높은 이유를 알아낼 수 있는 방법이 있나요?

tag-icon • tag-icon logs freeze load
내 서버 부하가 높은 이유를 알아낼 수 있는 방법이 있나요?

방금 매우 높은 로드(75!)로 인해 시스템이 충돌했기 때문에 CentOS 6.3 시스템을 원격으로 다시 시작해야 했습니다. WordPress 블로그(mySQL + PHP)를 제공하는 웹/메일 서버입니다.

원인을 분석하고 파악할 수 있는 로그가 있습니까?

어제 이벤트와 관련하여 시스템으로부터 받은 이메일은 다음과 같습니다.

This is an automated message notifying you that the 5 minute load average on your system is 75.91.
This has exceeded the 10 threshold.

One Minute      - 83.24
Five Minutes    - 75.91
Fifteen Minutes - 39.35

top - 22:25:30 up 122 days,  7:28,  0 users,  load average: 99.14, 80.70, 42.31
Tasks: 298 total,   1 running, 297 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.2%us,  0.5%sy,  0.0%ni, 98.1%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1020176k total,   956828k used,    63348k free,     2788k buffers
Swap:  4194296k total,  1391900k used,  2802396k free,    25164k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   1 root      20   0 19352  448  444 S  0.0  0.0   0:08.27 /sbin/init
   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [kthreadd]
   3 root      RT   0     0    0    0 S  0.0  0.0   0:09.43 [migration/0]
   4 root      20   0     0    0    0 S  0.0  0.0   1884:48 [ksoftirqd/0]
   5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 [migration/0]
   6 root      RT   0     0    0    0 S  0.0  0.0   0:06.06 [watchdog/0]
   7 root      RT   0     0    0    0 S  0.0  0.0   0:07.81 [migration/1]
   8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 [migration/1]
   9 root      20   0     0    0    0 S  0.0  0.0   7:25.62 [ksoftirqd/1]
  10 root      RT   0     0    0    0 S  0.0  0.0   0:04.58 [watchdog/1]
  11 root      20   0     0    0    0 S  0.0  0.0   4:48.95 [events/0]
  12 root      20   0     0    0    0 S  0.0  0.0   9:13.85 [events/1]
  13 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [cgroup]
  14 root      20   0     0    0    0 S  0.0  0.0   0:08.21 [khelper]
  15 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [netns]
  16 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [async/mgr]
  17 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [pm]
  18 root      20   0     0    0    0 S  0.0  0.0   0:21.72 [sync_supers]
  19 root      20   0     0    0    0 S  0.0  0.0   0:20.65 [bdi-default]
  20 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [kintegrityd/0]
  21 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [kintegrityd/1]
  22 root      20   0     0    0    0 S  0.0  0.0   5:26.09 [kblockd/0]
  23 root      20   0     0    0    0 S  0.0  0.0   0:22.90 [kblockd/1]

이것이 도움이 되는지 잘 모르겠습니다.

모든 것이 CPU를 0% 사용하고 있는 것 같습니다.

여기 또 다른 이메일이 있습니다..

This is an automated message notifying you that the 5 minute load average on your system is 70.53.
This has exceeded the 10 threshold.

One Minute      - 94.79
Five Minutes    - 70.53
Fifteen Minutes - 32.68

top - 22:23:34 up 122 days,  7:26,  0 users,  load average: 96.88, 74.74, 35.91
Tasks: 283 total,   2 running, 281 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.2%us,  0.5%sy,  0.0%ni, 98.1%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1020176k total,   970440k used,    49736k free,     3196k buffers
Swap:  4194296k total,  1249404k used,  2944892k free,    29836k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
6715 apache    20   0  217m 7804 3252 D  1.9  0.8   0:00.28 /usr/sbin/httpd -k start -DSSL 
6770 apache    20   0  218m 8772 3368 D  1.9  0.9   0:00.28 /usr/sbin/httpd -k start -DSSL 
6799 apache    20   0  301m 8088 3184 D  1.9  0.8   0:00.14 /usr/sbin/httpd -k start -DSSL 
7265 root      20   0 15160 1220  808 R  1.9  0.1   0:00.02 /usr/bin/top -c -b -n 1 
7266 root      20   0 15160 1220  808 R  1.9  0.1   0:00.02 /usr/bin/top -c -b -n 1 
   1 root      20   0 19352  448  444 S  0.0  0.0   0:08.27 /sbin/init 
   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [kthreadd]
   3 root      RT   0     0    0    0 S  0.0  0.0   0:09.43 [migration/0]
   4 root      20   0     0    0    0 S  0.0  0.0   1884:48 [ksoftirqd/0]
   5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 [migration/0]
   6 root      RT   0     0    0    0 S  0.0  0.0   0:06.06 [watchdog/0]
   7 root      RT   0     0    0    0 S  0.0  0.0   0:07.81 [migration/1]
   8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 [migration/1]
   9 root      20   0     0    0    0 S  0.0  0.0   7:22.58 [ksoftirqd/1]
  10 root      RT   0     0    0    0 S  0.0  0.0   0:04.58 [watchdog/1]
  11 root      20   0     0    0    0 S  0.0  0.0   4:48.95 [events/0]
  12 root      20   0     0    0    0 S  0.0  0.0   9:13.85 [events/1]
  13 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [cgroup]
  14 root      20   0     0    0    0 S  0.0  0.0   0:08.21 [khelper]
  15 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [netns]
  16 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [async/mgr]
  17 root      20   0     0    0    0 S  0.0  0.0   0:00.00 [pm]
  18 root      20   0     0    0    0 S  0.0  0.0   0:21.72 [sync_supers]

예, 저는 Apache를 사용하고 있습니다. 75는 지난 5분 동안의 로드 평균입니다.

답변1

사용된 스왑 양을 보면 스왑이 원인일 수 있음을 알 수 있습니다. vmstat의 출력은 문제 시나리오에서 이를 더 잘 보여줍니다.

vmstat 1 30

그러나 top이나 vmstat는 사후 문제 진단에 적합하지 않습니다.

나의 일반적인 조언은 이 패키지를 설치하는 것입니다 sysstat. 이를 통해 시스템 측정항목을 주기적으로 저장한 다음 해당 정보를 검색할 수 있습니다 sar. Sysstat는 다양한 세부 정보로 구성할 수 있지만 기본 구성에서는 CPU 사용량, 시스템 로드, 페이징 및 스와핑에 대한 예비 개요를 제공합니다.

yum install sysstat

sar 
sar -q
sar -B
sar -W

그러나 이것이 도움이 되지 않으면 더 자세히 살펴보는 것이 좋습니다. 프로세스 대기열(로드 평균) 외에도 일반적인 성능 지표를 통해 즉시 확인할 수 없는 작업이 진행 중일 수 있습니다. 한 가지 가능성은 CPU가 너무 많은 인터럽트 요청을 처리하느라 시스템에 남아 있는 사용 가능한 처리 시간 동안 프로세스가 대기열에 대기하게 되는 것입니다.

그렇다면 /proc/interrupts에서 몇 가지 단서를 찾을 수 있습니다.

cat /proc/interrupts

네트워크 어댑터나 로컬 타이머가 비정상적으로 많은 수의 인터럽트를 표시하고 있는 것일까요?

이는 익숙해지고 perf다음에 문제가 발생할 때까지 기다리는 것으로 귀결될 수 있습니다. 문제가 발생하는 즉시 로깅을 시작하거나, 평균 로드가 높을 때 트리거되는 스크립트를 사용하여 프로세스를 자동화하세요.

perf record -a

perf report

Perf는 시스템 작업에 대한 매우 자세한 보기를 제공하지만 많은 양의 데이터를 수집하고 상당한 오버헤드를 발생시키므로 지속적으로 실행하는 것이 비현실적입니다.

CentOS 6.3의 경우 로컬 타이머와 관련된 커널 소스 코드의 버그를 해결하는 CentOS 6.4로 업그레이드한 후 이상하게 높은 로드 평균이 사라질 수 있습니다. 그러나 하드웨어 공급업체에서 제공한 특정 드라이버로 인해 문제가 발생할 수도 있습니다.

답변2

로깅을 통한 일부 시스템 모니터링이 없으면 사후에 높은 시스템 부하의 원인을 파악하기가 어렵습니다.

성능 저하의 일반적인 원인은 RAM 고갈로 인한 시스템 스래싱입니다.

대부분의 Unix 시스템에서 스래싱은 높은 로드를 유발하지 않지만 Linux는 이 측정항목에서 I/O를 기다리는 프로세스를 고려하므로 여기서도 그럴 수 있습니다.

답변3

어떤 프로세스에 문제가 있는지 확인하려면 다음을 수행하세요.

실행 top -H( -H디스플레이 스레드 활성화)

키보드 단축키는 버전에 따라 다릅니다.

이전 버전(3.3 이전?)의 경우:

Shift+를 눌러 o정렬 옵션을 불러옵니다.
그런 다음 w프로세스 상태별로 정렬합니다.
그런 다음 Enter홈 페이지로 돌아갑니다.
그런 다음 Shift+를 R사용하여 정렬을 반대로 합니다.

최신 상단(3.3? 이상) 사용:

f필드 옵션을 불러오려면 누르세요 .
화살표 키를 사용하여 로 이동 S = Process Status한 후 을 누르세요 s. 홈 페이지로 돌아가
려면 누르세요 . +를 누르면 정렬이 반대로 됩니다.q
ShiftR

그런 다음 해당 S열에 D있는 프로세스를 찾으십시오 R(이제 맨 위에 있어야 합니다). 이는 시스템 부하에 영향을 미치는 프로세스입니다.

프로세스가 나타나면 D"방해받지 않고 잠자기"를 의미합니다. 일반적으로 이는 프로세스가 I/O(디스크, 네트워크 등)를 기다리고 있을 때 발생합니다.
프로세스에 표시가 나타나면 R정상적인 계산을 수행하고 있다는 의미입니다.

이러한 프로세스가 수행하는 작업에 대해 자세히 알아보려면 다음을 수행하세요.

오래된 상의와 함께:

f그런 다음 y해당 필드를 활성화하려면 누르세요 WCHAN.

새로운 상의와 함께:

f필드 옵션을 불러오려면 누르세요 .
화살표 키를 사용하여 으로 이동 WCHAN = Sleeping in Function한 후 을 눌러 d활성화하세요.
그런 다음 q홈 페이지로 돌아갑니다.

시스템에 필요한 커널 옵션이 있고 wchan 파일이 시스템에 존재하는 경우(어디인지, 이름이 무엇인지 잊어버렸습니다), 이 WCHAN필드는 현재 프로세스에서 실행 중인 커널 기능을 표시해야 합니다(필드에 모든 항목에 대해 a -또는 a 만 표시되는 경우 ?지원되지 않습니다).
여기에서 Google을 검색하면 괜찮을 것입니다.

wchan 지원이 없다면 언제든지 strace프로세스를 살펴보고 그들이 무엇을 하고 있는지 확인할 수 있지만 이는 어려운 방법입니다.

관련 정보