โหลดสูงเนื่องจาก I / O รอใน Ubuntu 12.04 บนอินสแตนซ์ของ EC2


9

ฉันใช้เซิร์ฟเวอร์ Ubuntu 12.04 มีปัญหาในการค้นหาสาเหตุของการโหลดฉันได้เห็นการเปลี่ยนแปลงเวลาตอบสนองของเซิร์ฟเวอร์จากสัปดาห์ที่ผ่านมา

หลังจากอ่านการแก้ไขปัญหา Linux ตอนที่ 1: โหลดสูง

ดูเหมือนว่าจะไม่มีปัญหากับ CPU และ RAM และการโหลดนี้อาจเกี่ยวข้องกับการโหลดI / O-bound โดยใช้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, Disk เขียนฉันสังเกตการณ์เป็น1266 KB/s

ป้อนคำอธิบายรูปภาพที่นี่

และ

ป้อนคำอธิบายรูปภาพที่นี่

ไม่ดีเหรอ? เมื่อเวลาตอบสนองลดลง อะไรทำให้เกิดสิ่งนี้

การแก้ไขที่ผู้อื่นถาม

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

@shodanshok จุดที่ 2

ป้อนคำอธิบายรูปภาพที่นี่

ไอโซโทป

ป้อนคำอธิบายรูปภาพที่นี่


1
99% IOwait เมื่ออ่านและเขียนดิสก์ 0 แผ่นไม่ได้ผล ที่นี่serverfault.com/questions/426181/มีการกล่าวถึงว่า I / O อาจเกี่ยวข้องกับกิจกรรมของดิสก์ไม่เพียง แต่ต้องยุ่งกับเครือข่าย คุณช่วยตรวจสอบด้วย iftop (และเครื่องมืออื่น ๆ ด้วย) ได้ไหม?
Andrey Sapegin

@AndreySapegin เพิ่ม iftop
Straw Hat

ฉันคิดว่าปัญหาเกิดขึ้นกับดิสก์ที่ติดตั้ง AWS Instance .. ฉันสร้าง AMI ของอินสแตนซ์ปัจจุบันและเปิดใช้งานอินสแตนซ์ใหม่โดยใช้ .. ตอนนี้ไม่มีการโหลดเพิ่มเติมใน I / O
หมวกฟาง

@StrawHat หมายความว่าคุณคิดว่ามีบางอย่างผิดปกติกับแผ่นดิสก์ในอินสแตนซ์แรกของคุณหรือไม่
sbrattla

@sbrattla ไม่ฉันคิดว่า หลังจากไม่กี่วันปัญหาเดียวกันก็โผล่ออกมา
หมวกฟาง

คำตอบ:


2

ปรับแต่งบริการ mysql ของคุณเพื่อหลีกเลี่ยงการสัมผัสกับดิสก์และระวังในคิว postfix ของคุณคุณอาจมีอีเมลจำนวนมากในคิว I / O ที่มีความละเอียดอ่อน

ระบบอีเมลของคุณถูกใช้เป็นรีเลย์สำหรับผู้ส่งอีเมลขยะ

ดูเอกสาร postfixและ จำกัด การเข้าถึง MTA ของคุณ


ย้าย mysql ไปที่อินสแตนซ์ RDS จะทำงานอย่างไร
หมวกฟาง

1
เรียงลำดับของปัญหาหลักคือเนื่องจากจำนวน itens สูงในคิว postfix กินไอพของคุณคุณสามารถดูด้วย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 ของคุณสามารถ misconfigured /var/lib/postfix/deferredแต่สำหรับปัญหาปัจจุบันของคุณให้ดูจำนวนอีเมลที่คุณมีใน ย้ายไปที่holdคิวเพื่อตรวจสอบหรือล้างข้อมูลเพิ่มเติม
fgbreel

1

แก้ไขหลังจากข้อมูลเพิ่มเติมที่รวบรวมโดยใช้ iostat และ iotop
ดิสก์ของคุณโหลดเต็ม 100% ขณะที่ไม่มี IOPS ที่มีอยู่: ตาม iostat คุณมีค่าคงที่ 50+ IOPS (85 w / s - 35 ที่รวมกันด้วย w / s) อินสแตนซ์ของ EC2 โดยเฉพาะอย่างยิ่งราคาถูกมีขีด จำกัด ที่แข็งแกร่งสำหรับ IOPS ที่ยั่งยืน (ในช่วง 30-50 IOPS)

