Có cách nào để lấy tỷ lệ Cache Hit / Miss cho các thiết bị chặn trong Linux không?


21

Có thể thấy trong Linux có bao nhiêu yêu cầu đọc và ghi từ không gian người dùng cuối cùng gây ra các lần truy cập bộ nhớ cache và bỏ lỡ cho các thiết bị khối không?

Câu trả lời:


9

Bạn có thể phát triển tập lệnh SystemTap của riêng bạn . Bạn cần tính đến hai hệ thống con sau:

  • VFS: điều này thể hiện tất cả các yêu cầu I / O trước bộ đệm Buffer (tức là hoàn toàn mọi yêu cầu I / O); xem lại các thăm dò "vfs.read", "vfs.write" và "kernel.feft (" vfs_ * ")"; bạn cần lọc ra các thiết bị khối mà bạn muốn theo dõi theo số chính + số phụ tương ứng của chúng.
  • Chặn: điều này thể hiện tất cả các yêu cầu I / O được gửi đến các thiết bị khối trước bộ lập lịch I / O (cũng hợp nhất + sắp xếp lại các yêu cầu I / O); ở đây chúng tôi biết những yêu cầu nào bị bỏ qua bởi bộ đệm Buffer; xem lại thăm dò "ioblock.request".

Phát triển SystemTap cần một chút thời gian để tìm hiểu. Nếu bạn là một nhà phát triển vừa phải và có kiến ​​thức tốt về Linux, bạn nên hoàn thành sau 3-4 ngày. Đúng, cần có thời gian để tìm hiểu, nhưng bạn sẽ rất hài lòng với kết quả - SystemTap mang đến cho bạn cơ hội (an toàn) đặt các đầu dò ở hầu hết mọi nơi trong nhân Linux.

Lưu ý rằng kernel của bạn phải có hỗ trợ tải và dỡ các mô-đun kernel. Hầu hết các hạt nhân chứng khoán ngày nay đều hỗ trợ điều này. Bạn cũng sẽ cần phải cài đặt các biểu tượng gỡ lỗi cho kernel của mình. Đối với hệ thống Ubuntu của tôi, việc này dễ như tải xuống tệp vài trăm MB .deb, nhóm phát triển nhân Ubuntu đã biên dịch cho tôi. Điều này được giải thích tại trang SystemtapOnUb Ubuntu Wiki chẳng hạn.

PS Chỉ thực hiện phương pháp SystemTap nếu bạn không có giải pháp nào khác, bởi vì đó là một khuôn khổ hoàn toàn mới mà bạn phải học, và điều đó làm tốn thời gian / tiền bạc và đôi khi là sự thất vọng.


1
+1 giải thích tốt đẹp và sạch sẽ. cảm ơn bạn, tôi cũng sẽ kiểm tra systemtap.
risyasin


8

Tôi đã đi trước và viết một kịch bản chính cho điều này. Có một cái trên wiki systemtap, nhưng nó không có vẻ đúng. Trong thử nghiệm cơ bản, điều này xuất hiện khá chính xác nhưng YMMV.

#! /usr/bin/env stap
global total_bytes, disk_bytes, counter

probe vfs.read.return {
  if (bytes_read>0) {
    if (devname=="N/A") {
    } else {
      total_bytes += bytes_read
    }
  }
}
probe ioblock.request
{
    if (rw == 0 && size > 0)
    {
        if (devname=="N/A") { 
        } else {
          disk_bytes += size
        }
    }

}

# print VFS hits and misses every 5 second, plus the hit rate in %
probe timer.s(5) {
    if (counter%15 == 0) {
        printf ("\n%18s %18s %10s %10s\n", 
            "Cache Reads (KB)", "Disk Reads (KB)", "Miss Rate", "Hit Rate")
    }
    cache_bytes = total_bytes - disk_bytes
    if (cache_bytes < 0)
      cache_bytes = 0
    counter++
    hitrate =  10000 * cache_bytes / (cache_bytes+disk_bytes)
    missrate = 10000 * disk_bytes / (cache_bytes+disk_bytes)
    printf ("%18d %18d %6d.%02d%% %6d.%02d%%\n",
        cache_bytes/1024, disk_bytes/1024,
        missrate/100, missrate%100, hitrate/100, hitrate%100)
    total_bytes = 0
    disk_bytes = 0
}

Tuyệt vời! Tôi đã thêm một chút bộ đệm trung bình sử dụng stat để in ra khi bạn đóng nó: pastie.org/1845683
entropo

