Giám sát IO của Linux trên mỗi tệp?


29

Tôi quan tâm đến một tiện ích hoặc quy trình giám sát IO đĩa trên mỗi tệp trên CentOS.

Trên Win2008, tiện ích resmon cho phép loại truy vấn ngược này, nhưng không có tiện ích Linux nào tôi tìm thấy để làm điều này (iostat, iotop, dstat, nmon).

Tôi quan tâm đến việc theo dõi các tắc nghẽn IO trên các máy chủ cơ sở dữ liệu. Với MSSQL, tôi đã tìm thấy nó một chẩn đoán thông tin để biết tệp / không gian tệp nào bị ảnh hưởng nặng nề nhất.



1
Nếu điều này là có thể, lưu ý rằng hầu hết các tệp được ánh xạ vào pagecache để số của bạn có thể ở khắp mọi nơi tùy thuộc vào byte nào trong pagecache và những gì trên đĩa.
Matthew Ife

@Matt Nhưng với một câu trả lời làm việc!
ewwhite

Câu trả lời:


18

SystemTap có lẽ là lựa chọn tốt nhất của bạn.

Đây là cách đầu ra từ ví dụ iotime.stp trông như sau:

825946 3364 (NetworkManager) access /sys/class/net/eth0/carrier read: 8190 write: 0
825955 3364 (NetworkManager) iotime /sys/class/net/eth0/carrier time: 9
[...]
117061 2460 (pcscd) access /dev/bus/usb/003/001 read: 43 write: 0
117065 2460 (pcscd) iotime /dev/bus/usb/003/001 time: 7
[...]
3973737 2886 (sendmail) access /proc/loadavg read: 4096 write: 0
3973744 2886 (sendmail) iotime /proc/loadavg time: 11

Nhược điểm (ngoài đường cong học tập) là bạn sẽ cần cài đặt gỡ lỗi kernel , điều này có thể không thực hiện được trên một hệ thống sản xuất. Tuy nhiên, bạn có thể sử dụng công cụ chéo trong đó bạn biên dịch mô-đun trên hệ thống phát triển và chạy .ko đó trên hệ thống sản xuất.

Hoặc nếu bạn không kiên nhẫn, hãy xem Chương 4. Các tập lệnh SystemTap hữu ích từ hướng dẫn cho người mới bắt đầu.


17

Tập lệnh SystemTap * :

#!/usr/bin/env stap
#
# Monitor the I/O of a program.
#
# Usage:
#   ./monitor-io.stp name-of-the-program

global program_name = @1

probe begin {
  printf("%5s %1s %6s %7s %s\n",
         "PID", "D", "BYTES", "us", "FILE")
}

probe vfs.read.return, vfs.write.return {
  # skip other programs
  if (execname() != program_name)
    next

  if (devname=="N/A")
    next

  time_delta = gettimeofday_us() - @entry(gettimeofday_us())
  direction = name == "vfs.read" ? "R" : "W"

  # If you want only the filename, use
  // filename = kernel_string($file->f_path->dentry->d_name->name)
  # If you want only the path from the mountpoint, use
  // filename = devname . "," . reverse_path_walk($file->f_path->dentry)
  # If you want the full path, use
  filename = task_dentry_path(task_current(),
                              $file->f_path->dentry,
                              $file->f_path->mnt)

  printf("%5d %1s %6d %7d %s\n",
         pid(), direction, $return, time_delta, filename)
}

Đầu ra trông như thế này:

[root@sl6 ~]# ./monitor-io.stp cat
PID D  BYTES      us FILE
3117 R    224       2 /lib/ld-2.12.so
3117 R    512       3 /lib/libc-2.12.so
3117 R  17989     700 /usr/share/doc/grub-0.97/COPYING
3117 R      0       3 /usr/share/doc/grub-0.97/COPYING

Hoặc nếu bạn chọn chỉ hiển thị đường dẫn từ điểm gắn kết:

[root@f19 ~]# ./monitor-io.stp cat
  PID D  BYTES      us FILE
26207 R    392       4 vda3,usr/lib64/ld-2.17.so
26207 R    832       3 vda3,usr/lib64/libc-2.17.so
26207 R   1758       4 vda3,etc/passwd
26207 R      0       1 vda3,etc/passwd
26208 R    392       3 vda3,usr/lib64/ld-2.17.so
26208 R    832       3 vda3,usr/lib64/libc-2.17.so
26208 R  35147      16 vdb7,ciupicri/doc/grub2-2.00/COPYING
26208 R      0       2 vdb7,ciupicri/doc/grub2-2.00/COPYING

