Tải cao do chờ I / O trong Ubuntu 12.04 trên ví dụ EC2

9

Tôi đang sử dụng máy chủ Ubuntu 12.04, gặp sự cố khi tìm nguyên nhân tải, tôi đã thấy sự thay đổi về thời gian phản hồi của máy chủ từ tuần trước

sau khi đọc Linux Xử lý sự cố, Phần I: Tải cao

Có vẻ như không có vấn đề gì với CPU và RAM, và tải này có thể liên quan đến tải bị ràng buộc I / O bằng cách sử dụng toplệnh tôi nhận được sau đầu ra

Tải và sử dụng bộ nhớ

Đây là 97.6%wa, RAM là miễn phí và không sử dụng trao đổi.

Sau đây là đầu ra của lệnh iostatgieo mà có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

Tôi cũng đã sử dụng iotopmà sau khoảng thời gian sửa lỗi hiển thị 99% I / O, Đĩa ghi tôi quan sát là1266 KB/s

nhập mô tả hình ảnh ở đây

và

nhập mô tả hình ảnh ở đây

Là xấu? khi thời gian đáp ứng được hạ xuống. Điều gì gây ra điều này?

EDITS được hỏi bởi những người khác

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

đầu ra của 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

@shodanshok điểm 2

nhập mô tả hình ảnh ở đây

iotop -a

nhập mô tả hình ảnh ở đây

— Mũ rơm
nguồn

1

99% IOwait với 0 đĩa đọc và ghi có vẻ không tốt. Ở đây serverfault.com/questions/426181/, nó được đề cập, rằng I / O có thể không chỉ liên quan đến hoạt động của đĩa, mà còn cả mạng. Bạn có thể kiểm tra nó với, ví dụ, iftop (và các công cụ khác) không?

— Andrey Sapegin

@AndreySapegin đã thêm iftop

— Mũ rơm

Tôi nghĩ vấn đề xảy ra với Disc mà AWS Instance đã được triển khai .. Tôi đã tạo AMI của phiên bản hiện tại và khởi chạy Instance mới bằng cách đó .. Bây giờ không có tải thêm nào trên I / O

— Straw Hat

@StrawHat điều đó có nghĩa là bạn nghĩ rằng có vấn đề gì đó với đĩa trong trường hợp đầu tiên của bạn?

— sbrattla

@sbrattla Không tôi nghĩ. Sau vài ngày, vấn đề tương tự đã xuất hiện

— Mũ Rơm

2

Điều chỉnh dịch vụ mysql của bạn để tránh chạm vào đĩa và xem ra trong hàng đợi hậu tố của bạn, bạn có thể có rất nhiều email vào hàng đợi nhạy cảm I / O (nghĩa là hoãn lại, nó nhỏ với hành vi đọc ngẫu nhiên).

Hệ thống email của bạn đã được sử dụng làm chuyển tiếp cho người gửi thư rác.

Hãy xem tài liệu postfix và hạn chế quyền truy cập chuyển tiếp vào MTA của bạn.

— chữ viết tắt
nguồn

di chuyển mysql sang RDS dụ sẽ hoạt động?

— Mũ rơm

1

Sắp xếp, vấn đề chính là do số lượng itens cao vào hàng đợi hậu tố ăn iops của bạn, bạn có thể thấy bằng qshape deferredlệnh.

— fgenameel 4/03/2015

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

— Mũ rơm

postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_bind_address=127.0.0.1mắc phải những lỗi nàyqshape deferred

— Straw Hat

1

Tôi nghĩ rằng hậu tố của bạn có thể được định cấu hình sai, nhưng đối với vấn đề hiện tại của bạn, hãy xem bạn có bao nhiêu email /var/lib/postfix/deferred. Di chuyển chúng để holdxếp hàng để điều tra thêm hoặc dọn dẹp.

— fgbreel 4/03/2015

1

Được chỉnh sửa sau khi thông tin bổ sung được thu thập bằng i bổ sung và iotop
Đĩa của bạn được tải 100% khi hết IOPS: theo iuler, bạn có 50+ IOPS không đổi (85 w / s - 35 w / s được sáp nhập). Các phiên bản EC2, đặc biệt là giá rẻ, có giới hạn mạnh đối với IOPS được duy trì (trong phạm vi 30-50 IOPS).