ตามผลลัพธ์ของไอโซโทปใหม่ทั้ง mysql และ bounce นั้นกำลังกิน IOPS เป็นจำนวนมาก อย่างไรก็ตามผลลัพธ์ของไอโซโทปดูเหมือนจะไม่สมบูรณ์หรือเรียงลำดับไม่ดีอย่างน้อยที่สุด คุณสามารถเรียกใช้การเรียงลำดับ "iotop -a" อีกครั้งหนึ่งได้โดย IOPS และอีกครั้งด้วยการเขียนดิสก์

คำตอบเดิม
เดิมพันของฉัน: กระบวนการ "ตีกลับ" กำลังออกซิงโครไนซ์หลายเขียนที่ทำให้อุปกรณ์ดิสก์เสมือนที่นำเสนอโดย Amazon (อย่างไรก็ตามคุณใช้โปรไฟล์ใดบ้างดิสก์ EC2 มีกฎที่เข้มงวดมากสำหรับการระเบิด I / O อย่างต่อเนื่อง)

อย่างไรก็ตามระบุว่าแบนด์วิดธ์ของ I / O ที่กำลังเผาไหม้อาจเป็นเรื่องยากในบางครั้ง ในขณะที่ไอโซโทปเป็นเครื่องมือที่ดีมากบางครั้งมันก็ไม่ได้ให้ข้อมูลที่จำเป็นแก่คุณ เราต้องไปให้ลึกกว่านี้ ดังนั้นทำตามคำแนะนำเหล่านี้:

  1. อันดับแรกเราต้องระบุประเภทของ I / O ที่กำลังประมวลผลและอุปกรณ์บล็อกที่ได้รับผลกระทบ
    กรุณาเรียกใช้คำสั่งต่อไปนี้: iostat -x -k 5 2. โปรดรายงานชุดผลลัพธ์ทั้งสองชุด
  2. จากนั้นเราจะต้องระบุกระบวนการรอ I / O
    เมื่อสามารถใช้ "top" สำหรับสิ่งนั้น: เรียกใช้งานกด Shift + f (F) จากนั้น w จากนั้นป้อนจากนั้น shift + r (R) กระบวนการแรกจะเป็นกระบวนการหนึ่งใน D หรือ D + (เช่น: รอดิสก์ / เครือข่าย) กรุณารายงานกลับรายการ
  3. ใช้ iotop เพื่อแสดงสะสม I / O ค่าสำหรับกระบวนการ
    ใช้iotop -aเวลาประมาณหนึ่งนาทีแล้ววางผลลัพธ์ที่นี่

iostat -x -k 5 2และยังเพิ่มคำถาม
Straw Hat

1

ช้าไปหน่อย แต่ฉันมีปัญหาเดียวกันในเครื่องที่คล้ายกันและพบว่าปัญหานั้นเป็นปัญหาของตาราง MySQL ที่เสียหาย เนื่องจากตารางเหล่านี้บางส่วนมีข้อมูลจำนวนมากจึงสร้างเวลารอ I / O จำนวนมาก

ดู/var/log/mysql/error.logหรือใช้mysqlcheckเพื่อค้นหาและซ่อมแซมข้อมูลที่เสียหาย


0

ตามที่ระบุไว้ข้างต้นเป็นไปได้ค่อนข้างมากที่อินสแตนซ์ EC2 ของคุณจะมาพร้อมกับขีด จำกัด IO หรืออาจจะสำรองไว้ในไดรฟ์ข้อมูล Amazon EBS Standard ซึ่งไม่ส่ง IO ที่ฉลาดมาก ดูที่หน้านี้ - อธิบายประเภทต่างๆของข้อเสนอที่ Amazon เสนอ

แม้ว่าคุณจะมีโวลุ่มค่อนข้างช้าคุณก็ควรจะสามารถเขียนได้อย่างรวดเร็วพอสมควร แต่หากการโหลดของคุณเป็นแบบสุ่มตามธรรมชาติดูเหมือนว่ามันอาจจะเป็น (สิ่ง 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.