Tôi có CPU I / O chờ ổn định khoảng 50%, nhưng khi tôi chạy iostat 1 nó hiển thị rất ít hoạt động của đĩa.

Điều gì gây ra sự chờ đợi mà không có iops?

LƯU Ý: Không có hệ thống tập tin NFS hoặc FUSE ở đây, nhưng nó đang sử dụng ảo hóa Xen.

NFS có thể làm điều này và nó sẽ không làm tôi ngạc nhiên nếu các hệ thống tệp mạng khác (và thậm chí cả các thiết bị dựa trên FUSE) có hiệu ứng tương tự.

Có bất kỳ máy ảo nào khác trên máy chủ đang đập đĩa không?

Tôi biết với ảo hóa rằng bạn có thể nhận được một số kết quả lạ nếu nút máy chủ bị quá tải.

Nếu đây là môi trường Amazon EC2 Xen sử dụng lưu trữ dựa trên cá thể, hãy yêu cầu Amazon kiểm tra sức khỏe của máy chủ chứa hình ảnh này.

Nếu đây là môi trường Xen mà bạn có thể có quyền truy cập vào trình ảo hóa, thì hãy kiểm tra IOwait mà không cần hình ảnh đĩa (tệp, mạng, LVM-lát, bất cứ thứ gì) đang được sử dụng cho các thiết bị xvda và xvdb. Nói chung, bạn cũng muốn kiểm tra hệ thống I / O cho bộ ảo hóa vì các thiết bị đĩa khác có thể độc quyền tài nguyên của hệ thống.

iostat -txk 5

thường là một công cụ chẩn đoán bắt đầu tốt. Phải mất 5 giây tóm tắt I / O cho TẤT CẢ các thiết bị có sẵn cho nó, và do đó rất hữu ích cả trong và ngoài héo hình ảnh VM.

Kiểm tra mô tả tập tin / inodes có sẵn của bạn. Khi bạn đạt đến giới hạn, họ trao đổi và bắt chước iowait

Biên tập

Tôi thấy bạn đang sử dụng xen, hãy xem các ngắt hiện tại của bạn, bạn có thể thấy blkif cao hơn bình thường.

Bit muộn, nhưng được cài đặt munin và nó thực sự sẽ giúp gỡ lỗi trong tương lai.

sudo sysctl vm.block_dump=1

Sau đó kiểm tra dmesg để xem những gì đang thực hiện đọc / ghi khối hoặc làm bẩn các nút.

Ngoài ra, hãy kiểm tra giới hạn nofile trong giới hạn. Thông tin, một quy trình có thể yêu cầu nhiều tệp hơn mức được phép mở.

CẢNH BÁO: HDPARM LÀ NGUY HIỂM, LUÔN LUÔN ĐỌC VỀ QUY TẮC BẠN ĐANG SỬ DỤNG!

Nếu không có máy ảo nào khác nhấn mạnh vào đĩa cứng, hãy làm

hdparm -f

trên đĩa vật lý cơ bản. Có thể bộ đệm đĩa không hoạt động chính xác. Điều này sẽ xóa dữ liệu được lưu trữ trong bộ đệm và bạn có thể liên tục theo dõi I / O, cho dù nó sắp tăng trở lại sau khi xóa. Nếu có, nó sẽ là một vấn đề bộ nhớ cache.

Với tải trung bình, tôi đã thấy các hoạt động mạng bị chặn (tức là các cuộc gọi dài đến máy chủ DB bên ngoài) tăng lên. Tôi không biết chắc chắn nhưng tôi đoán IO mạng có thể khiến CPU chờ tăng? Bất cứ ai có thể xác nhận?

Có thể là các thiết bị loopback, được gắn trên mạng.

Trên máy của tôi, NFS là "nhà sản xuất" IO-WAIT lớn nhất. Tôi có một ổ SSD trong máy tính xách tay của mình, nó nhanh như địa ngục, vì vậy "IO thực sự" không phải là vấn đề. Tuy nhiên, đôi khi tôi có rất nhiều IO chờ đợi do các cổ phiếu nfs được gắn kết của tôi.

SCP đôi khi dường như cũng dẫn đến IO Wait nhưng đến mức mở rộng ít hơn nhiều.

Đây có thể là bất cứ điều gì. Nó chỉ có nghĩa là một cái gì đó đang chờ kết thúc hoạt động I / O. Bạn có thể tìm ra quy trình của nó thông qua ps, sau đó gắn gdb vào nó và kiểm tra backtrace để xác định cuộc gọi nào bị treo (thường đây là một số nội dung liên quan đến mạng hoặc đĩa đột ngột bị ngắt kết nối). Để biết thông tin fd, hãy kiểm tra / Proc.

Tôi cũng đã gặp một vấn đề tương tự ngay trước khi một đĩa trong RAID bị lỗi và một số cáp SATA bị uốn cong bắt đầu bị lỗi.

Việc sử dụng CPU là gần 0%, nhưng 1 hoặc nhiều CPU trên hệ thống 4 lõi đã dành 100% thời gian của họ trong IOwait trong thời gian dài (được tìm thấy qua topmàn hình cpu nhiều dòng) với IOps và băng thông rất thấp (được tìm thấy thông qua iostat), nhưng hoạt động ngắt cao. Việc sử dụng dòng lệnh tương tác gây khó khăn trong bất kỳ truy cập đĩa nào (nghĩa là tự động lưu từ emacsphiên của ai đó ) nhưng có thể chấp nhận được một khi thời gian IOwait trôi qua (và có lẽ các hoạt động đã thành công sau nhiều lần thử lại).