Theo đầu ra iotop mới, cả mysql và nảy đều ăn một lượng IOPS đáng kể. Tuy nhiên, đầu ra của iotop dường như chưa hoàn thành hoặc ít nhất được sắp xếp kém. Bạn có thể chạy lại "iotop -a" sắp xếp một lần bằng IOPS và lần khác bằng cách ghi đĩa không?

Câu trả lời ban đầu
Đặt cược của tôi: quá trình "thoát" đang phát hành nhiều lần ghi đồng bộ hóa làm nghẹt thiết bị đĩa ảo do Amazon cung cấp (nhân tiện, bạn đang sử dụng cấu hình nào? Đĩa EC2 có các quy tắc khá nghiêm ngặt để duy trì so với I / O nổ).

Dù sao, việc xác định những gì đang đốt băng thông I / O có thể hơi khó khăn. Mặc dù iotop là một công cụ rất tốt, đôi khi nó không cung cấp cho bạn thông tin cần thiết. Chúng ta cần phải đi sâu hơn. Vì vậy, hãy làm theo những lời khuyên sau:

Trước tiên, chúng ta cần xác định loại I / O đang được xử lý và thiết bị khối bị ảnh hưởng.
Vui lòng chạy lệnh sau : iostat -x -k 5 2. Vui lòng báo cáo cả hai bộ kết quả.
Sau đó, chúng ta cần phải xác định các quá trình chờ đợi cho I / O .
Khi có thể sử dụng "top" cho điều đó: khởi chạy nó, nhấn shift + f (F), sau đó w, sau đó nhập, sau đó shift + r (R). Các quy trình đầu tiên sẽ là một trong trạng thái D hoặc D + (nghĩa là: chờ đĩa / mạng). Vui lòng báo cáo lại danh sách.
Sử dụng iotop để hiển thị các giá trị I / O tích lũy cho các quy trình .
Chạy iotop -atrong khoảng một phút và dán ở đây đầu ra.

— shodanshok
nguồn

iostat -x -k 5 2 và cũng được thêm vào câu hỏi

— Mũ rơm

1

Hơi muộn một chút, nhưng tôi gặp vấn đề tương tự trên một máy tương tự và phát hiện ra rằng vấn đề là một loạt các bảng MySQL bị hỏng. Vì một số bảng này có rất nhiều dữ liệu, nó tạo ra rất nhiều thời gian chờ I / O.

Nhìn vào /var/log/mysql/error.loghoặc sử dụng mysqlcheckđể tìm và sửa chữa dữ liệu bị hỏng.

— ojovirtual
nguồn

0

Như đã nêu ở trên, rất có thể phiên bản EC2 của bạn đi kèm với nắp IO hoặc có thể nó được hỗ trợ trên âm lượng Tiêu chuẩn Amazon EBS mà đơn giản là không cung cấp rất nhiều IO khôn ngoan. Hãy xem trang này - nó mô tả các loại âm lượng khác nhau mà Amazon cung cấp.

Ngay cả khi bạn có loại âm lượng chậm, bạn vẫn có thể viết nhanh một cách hợp lý cho nó, nhưng nếu bản chất tải của bạn là ngẫu nhiên, vì có vẻ như đó là (công cụ SQL), bạn có thể muốn nâng cấp IOPS năng lực, vì điều đó thường đặt giới hạn trên cho hiệu suất SQL.

Vì vậy - từ số của bạn, có vẻ như bạn có thể hết IOPS bằng cách sử dụng bộ nhớ tiêu chuẩn. Mua dung lượng nhanh hơn không phải là đắt. Có một cái nhìn về điều này .

— MrMajestyk
nguồn

-3

Đĩa có thể ở chế độ không DMA. Vui lòng kiểm tra trạng thái DMA của ổ đĩa. (lệnh hdparm)

Nếu không phải như vậy, một cái gì đó khác có thể tạo ra rất nhiều gián đoạn. Bất cứ ai cũng nhớ những người từ thời DOS cũ tốt?

— Overmind
nguồn

EC2 là một nền tảng ảo hóa và sử dụng các đĩa ảo. DMA không phải là thủ phạm ở đây. Dù sao, một cơn bão IRQ gây ra một số điện thoại cho CPU, không phải đĩa.

— shodanshok 4/03/2015

Có và IRQ có nghĩa là gián đoạn.

— Khắc phục

EC2 đã được loại bỏ khỏi loại vấn đề đó càng nhiều càng tốt. I / O được giới hạn bởi loại thể hiện - và cuối cùng bởi một số giải pháp SAN thực sự đắt tiền có nhiều dung lượng.

— MrMajestyk