[root@f19 ~]# mount | grep -E '(vda3|vdb7)'
/dev/vda3 on / type ext4 (rw,relatime,seclabel,data=ordered)
/dev/vdb7 on /mnt/mnt1/mnt11/data type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

Hạn chế / lỗi:

  • mmap dựa I / O không hiển thị vì devname"N/A"
  • các tập tin trên tmpfs không hiển thị vì devname"N/A"
  • không có vấn đề gì nếu các lần đọc là từ bộ đệm hoặc ghi vào bộ đệm

Kết quả cho các chương trình của Matthew Ife :

  • cho mmaptest private:

     PID D  BYTES      us FILE
    3140 R    392       5 vda3,usr/lib64/ld-2.17.so
    3140 R    832       5 vda3,usr/lib64/libc-2.17.so
    3140 W     23       9 N/A,3
    3140 W     23       4 N/A,3
    3140 W     17       3 N/A,3
    3140 W     17     118 N/A,3
    3140 W     17     125 N/A,3
    
  • cho mmaptest được chia sẻ:

     PID D  BYTES      us FILE
    3168 R    392       3 vda3,usr/lib64/ld-2.17.so
    3168 R    832       3 vda3,usr/lib64/libc-2.17.so
    3168 W     23       7 N/A,3
    3168 W     23       2 N/A,3
    3168 W     17       2 N/A,3
    3168 W     17      98 N/A,3
    
  • cho diotest (I / O trực tiếp):

     PID D  BYTES      us FILE
    3178 R    392       2 vda3,usr/lib64/ld-2.17.so
    3178 R    832       3 vda3,usr/lib64/libc-2.17.so
    3178 W     16       6 N/A,3
    3178 W 1048576     509 vda3,var/tmp/test_dio.dat
    3178 R 1048576     244 vda3,var/tmp/test_dio.dat
    3178 W     16      25 N/A,3
    

* Hướng dẫn thiết lập nhanh cho RHEL 6 hoặc tương đương: yum install systemtapdebuginfo-install kernel


Đó là một số systemtap khá ấn tượng ngay tại đó. Một minh chứng tuyệt vời về tính linh hoạt của nó.
Matthew Ife

Điều này có đo I / O trực tiếp và I / O không đồng bộ không? (sử dụng io_submit, không phải posix)
Matthew Ife

@Mlfe: cảm ơn! Như một lưu ý phụ, trong khi viết kịch bản, tôi đã phát hiện ra một lỗi nhỏ trong pv và một lỗi khác trong SystemTap ( task_dentry_path) :-) Tôi không biết gì về I / O đó, nhưng tôi có thể kiểm tra nếu bạn đưa cho tôi lệnh hoặc một chương trình mẫu. Ví dụ tôi đã sử dụng Python để kiểm tra mmap. dd iflag=direct oflag=directxuất hiện.
Cristian Ciupitu

2
Hãy thử điều này cho mmap: gist.github.com/anonymous/7014284 Tôi đang đặt cược các ánh xạ riêng tư không được đo nhưng các chia sẻ là ..
Matthew Ife

2
Đây là bài kiểm tra IO trực tiếp: gist.github.com/anonymous/7014604
Matthew Ife

9

Bạn thực sự muốn sử dụng blktracecho việc này. Xem trực quan hóa Linux IO với Seekwatcher và blktrace .

Tôi sẽ xem liệu tôi có thể đăng một trong những ví dụ của mình sớm không.


Chỉnh sửa:

Bạn không đề cập đến việc phân phối Linux, nhưng có lẽ đây là một trường hợp tốt cho tập lệnh dtrace trên Linux hoặc thậm chí là System Tap , nếu bạn đang sử dụng một hệ thống giống như RHEL.


2
Cảm ơn, điều tốt và rất gần với điểm, nhưng nó cung cấp thông tin lớp khối chi tiết, tôi cần một cái gì đó hoạt động trên lớp trừu tượng VFS.
GioMac

Tôi bắt đầu thử một số tập lệnh systemtap để chạy nó. Tôi thất bại vì máy chủ bị sập. Tôi có thể lấy thông tin này trên Dtrace trên Solaris. Tôi sẽ thử với Linux ngày hôm nay.
ewwhite

