wa (Chờ I / O) từ lệnh cao nhất là lớn

Tôi có một diễn đàn với rất nhiều khách truy cập, Một số ngày, tải tăng lên đến 40 mà không tăng số lượng khách hàng. Như bạn có thể thấy từ đầu ra bên dưới, thời gian chờ là cao (57%). Làm thế nào để tôi tìm thấy lý do cho điều đó?
Phần mềm máy chủ là Apache, MySQL và 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

Dưới đây là một vài công cụ để tìm hoạt động của đĩa:

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

Trong ps auxfbạn cũng sẽ thấy các quá trình đang trong trạng thái ngủ không thể giải thích được ( D) vì chúng đang chờ I / O.

Một số ngày, tải tăng lên đến 40 mà không tăng số lượng vistors.

Bạn cũng có thể muốn tạo một bản sao lưu và xem liệu ổ cứng đang dần bị lỗi. Một ổ cứng thường bắt đầu chậm lại trước khi nó chết. Điều này cũng có thể giải thích tải cao.

Đầu ra từ đầu cho thấy rằng DBMS đang trải qua hầu hết các chờ đợi I / O, vì vậy các vấn đề điều chỉnh cơ sở dữ liệu là một ứng cử viên rõ ràng để điều tra.

I / O chờ trên máy chủ cơ sở dữ liệu - đặc biệt là trên các tải trọng đột biến - là một đầu mối cho thấy DBMS của bạn có thể bị ràng buộc bởi đĩa (tức là bạn cần một hệ thống con đĩa nhanh hơn) hoặc nó có thể có vấn đề điều chỉnh. Có lẽ bạn cũng nên xem xét hồ sơ máy chủ cơ sở dữ liệu của mình - tức là theo dõi những gì nó đang làm và những truy vấn nào đang làm mất thời gian.

Một số điểm khởi đầu để chẩn đoán các vấn đề điều chỉnh cơ sở dữ liệu: -

• Tìm các truy vấn chiếm nhiều thời gian nhất và xem xét các kế hoạch truy vấn. Xem nếu có bất kỳ kế hoạch truy vấn kỳ lạ như quét bảng ở nơi không nên. Có lẽ cơ sở dữ liệu cần một chỉ mục được thêm vào.

• Thời gian chờ đợi tài nguyên dài có thể có nghĩa là một số nhóm tài nguyên chính cần được mở rộng.

• Thời gian chờ I / O dài có thể có nghĩa là bạn cần một hệ thống con đĩa nhanh hơn.

• Là nhật ký và khối lượng dữ liệu của bạn trên các ổ đĩa riêng biệt? Nhật ký cơ sở dữ liệu có rất nhiều ghi tuần tự nhỏ (về cơ bản chúng hoạt động giống như bộ đệm vòng). Nếu bạn có một khối lượng công việc truy cập ngẫu nhiên bận rộn chia sẻ cùng các đĩa như nhật ký của bạn, điều này sẽ ảnh hưởng không tương xứng đến thông lượng của việc ghi nhật ký. Đối với một giao dịch cơ sở dữ liệu để cam kết các mục nhật ký phải được ghi ra đĩa, vì vậy điều này sẽ đặt một nút cổ chai trên toàn hệ thống.
  
  Lưu ý rằng một số công cụ lưu trữ MySQL không sử dụng nhật ký nên điều này có thể không phải là vấn đề trong trường hợp của bạn.

Chú thích: Hệ thống xếp hàng

Các hệ thống xếp hàng (một mô hình thống kê cho thông lượng) trở nên chậm hơn khi hệ thống đạt đến độ bão hòa. Đối với xấp xỉ mức cao, một hệ thống bão hòa 50% có chiều dài hàng đợi trung bình là 2. Một hệ thống bão hòa 90% có chiều dài hàng đợi là 10, hệ thống bão hòa 99% có chiều dài hàng đợi là 100.

Do đó, trên một hệ thống gần với độ bão hòa, những thay đổi nhỏ về tải có thể dẫn đến những thay đổi lớn đối với thời gian chờ, trong trường hợp này biểu hiện là thời gian chờ đợi trên I / O. Nếu dung lượng I / O của hệ thống con đĩa của bạn gần bão hòa thì những thay đổi nhỏ trong tải có thể dẫn đến những thay đổi đáng kể về thời gian đáp ứng.

Chạy iotop, hoặc atop -dD, để xem những gì quá trình đang làm io. Sử dụng stracenếu bạn cần xem xét kỹ hơn.

Trong cả hai màn hình, có vẻ như "mysqld" phải chịu trách nhiệm.

Bạn cần xem daemon đó đang làm gì ... những truy vấn nào đang chạy.

Một số ngày, tải tăng lên đến 40 mà không tăng số lượng vistors.

Những gì người dùng đang làm có thể quan trọng như con số thực sự ở đó. Các hoạt động như tìm kiếm diễn đàn sẽ đòi hỏi nhiều hơn là chỉ tải và xem từng chủ đề hoặc danh sách các chủ đề.

Ngoài ra: bạn đang chạy trên một máy chủ chuyên dụng hay VPS? Nếu dịch vụ của bạn không có trên một máy chủ chuyên dụng thì hành động của các ứng dụng chạy trên cùng một máy chủ sẽ có tác dụng vì các VM mà máy ảo của bạn chia sẻ với máy chủ sẽ cạnh tranh để chia sẻ tài nguyên I / O.

Như những người khác đã chỉ ra, các công cụ như iotopsẽ giúp bạn nhìn sâu hơn vào những nhiệm vụ đang chờ phản hồi I / O và những tập tin họ đang truy cập tại thời điểm đó.

Như Flip nói, có vẻ như vấn đề xoay quanh những gì mysql đang làm.

Khoảng một nửa bộ nhớ vật lý của bạn hiện đang được sử dụng cho bộ nhớ đệm I / O - phần mềm diễn đàn thường tạo ra rất nhiều truy vấn nhanh trả về số lượng nhỏ hàng, với các vùng nóng bị lệch rất nhiều - vì vậy sẽ có một cái gì đó rất khó xảy ra nếu hệ thống đang chi tiêu nhiều thời gian chờ đợi

Tôi chỉ thấy việc sử dụng CPU / đĩa như thế khi chạy các truy vấn cập nhật hàng triệu hàng.

Trung bình tải cao là hệ quả trực tiếp của I / O.

Tăng tốc ghi nhật ký mysql của bạn để xem liệu có mã xấu trong đó / thay đổi chỉ mục sẽ giúp ích. Phân tích các bảng của bạn có thể giúp (nhưng có lẽ không nhiều).

C.