Tôi đã sao chép / dán mã của bạn để chạy nó, do lỗi sau đây xảy ra, semantic error: unable to find member 'bi_size' for struct bio (alternatives: bi_next bi_bdev bi_flags bi_rw bi_iter bi_phys_segments bi_seg_front_size bi_seg_back_size bi_remaining bi_end_io bi_private bi_ioc bi_css bi_integrity bi_vcnt bi_max_vecs bi_cnt bi_io_vec bi_pool bi_inline_vecs): operator '->' at /usr/share/systemtap/tapset/linux/ioblock.stp:113:20 source: size = $bio->bi_size ^ Pass 2: analysis failed. [man error::pass2]bạn có thể giúp gì không?
Fopa Léon Constantin

2

/ Proc / slabinfo là một khởi đầu tốt, nhưng không cung cấp cho bạn khá nhiều thông tin bạn đang tìm kiếm (đừng bị lừa bởi tỷ lệ trúng / bỏ lỡ trên các hệ thống có nhiều lõi và chỉ số được bật; đó là những thứ khác). Theo như tôi biết, không có cách nào để lấy thông tin cụ thể đó ra khỏi kernel, mặc dù việc viết ra một chút mã để làm là cực kỳ khó khăn.

Chỉnh sửa: http://www.kernel.org/doc/man-pages/online/pages/man5/slabinfo.5.html


1

Bây giờ có tiện ích bộ nhớ cache từ gói công cụ hoàn hảo .

Tác giả cũng liệt kê một số lựa chọn thay thế (có thể là cruder) mà mọi người sử dụng:

A) Nghiên cứu tỷ lệ bỏ lỡ bộ đệm của trang bằng cách sử dụng i điều chỉnh (1) để theo dõi các lần đọc đĩa và giả sử đây là các lỗi bộ nhớ cache và không, ví dụ, O_DIRECT. Tỷ lệ bỏ lỡ thường là một số liệu quan trọng hơn so với tỷ lệ, vì các lần bỏ lỡ tỷ lệ thuận với nỗi đau của ứng dụng. Cũng sử dụng miễn phí (1) để xem kích thước bộ đệm.

B) Thả bộ đệm trang (echo 1> / Proc / sys / vm / drop_caches) và đo mức độ hiệu suất trở nên tồi tệ hơn! Tôi thích việc sử dụng một thử nghiệm tiêu cực, nhưng tất nhiên đây là một cách đau đớn để làm sáng tỏ việc sử dụng bộ đệm.

C) Sử dụng sar (1) và nghiên cứu các lỗi nhỏ và lớn. Tôi không nghĩ rằng nó hoạt động (ví dụ, I / O thường xuyên).

D) Sử dụng tập lệnh SystemTap cache-hit-Rate.stp, là số hai trong một tìm kiếm trên Internet cho tỷ lệ nhấn bộ nhớ cache của trang Linux. Nó lưu trữ bộ nhớ cache truy cập cao trong ngăn xếp, trong giao diện VFS, để có thể nhìn thấy bất kỳ hệ thống tệp hoặc thiết bị lưu trữ nào. Lỗi bộ nhớ cache được đo thông qua I / O đĩa của họ. Điều này cũng bỏ lỡ một số loại khối lượng công việc (một số được đề cập trong "Bài học" trên trang đó) và gọi tỷ lệ là "tỷ lệ".


1

Nếu bạn quan tâm đến tỷ lệ hit / miss IO của một quy trình cụ thể, một cách tiếp cận đơn giản nhưng rất hiệu quả là đọc /proc/<pid>/iotệp.

Ở đây bạn sẽ tìm thấy 4 giá trị chính:

  • rchar: tổng số byte đọc từ quan điểm ứng dụng (nghĩa là: không có sự khác biệt nào giữa việc đọc được thỏa mãn từ bộ nhớ vật lý thay vì từ bộ đệm)
  • wchar: như trên, nhưng về byte được viết
  • read_bytes: các byte thực sự được đọc từ hệ thống con lưu trữ
  • write_bytes: các byte thực sự được ghi vào hệ thống con lưu trữ

Nói một quá trình có các giá trị sau:

rchar: 1000000
read_bytes: 200000

Tỷ lệ bỏ lỡ bộ đệm đọc (tính bằng byte) là 100*200000/1000000 = 20%và tỷ lệ nhấn là100-20 = 80%

Tuy nhiên, có một nhược điểm: rchargiá trị bao gồm thứ là tty IO, do đó, đối với các quá trình đọc / ghi nhiều từ / đến một đường ống, phép tính ở trên sẽ bị sai lệch, báo cáo tỷ lệ trúng cao hơn so với hiệu quả.

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.