4

Công cụ duy nhất tôi biết có thể theo dõi hoạt động I / O theo tệp là inotifywatch. Đó là một phần của inotify-toolsgói. Thật không may, nó chỉ cung cấp cho bạn số lượng hoạt động.


4

sử dụng iotop để có được các quy trình đóng góp IO cao

chạy strace chống lại PID bạn đã tạo, bạn sẽ thấy tập tin nào đang được truy cập bởi một quy trình cụ thể

strace -f -p $PID -e trace=open,read,write

strace sẽ cung cấp thông tin về các tòa nhà và các tệp được truy cập, sẽ rất khó để phân tích và lấy số liệu thống kê về việc sử dụng ...
GioMac

1
Tôi nghĩ tôi sẽ thử nó. Nó tạo ra ALOT dữ liệu. Và có thể sụp đổ quá trình khi bạn ctrl + c. Nó có vẻ khá nguy hiểm.
Matt

4

Cuối cùng tôi đã sử dụng Sysdig cho việc này


Cách thực hiện: Cài đặt sysdig , chạy csysdig, nhấn F2 và chọn Fileschế độ xem. Bạn sẽ thấy đầu các tệp được truy cập theo cột OPS (có thể thay đổi bằng cách nhấn F9).
catpnosis

csysdig -v fileschuyển trực tiếp đến chế độ xem "Tệp"
Gert van den Berg

2

Tôi cho rằng bạn có thể đã hỏi sai câu hỏi. nếu bạn đang tìm kiếm các nút thắt cổ chai, có thể cũng quan trọng để xem những gì đang xảy ra trên đĩa của bạn. db nổi tiếng với việc thực hiện i / o ngẫu nhiên có thể làm giảm đáng kể thông lượng, đặc biệt nếu bạn chỉ có một vài trục chính.

Điều thú vị hơn là xem bạn có thời gian chờ đợi lâu trên đĩa không. bạn có thể làm điều này với colll thông qua lệnh "colll -sD", sẽ hiển thị các thống kê hiệu suất đĩa riêng lẻ. Là - một phần để biến nó thành một tiện ích giống như hàng đầu. Nếu có nhiều đĩa liên quan, hãy chạy nó qua colmux: colmux -command "-sD" và nó sẽ cho phép bạn sắp xếp theo một cột bạn chọn, thậm chí trên nhiều hệ thống.


Tôi không đồng ý với bạn từ góc độ đĩa. Nơi tôi có thể hiểu rõ hơn là khi không gian tệp cơ sở dữ liệu được sử dụng để phân vùng dữ liệu, chỉ mục, nhật ký, v.v., nhưng được gắn trên các đĩa được chia sẻ khi tài nguyên bị hạn chế - ví dụ như máy chủ phát triển. Lý tưởng nhất là mỗi không gian tệp này sẽ nằm trên các ổ riêng biệt, do đó nhìn vào IO từ phối cảnh đĩa sẽ đầy đủ - đó có thể là lý do tại sao tất cả các tiện ích giám sát đều là đĩa, không dựa trên tệp.
kermatt

Đó là câu hỏi đúng; mục tiêu là cố gắng tìm ra "bảng nào là tất cả I / O này xảy ra?", và trong hầu hết các cơ sở dữ liệu, một bảng là một hoặc nhiều tệp. Bất kỳ đĩa nào sẽ kết thúc với nhiều tệp trên đó và việc xác định các điểm nóng nào trong số đó là điểm đầu vào điều chỉnh cơ sở dữ liệu hữu ích.
Greg Smith

2

Bạn có thể theo dõi i / o trên mỗi thiết bị khối (thông qua / Proc / đĩa) và mỗi quy trình (kế toán io qua /proc/$PID/iohoặc tác vụ ), nhưng tôi không biết cách nào để thực hiện theo từng tệp.


0

Có thể inotify sẽ giải quyết điều này.

API inotify cung cấp một cơ chế giám sát các sự kiện của hệ thống tệp. Chú ý có thể được sử dụng để giám sát các tệp riêng lẻ hoặc để giám sát các thư mục. Khi một thư mục được theo dõi, inotify sẽ trả về các sự kiện cho chính thư mục đó và cho các tệp bên trong thư mục.

