wa (กำลังรอ I / O) จากคำสั่งด้านบนมีขนาดใหญ่

ฉันมีฟอรัมที่มีผู้เข้าชมจำนวนมากบางวันโหลดเพิ่มขึ้นถึง 40 โดยไม่ต้องเพิ่มจำนวนตัวต้านทาน ดังที่คุณเห็นจากด้านล่างผลลัพธ์เวลารอสูง (57%) ฉันจะหาสาเหตุได้อย่างไร
ซอฟต์แวร์เซิร์ฟเวอร์คือ Apache, MySQL และ PHP

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

.

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

ต่อไปนี้เป็นเครื่องมือเล็กน้อยในการค้นหากิจกรรมของดิสก์:

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

ในps auxfนอกจากนี้คุณยังจะเห็นว่ากระบวนการใดที่อยู่ในโหมดสลีปดิสก์ที่ไม่สามารถตีความได้ ( D) เนื่องจากกำลังรอ I / O

บางวันภาระเพิ่มขึ้นถึง 40 โดยไม่เพิ่มจำนวนตัวต้านทาน

คุณอาจต้องการสร้างการสำรองข้อมูลและดูว่าฮาร์ดไดรฟ์ช้าหรือไม่ ฮาร์ดไดรฟ์เริ่มช้าลงก่อนที่มันจะตาย สิ่งนี้สามารถอธิบายการรับน้ำหนักได้สูง

ผลลัพธ์จากด้านบนแสดงให้เห็นว่า DBMS กำลังประสบกับ I / O ส่วนใหญ่รอดังนั้นปัญหาการปรับแต่งฐานข้อมูลจึงเป็นตัวเลือกที่ชัดเจนในการตรวจสอบ

I / O ที่รออยู่บนเซิร์ฟเวอร์ฐานข้อมูลโดยเฉพาะอย่างยิ่งใน load spikes เป็นคำใบ้ที่ว่า DBMS ของคุณอาจเป็นดิสก์ที่ถูกผูกไว้ (เช่นคุณต้องการระบบย่อยดิสก์ที่เร็วกว่า) หรืออาจมีปัญหาในการปรับแต่ง คุณควรดูที่การทำโปรไฟล์เซิร์ฟเวอร์ฐานข้อมูลของคุณเช่นรับการติดตามสิ่งที่กำลังทำและการสืบค้นที่ใช้เวลา

จุดเริ่มต้นบางจุดสำหรับการวินิจฉัยปัญหาการปรับแต่งฐานข้อมูล: -

• ค้นหาคิวรีที่ใช้เวลามากที่สุดและดูที่แผนคิวรี ดูว่ามีแผนแบบสอบถามแปลก ๆ เช่นการสแกนตารางที่ไม่ควร บางทีฐานข้อมูลต้องการดัชนีเพิ่ม

• เวลารอของทรัพยากรที่ยาวนานอาจหมายถึงว่าต้องมีพูลทรัพยากรที่สำคัญบางตัว

• เวลารอ I / O ที่ยาวนานอาจหมายความว่าคุณต้องการระบบย่อยดิสก์ที่เร็วกว่า

• บันทึกและปริมาณข้อมูลของคุณในไดรฟ์แยกกันหรือไม่ บันทึกฐานข้อมูลมีการเขียนเรียงลำดับขนาดเล็กจำนวนมาก หากคุณมีภาระงานเข้าถึงแบบสุ่มไม่ว่างที่แชร์ดิสก์เดียวกันกับบันทึกของคุณการทำเช่นนี้จะส่งผลกระทบต่อปริมาณงานของการบันทึกอย่างไม่เป็นสัดส่วน สำหรับธุรกรรมฐานข้อมูลเพื่อส่งรายการบันทึกต้องถูกเขียนลงดิสก์ดังนั้นสิ่งนี้จะวางคอขวดบนทั้งระบบ
  
  โปรดทราบว่าเครื่องมือเก็บข้อมูล MySQL บางตัวไม่ใช้บันทึกดังนั้นนี่อาจไม่เป็นปัญหาในกรณีของคุณ

เชิงอรรถ: ระบบการเข้าคิว

ระบบเข้าคิว (แบบจำลองทางสถิติสำหรับปริมาณงาน) ลดลงช้าลงอย่างมากเนื่องจากระบบเข้าใกล้ความอิ่มตัว สำหรับการประมาณในระดับสูงระบบที่อิ่มตัว 50% จะมีความยาวคิวเฉลี่ย 2 ระบบที่อิ่มตัว 90% มีความยาวคิว 10 ระบบที่ 99% อิ่มตัวมีความยาวคิว 100

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

เรียกใช้iotopหรือatop -dDเพื่อดูว่ากระบวนการใดกำลังทำ io ใช้straceหากคุณต้องการรูปลักษณ์ที่ใกล้กว่า

ในหน้าจอทั้งสองดูเหมือนว่า "mysqld" เป็นผู้รับผิดชอบ

คุณต้องดูว่า daemon นั้นกำลังทำอะไร ...

บางวันภาระเพิ่มขึ้นถึง 40 โดยไม่เพิ่มจำนวนตัวต้านทาน

สิ่งที่ผู้ใช้กำลังทำอาจมีความสำคัญเท่ากับจำนวนที่มีอยู่จริง การดำเนินการเช่นการค้นหาฟอรัมจะมีความต้องการมากกว่าการโหลดและดูแต่ละกระทู้หรือรายการของเธรด

นอกจากนี้: คุณกำลังทำงานบนเซิร์ฟเวอร์เฉพาะหรือ VPS หรือไม่? หากบริการของคุณไม่ได้อยู่บนเซิร์ฟเวอร์เฉพาะการกระทำของแอพที่ทำงานบนโฮสต์เดียวกันจะมีผลเมื่อ VMs ที่ VM ของคุณแชร์กับโฮสต์จะแข่งขันกันเพื่อแบ่งปันทรัพยากร I / O

เครื่องมืออื่น ๆiotopจะช่วยให้คุณมองลึกลงไปในสิ่งที่งานกำลังรอคอยการตอบกลับ I / O และไฟล์ที่พวกเขากำลังเข้าถึงในเวลานั้น

ดังที่ Flip บอกว่าดูเหมือนว่าปัญหาจะเกิดขึ้นกับสิ่งที่ mysql กำลังทำอยู่

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

ฉันเคยเห็นการใช้งาน CPU / ดิสก์เช่นนั้นเมื่อเรียกใช้คิวรีที่อัปเดตหลายล้านแถว

ค่าภาระเฉลี่ยสูงเป็นผลโดยตรงจาก I / O

เร่งการบันทึก mysql ของคุณเพื่อดูว่ามีรหัสที่ไม่ดีอยู่ในนั้นหรือการเปลี่ยนดัชนีจะช่วยได้หรือไม่ การวิเคราะห์ตารางของคุณอาจช่วยได้ (แต่อาจจะไม่มาก)

ซี