wa (Menunggu I / O) dari komando besar

Saya memiliki forum dengan banyak pengunjung, Beberapa hari bebannya meningkat mencapai 40 tanpa peningkatan jumlah pengunjung. Seperti yang Anda lihat dari output di bawah ini, waktu tunggu tinggi (57%). bagaimana saya menemukan alasan untuk itu?
Perangkat lunak server adalah Apache, MySQL dan 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

Berikut adalah beberapa alat untuk menemukan aktivitas disk:

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

Dalam ps auxfAnda juga akan melihat proses mana yang ada dalam disk sleep ( D) karena mereka menunggu I / O.

Beberapa hari beban bertambah hingga mencapai 40 tanpa menambah jumlah pengunjung.

Anda mungkin juga ingin membuat cadangan, dan melihat apakah harddisk lambat gagal. Hard disk umumnya mulai melambat sebelum mati. Ini juga bisa menjelaskan beban tinggi.

Output dari atas menunjukkan bahwa DBMS sedang mengalami sebagian besar menunggu I / O, sehingga masalah pencarian basis data adalah kandidat yang jelas untuk diselidiki.

I / O yang menunggu di server database - terutama pada lonjakan beban - adalah petunjuk bahwa DBMS Anda mungkin terikat dengan disk (misalnya Anda memerlukan subsistem disk yang lebih cepat) atau mungkin memiliki masalah penyetelan. Anda mungkin juga harus melihat ke profil server database Anda - yaitu mendapatkan jejak apa yang dilakukannya dan pertanyaan apa yang meluangkan waktu.

Beberapa poin awal untuk mendiagnosis masalah penyetelan basis data: -

• Temukan kueri yang paling memakan waktu, dan lihat paket kueri. Lihat apakah ada yang memiliki rencana kueri aneh seperti pemindaian tabel di tempat yang seharusnya. Mungkin database perlu ditambahkan indeks.

• Waktu tunggu sumber daya yang panjang dapat berarti bahwa beberapa kumpulan sumber daya utama perlu diperluas.

• Waktu tunggu I / O yang lama dapat berarti bahwa Anda memerlukan subsistem disk yang lebih cepat.

• Apakah volume log dan data Anda pada drive terpisah? Log basis data memiliki banyak penulisan sekuensial kecil (pada dasarnya mereka berperilaku seperti buffer cincin). Jika Anda memiliki beban kerja akses acak yang sibuk dengan berbagi disk yang sama dengan log Anda, ini akan secara tidak proporsional memengaruhi throughput logging. Untuk transaksi basis data untuk melakukan entri log harus ditulis ke disk, jadi ini akan menempatkan hambatan pada keseluruhan sistem.
  
  Perhatikan bahwa beberapa mesin penyimpanan MySQL tidak menggunakan log sehingga ini mungkin tidak menjadi masalah dalam kasus Anda.

Catatan Kaki: Sistem antrian

Sistem antrian (model statistik untuk throughput) menjadi lebih lambat secara hiperbola ketika sistem mendekati kejenuhan. Untuk perkiraan tingkat tinggi, sistem yang jenuh 50% memiliki panjang antrian rata-rata 2. Sistem yang jenuh 90% memiliki panjang antrian 10, sistem yang jenuh 99% memiliki panjang antrian 100.

Jadi, pada sistem yang mendekati saturasi, perubahan kecil pada beban dapat menghasilkan perubahan besar untuk menunggu waktu, dalam hal ini bermanifestasi sebagai waktu yang dihabiskan menunggu pada I / O. Jika kapasitas I / O subsistem disk Anda hampir jenuh maka perubahan kecil pada beban dapat menghasilkan perubahan signifikan dalam waktu respons.

Jalankan iotop, atau atop -dD, untuk melihat proses apa yang sedang dilakukan io. Gunakan stracejika Anda perlu melihat lebih dekat.

Di kedua layar pasti terlihat seperti "mysqld" yang bertanggung jawab.

Anda perlu melihat apa yang dilakukan daemon ... pertanyaan apa yang sedang dijalankan.

Beberapa hari beban bertambah hingga mencapai 40 tanpa menambah jumlah pengunjung.

Apa yang dilakukan pengguna bisa sama pentingnya dengan jumlah yang sebenarnya ada. Operasi seperti mencari di forum akan lebih banyak menuntut daripada sekadar memuat dan melihat setiap utas atau daftar utas.

Juga: apakah Anda menjalankan server khusus atau VPS? Jika layanan Anda tidak berada di server khusus maka tindakan aplikasi yang berjalan di host yang sama akan memiliki efek karena VM yang dibagikan dengan host Anda oleh VM akan bersaing untuk mendapatkan bagian dari sumber daya I / O.

Seperti yang telah ditunjukkan orang lain, alat-alat seperti iotopakan membantu Anda untuk melihat lebih dalam pada tugas-tugas apa saja yang menunggu tanggapan I / O dan file apa yang mereka akses pada saat itu.

Seperti yang dikatakan Flip, sepertinya masalahnya ada di sekitar apa yang dilakukan mysql.

Sekitar setengah dari memori fisik Anda saat ini sedang digunakan untuk cache I / O - perangkat lunak forum biasanya menghasilkan banyak permintaan cepat mengembalikan sejumlah kecil baris, dengan area disk yang sangat miring - sehingga ada sesuatu yang pasti terjadi jika sistem menghabiskan banyak waktu menunggu ini.

Saya hanya pernah melihat penggunaan CPU / disk seperti itu ketika menjalankan kueri yang memperbarui jutaan baris.

Rata-rata beban tinggi adalah konsekuensi langsung dari I / O.

Crank mysql logging Anda untuk melihat apakah ada kode buruk di sana / mengubah indeks akan membantu. Menganalisis tabel Anda mungkin membantu (tapi mungkin tidak banyak).

C.