Giám sát hoạt động hệ thống tệp với inotify

tham chiếu inotify


Điều này có thể cung cấp các cuộc gọi được thực hiện trên tệp, nhưng cung cấp rất ít để giúp khám phá xem pid đã làm gì, viết lớn như thế nào, ở đâu và mất bao lâu.
Matthew Ife

Câu hỏi không hỏi về quy trình (có thể được phát hiện bằng các phương tiện khác, như lsof)
Gert van den Berg

0

Trong khi có rất nhiều thông tin tốt trong các câu trả lời ở đây, tôi tự hỏi liệu nó có thực sự áp dụng không?

Nếu bạn đang nói về các tệp trong 10 gigabyte, liên tục được ghi vào, trừ khi chúng là các tệp nhật ký hoặc tương tự liên tục được thêm vào (trong trường hợp đó chỉ giám sát kích thước tệp), rất có thể các tệp đó là mmap'd . Nếu đó là trường hợp, thì câu trả lời tốt nhất có thể là bạn nên ngừng xem xét hầu hết các giải pháp. Điều đầu tiên bạn nên hỏi về bất kỳ giải pháp được đề xuất nào khác là "nó có hoạt động với mmap không", bởi vì phần lớn chúng không hoạt động. Tuy nhiên, bạn có thể biến vấn đề thành giám sát một thiết bị khối thay vì theo dõi tệp.

Khi một chương trình yêu cầu một trang từ tệp mmap'd, nó chỉ tham chiếu một vị trí trong bộ nhớ ảo. Trang đó có thể có hoặc không có trong bộ nhớ. Nếu không, thì điều đó sẽ tạo ra lỗi trang, kích hoạt trang được tải từ đĩa, nhưng điều đó xảy ra trong hệ thống bộ nhớ ảo, không dễ bị ràng buộc với một quy trình ứng dụng cụ thể hoặc một tệp cụ thể. Tương tự, khi ứng dụng của bạn cập nhật trang mmap'd, tùy thuộc vào cờ, điều đó có thể không kích hoạt ghi ngay lập tức vào đĩa và trong một số trường hợp có thể không chuyển sang đĩa (mặc dù những trường hợp cuối cùng không phải là trường hợp bạn quan tâm trong).

Điều tốt nhất tôi có thể nghĩ đến đối với các tệp mmap, nếu khả thi đối với bạn, là đặt từng tệp quan tâm vào một thiết bị riêng biệt và sử dụng số liệu thống kê thiết bị để thu thập thông tin sử dụng của bạn. Bạn có thể sử dụng phân vùng lvm cho việc này. Gắn kết liên kết sẽ không hoạt động mặc dù nó không tạo ra một thiết bị khối mới.

Khi bạn có tệp của mình trên các thiết bị khối riêng biệt, bạn có thể nhận được số liệu thống kê từ / sys / block / * hoặc / Proc / Discstats

Có thể quá khó để giới thiệu điều này với một máy chủ sản xuất, nhưng có lẽ bạn có thể sử dụng nó.

NẾU các tệp không được khai thác, thì có, bạn có thể chọn một trong các giải pháp khác tại đây.


Xin vui lòng đọc kỹ, tôi không cần số liệu thống kê cấp khối :)
GioMac

Đúng, nhưng loại số liệu thống kê mà bạn đang yêu cầu không thể có đối với các tệp được mã hóa, vì vậy nếu bạn đang chống lại điều đó, thì điều này cung cấp cho bạn một cách có thể để lấy số liệu thống kê về các tệp bằng cách sử dụng một tệp trên mỗi thiết bị và đọc thống kê thiết bị.
mc0e

-1

Gần đây tôi đã mày mò thu thập , nó có vẻ là một công cụ tuyệt vời và khá khó để cài đặt. Thú vị nhất là bạn có thể tìm ra quy trình chịu trách nhiệm cho các tắc nghẽn IO. Tôi khuyên bạn nên đọc Sử dụng Sưu tầm , nó có thể hữu ích.


1
colll không giám sát mỗi tệp, nó hoạt động theo quy trình
Greg Smith


-2

Tôi nghĩ rằng iotop là một trong những công cụ tốt nhất trên Linux để xác định các tắc nghẽn trên IO.


3
-1 iotopkhông giám sát trên mỗi tệp, nó hoạt động theo quy trình
dyasny
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.