Gỡ lỗi độ trễ I / O của Linux

Tôi đang gặp một số vấn đề I / O trên một vài hệ thống Linux mà tôi quản lý. Chúng biểu hiện trong đó các quy trình thường chặn tối đa vài giây trong các tòa nhà đơn giản như open (), unlink () hoặc close () trên các tệp (đó là một vấn đề vì một số chương trình liên quan cần độ trễ I / O khá thấp để hoạt động đúng cách). Đúng là các hệ thống được đề cập để trải nghiệm một số tải I / O vừa phải, nhưng tôi khó có thể nghĩ rằng nó sẽ đủ để biện minh cho thời gian trễ lớn như vậy. Đôi khi, các cuộc gọi có thể mất hơn 15 giây để hoàn thành (mặc dù thường thì chúng có thể mất 1 hoặc 2 hoặc 3 giây hoặc lâu hơn).

Câu hỏi của tôi là: Làm thế nào tôi có thể tìm hiểu tại sao điều này xảy ra? Những gì tôi muốn là một số công cụ có thể cho tôi biết các quy trình trong câu hỏi bị chặn bởi kernel và lý do tại sao chúng ngủ trên đó là bận rộn, những gì đang xảy ra với nó và những thứ như vậy. Có một công cụ như vậy, hoặc có một số cách khác để cố gắng gỡ lỗi những gì xảy ra?

Ngoài ra, tất nhiên, nếu bạn có bất kỳ manh mối nào về những gì thực sự đang xảy ra, làm thế nào để tránh nó?

Đối với bản ghi, hệ thống tập tin tôi sử dụng là XFS.

Bây giờ trong thời gian thích hợp, tôi đã tự mình giải quyết vấn đề này, vì vậy tôi ít nhất có thể tự mình theo dõi nó cho hậu thế.

Thật không may, tôi đã mất vấn đề ban đầu trong quá trình nâng cấp kernel, nhưng thay vào đó lại gặp vấn đề mới, thậm chí còn tệ hơn về hiệu năng và khó theo dõi. Các kỹ thuật tôi tìm thấy như sau:

Đầu tiên, blktrace / blkparselà một công cụ mà tôi thấy khá hữu ích. Nó cho phép theo dõi tiến trình của các yêu cầu I / O riêng lẻ với nhiều chi tiết hữu ích, chẳng hạn như quá trình gửi yêu cầu. Sẽ rất hữu ích khi đặt đầu ra tmpfs, để việc xử lý lưu trữ dấu vết không bắt đầu tự theo dõi.

Tuy nhiên, điều đó chỉ giúp được cho đến nay, vì vậy tôi đã biên dịch một kernel có nhiều chức năng sửa lỗi hơn. Đặc biệt, tôi thấy ftracekhá hữu ích, vì nó cho phép tôi theo dõi quá trình hoạt động kém bên trong không gian kernel, để xem những gì nó đã làm và nơi nó bị chặn. Việc biên dịch kernel gỡ lỗi cũng cung cấp WCHANđầu ra làm việc ps, nó có thể hoạt động như một cách dễ dàng hơn để xem quá trình đang làm gì bên trong kernel, ít nhất là đối với các trường hợp đơn giản hơn.

Tôi cũng hy vọng LatencyTop sẽ hữu ích, nhưng tôi thấy nó khá có lỗi, và cũng chỉ hiển thị lý do độ trễ quá "cao cấp" là thực sự hữu ích, thật không may.

Ngoài ra, tôi thấy nó hữu ích hơn iostatlà chỉ xem nội dung trong /sys/block/$DEVICE/statkhoảng thời gian rất gần, chỉ đơn giản như thế này:

while :; do cat /sys/block/sda/stat; sleep .1; done

Xem Documentation/iostats.txt trong cây nguồn kernel để biết định dạng củastat tệp. Xem nó trong khoảng thời gian gần cho phép tôi thấy thời gian và kích thước chính xác của cụm I / O và những thứ như vậy.

Cuối cùng, tôi phát hiện ra rằng sự cố tôi gặp phải sau khi nâng cấp kernel là do các trang ổn định , một tính năng được giới thiệu trong Linux 3.0, trong trường hợp của tôi, Berkeley DB tạm dừng trong thời gian dài khi làm bẩn các trang trong mmap'ed tập tin khu vực. Mặc dù dường như có thể vá tính năng này và cũng có thể các sự cố mà nó gây ra có thể được khắc phục trong Linux 3.9, tôi đã giải quyết vấn đề tồi tệ nhất hiện tại bằng cách vá Berkeley DB để cho phép tôi đặt các tệp vùng của nó vào một thư mục khác (trong trường hợp của tôi /dev/shm), cho phép tôi tránh vấn đề hoàn toàn.

Theo kinh nghiệm của tôi, công cụ thống kê đơn giản và chi tiết nhất bạn có thể cài đặt để theo dõi các vấn đề hiệu năng hệ thống bí ẩn là http://freecode.com/projects/sysstat aka. sar

để chắc chắn bạn cũng muốn xem đầu ra lệnh i điều chỉnh, đặc biệt là% iowait của bạn nên ở mức dưới 5-10% trong tải hệ thống bình thường (dưới 1.0 hoặc hơn).

nhìn vào đầu ra ps nếu trong cột STAT bạn thấy các trạng thái D có nghĩa là các quá trình đó bị khóa và chờ IO, rất có thể là sự cố phần cứng với bộ điều khiển hoặc đĩa, kiểm tra số liệu thống kê SMART cũng như dmesg và syslog để tìm manh mối

kiểm tra nhật ký sar và xác định thời gian cao điểm nếu điều này xảy ra và cố gắng khớp thời gian đó với các công việc cron chuyên sâu trên đĩa, ví dụ như sao lưu qua mạng

bạn có thể đánh giá hiệu suất đĩa của mình với bonnie ++

Tôi nghĩ rằng tôi đã đề cập đến bước đi mặc dù câu hỏi này đã được vài tháng tuổi. Nó có thể giúp một người có vấn đề tương tự tìm thấy trang này.

thử.

strace "application"

bạn cũng có thể làm

strace -e read,write "application"

để chỉ hiển thị các sự kiện đọc / ghi.

Ứng dụng sẽ tải như bình thường (mặc dù khởi động chậm hơn một chút) và bạn có thể sử dụng nó như bình thường để kích hoạt sự cố. Đầu ra sẽ xuất hiện trong shell mà bạn đã sử dụng để khởi chạy strace.

Điểm hay của strace là bạn có thể thấy lệnh gọi hàm / kernel gần đây nhất tại thời điểm ứng dụng kích hoạt sự chậm lại. Bạn có thể thấy rằng nếu /hometài khoản của bạn nằm trên NFS thì ứng dụng gặp một số khó khăn với tệp I / O qua NFS vì một số lý do.