EC2 인스턴스의 Ubuntu 12.04에서 I / O 대기로 인한 높은로드


9

우분투 서버 12.04를 사용하고 있는데로드 원인을 찾는 데 문제가 있으며 지난 주부터 서버의 응답 시간이 변경되었습니다.

Linux 문제 해결, 1 부 : 높은로드를 읽은 후

CPU 및 RAM에 문제가없는 것 같습니다. 이로 드는 출력을 얻은 명령 을 사용하여 I / O 바인딩로드 와 관련이있을 수 있습니다top

로드 및 메모리 사용량

여기에는 97.6%waRAM이 비어 있고 스왑이 사용되지 않습니다.

다음은 iostat거기에 뿌리 는 명령의 출력입니다89% iowait

ubuntu@ip-my-sys-ubuntu:~$ iostat
Linux 3.2.0-58-virtual (ip-172-31-6-203)    02/19/2015  _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.05    0.01    3.64   89.50    3.76    0.03

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvdap1           69.91         3.81       964.37     978925  247942876

나는 또한 iotop수정 간격이 99 % I / O를 나타내는 디스크 쓰기를 관찰자로 사용했습니다.1266 KB/s

여기에 이미지 설명을 입력하십시오

여기에 이미지 설명을 입력하십시오

나쁜가요? 응답 시간이 줄어 듭니다. 이 원인은 무엇입니까?

다른 사람들이 묻는 EDITS

iftop O / P

                  12.5kb             25.0kb            37.5kb             50.0kb       62.5kb
└─────────────────┴──────────────────┴─────────────────┴──────────────────┴──────────────────
ip-12-1-1-111.ap-southeast-1.  => 115.231.218.130                      0b   2.04kb   522b
                                 <=                                      0b   1.53kb   393b
ip-112-1-1-111.ap-southeast-1.  => 62.snat-111-91-22.hns.net.in      1.52kb  1.52kb  1.72kb
                                 <=                                    208b    208b    262b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.141.177.mtnl.      0b    480b    240b
                                 <=                                      0b    350b    175b
ip-112-1-1-111.ap-southeast-1.  => ip-112-11-1-1.ap-southeast-1.co      0b    118b    178b
                                 <=                                      0b    210b    292b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.194.119.mtnl.      0b      0b    240b
                                 <=                                      0b      0b    175b

TX:             cum:    123kB   peak:   3.72kb               rates:   1.67kb  2.02kb  1.78kb
RX:                    51.5kB           4.88kb                        1.19kb   989b    918b
TOTAL:                  174kB           8.60kb                        2.86kb  2.98kb  2.68kb

~의 출력 iostat -x -k 5 2

ubuntu@ip-111-11-1-111:~$ iostat -x -k 5 2
Linux 3.2.0-58-virtual (ip-111-11-1-111)        03/04/2015      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.75    0.01    4.74   22.72    4.06   64.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00   263.80    0.42  109.42     7.28  1572.36    28.76     1.92   17.52   17.57   17.52   2.31  25.39

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.97    0.00    4.77   76.34    9.92    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00    35.69    0.00   85.88     0.00   438.93    10.22   137.55 1612.71    0.00 1612.71  11.11  95.42

@ 쇼 단쇼 포인트 2

여기에 이미지 설명을 입력하십시오

iotop -a

여기에 이미지 설명을 입력하십시오


1
디스크 읽기 및 쓰기가 0 인 99 % IOwait가 좋지 않습니다. 여기서 serverfault.com/questions/426181/… I / O는 디스크 활동뿐만 아니라 네트워크와 관련이있을 수 있습니다. 예를 들어 iftop (및 기타 도구)으로 확인할 수 있습니까?
Andrey Sapegin

@AndreySapegin 님이 iftop
Straw Hat

문제는 AWS 인스턴스가 배포 된 디스크에 문제가 있다고 생각합니다. 현재 인스턴스의 AMI를 생성하고이를 사용하여 새 인스턴스를 시작했습니다. 이제 I / O에 추가로드가 없습니다.
Straw Hat

@StrawHat은 첫 번째 인스턴스의 디스크에 문제가 있다고 생각합니까?
sbrattla

@ sbrattla 아뇨. 며칠 후 동일한 문제가 튀어
밀짚 모자를

답변:


2

디스크에 닿지 않고 postfix 대기열에서 조심스럽게 mysql 서비스를 조정하십시오 .I / O에 민감한 대기열에 많은 전자 메일이있을 수 있습니다 (예 : 임의의 읽기 동작으로 지연되는 작은 Iten).

귀하의 이메일 시스템은 스패머의 릴레이로 사용되었습니다.

postfix documentation을 보고 MTA에 대한 릴레이 액세스를 제한하십시오.


mysql을 RDS 인스턴스로 옮기면 작동합니까?
Straw Hat

1
일종의 주요 문제는 iops를 먹는 postfix 대기열에 많은 수의 itens가 있기 때문에 qshape deferred명령으로 볼 수 있습니다 .
fgbreel

postconf: warning: /etc/postfix/main.cf: unused parameter: virtual_mailbox_limit_maps=proxy:mysql:/etc/zpanel/configs/postfix/mysql-virtual_mailbox_limit_maps.cf
밀짚 모자

postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_bind_address=127.0.0.1이 오류가 발생했습니다qshape deferred
Straw Hat

1
귀하의 postfix가 잘못 구성되었을 수 있다고 생각하지만 현재 문제가있는의 이메일 수를 살펴보십시오 /var/lib/postfix/deferred. hold추가 조사 또는 정리를 위해 대기열로 옮깁니다.
fgbreel

1

iostat 및 iotop을 사용하여 추가 정보를 수집 한 후 편집
가능 사용 가능한 IOPS가 부족할 때 디스크가 100 %로드됩니다. iostat에 따라 일정한 50+ IOPS (85w / s-35 개의 병합 된 w / s)가 있습니다. EC2 인스턴스, 특히 저렴한 인스턴스는 지속적인 IOPS (30-50 IOPS 범위)에 강력한 제한이 있습니다.

새로운 iotop 출력에 따라 mysql과 bounce 모두 상당한 양의 IOPS를 먹고 있습니다. 그러나 iotop의 출력은 완전하지 않거나 적어도 정렬이 잘못되었습니다. "iotop -a"정렬을 한 번 IOPS로, 다른 시간을 디스크 쓰기로 다시 실행할 수 있습니까?

원래 답변
내기 : "바운스"프로세스는 Amazon에서 제공하는 가상 디스크 장치를 질식시키는 많은 동기화 된 쓰기를 발행합니다 (어떻게 사용하고 있습니까? EC2 디스크는 지속적인 I / O에 대한 엄격한 규칙을 가지고 있습니다).

어쨌든, 굽기 I / O 대역폭이 때때로 어려울 수있는 것을 식별하십시오. iotop은 매우 유용한 도구이지만 때로는 필요한 정보를 제공하지 않습니다. 우리는 더 깊이 가야합니다. 따라서 다음 조언을 따르십시오.

  1. 먼저 처리중인 I / O 유형과 영향을받는 블록 장치를 식별해야합니다.
    다음 명령을 실행하십시오 : iostat -x -k 5 2. 두 결과 세트를 모두보고하십시오.
  2. 그런 다음 I / O를 기다리는 프로세스를 식별해야합니다 .
    이를 위해 "top"을 사용할 수있는 경우 : 시작하고 Shift + F (F)를 누른 다음 w를 입력하고 Enter를 누른 다음 Shift + r (R)을 누르십시오. 첫 번째 프로세스는 D 또는 D + 상태의 프로세스입니다 (예 : 디스크 / 네트워크 대기 중). 목록을 다시보고하십시오.
  3. iotop을 사용하여 프로세스의 누적 I / O 값을 표시하십시오 . 약 1 분 동안
    실행 iotop -a하여 여기에 출력을 붙여 넣으십시오.

iostat -x -k 5 2 또한 질문에 추가됨
Straw Hat

1

조금 늦었지만 비슷한 컴퓨터에서 같은 문제가 발생하여 문제가 손상된 MySQL 테이블이라는 것을 알았습니다. 이러한 테이블 중 일부에 많은 데이터가 있었으므로 많은 I / O 대기 시간이 발생했습니다.

에서 봐 /var/log/mysql/error.log또는 사용은 mysqlcheck찾을 수 및 수리 데이터를 손상.


0

위에서 언급했듯이 EC2 인스턴스에는 IO 한도가 제공되거나 아마도 IO를 현명하게 제공하지 않는 Amazon EBS 표준 볼륨에 백업되어있을 가능성이 큽니다. 그 모습이 이 페이지를 - 그것은 이벤트 아마존 다른 볼륨 유형을 설명합니다.

느린 종류의 볼륨이 있더라도 여전히 적당히 빨리 쓸 수는 있지만 부하가 본질적으로 임의적 인 경우 (SQL 항목) 보일 수 있으므로 IOPS를 업그레이드 할 수 있습니다 일반적으로 SQL 성능에 상한을두기 때문에 용량.

따라서 숫자에서 표준 스토리지를 사용하는 IOPS가 부족한 것으로 보입니다. 더 빠른 스토리지를 구입하는 것은 그렇게 비싸지 않습니다. 이것 좀 봐 .


-3

디스크가 비 DMA 모드 일 수 있습니다. 드라이브의 DMA 상태를 확인하십시오. (hdparm 명령)

그렇지 않은 경우 다른 무언가가 많은 인터럽트를 생성 할 수 있습니다. 오래된 DOS 시대의 사람들을 기억하십니까?


EC2는 가상화 플랫폼이며 가상 디스크를 사용합니다. 여기에 범인이 아닌 DMA. 어쨌든 IRQ 스톰은 디스크가 아닌 CPU에 큰 타격을줍니다.
shodanshok

예, IRQ는 인터럽트를 의미합니다.
Overmind

EC2는 가능한 한 이런 종류의 문제에서 제거되었습니다. I / O는 인스턴스 유형에 의해 결정되며 결국에는 많은 용량을 가진 고가의 SAN 솔루션에 의해 결정됩니다.
MrMajestyk
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.