Linuxのブロックデバイスのキャッシュヒット/ミス比を取得する方法はありますか?


21

Linuxで、ユーザー空間からの読み取りおよび書き込み要求がブロックデバイスのキャッシュヒットとキャッシュミスの原因になることを確認することはできますか?

回答:


9

独自のSystemTapスクリプトを開発できます。次の2つのサブシステムを考慮する必要があります。

  • VFS:これは、バッファキャッシュの前のすべてのI / O要求(つまり、すべてのI / O要求)を表します。「vfs.read」、「vfs.write」、および「kernel.function( "vfs_ *")」プローブを確認します。監視するブロックデバイスをそれぞれのメジャー番号とマイナー番号で除外する必要があります。
  • ブロック:これは、I / Oスケジューラーの前にブロックデバイスに送信されたすべてのI / O要求を表します(I / O要求のマージと並べ替えも行います)。ここで、バッファキャッシュによってミスされたリクエストがわかります。「ioblock.request」プローブを確認します。

SystemTapの開発は学習に時間がかかります。あなたが中程度の開発者であり、Linuxの十分な知識がある場合、3〜4日で完了します。はい、学習するには時間がかかりますが、結果に非常に満足しています。SystemTapを使用すると、Linuxカーネルのほぼすべての場所に(安全に)プローブを配置できます。

カーネルは、カーネルモジュールのロードとアンロードをサポートしている必要があることに注意してください。現在、ほとんどのカーネルはこれをサポートしています。また、カーネルのデバッグシンボルをインストールする必要があります。私のUbuntuシステムでは、これはUbuntuカーネル開発チームが私のためにコンパイルした数百MBの.debファイルをダウンロードするのと同じくらい簡単でした。これは、例えばSystemtapOnUbuntu Wikiページで説明されています。

PS SystemTapアプローチは、他に解決策がない場合にのみ使用してください。これは、習得しなければならないまったく新しいフレームワークであり、時間/費用がかかり、時にはフラストレーションが発生するためです。


1
+1のわかりやすい説明。ありがとう、私もsystemtapをチェックアウトします。
リシャシン


8

先に進んで、このためのスクリプトを作成しました。systemtap wikiには1つありますが、正しくないようです。基本的なテストでは、これはかなり正確に見えますが、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
}

驚くばかり!閉じたときに印刷するために、平均的なキャッシュ使用統計を少し追加しました:pastie.org/1845683
entropo

コードをコピーして貼り付けて実行しましたが、次のエラーが発生したため、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]お手伝いできますか?
フォパレオンコンスタンタン

2

/ proc / slabinfoは良いスタートですが、探している情報を十分に提供していません(複数のコアと統計が有効になっているシステムでのヒット/ミスの割合にだまされないでください;これらは別のものです)。私の知る限り、カーネルから特定の情報を引き出す方法はありませんが、少しのコードを書くのはそれほど難しくないはずです。

編集:http : //www.kernel.org/doc/man-pages/online/pages/man5/slabinfo.5.html


1

現在、perf-toolsパッケージのcachestatユーティリティがあります。

著者はまた、人々が使用するいくつかの(おそらく粗雑な)代替をリストしています:

A)iostat(1)を使用してディスク読み取りを監視することでページキャッシュミス率を調べ、これらがキャッシュミスであり、たとえばO_DIRECTではないことを想定します。ミスはアプリケーションの痛みに比例するため、通常、ミス率は比率よりも重要なメトリックです。キャッシュサイズを確認するには、free(1)も使用します。

B)ページキャッシュを削除し(エコー1> / proc / sys / vm / drop_caches)、パフォーマンスがどの程度悪化するかを測定します!ネガティブな実験の使用は大好きですが、これはもちろん、キャッシュの使用量に光を当てる苦痛な方法です。

C)sar(1)を使用して、軽度および重度の障害を調査します。私はこれが機能するとは思わない(例えば、通常のI / O)。

D)cache-hit-rate.stp SystemTapスクリプトを使用します。これは、Linuxページキャッシュヒット率のインターネット検索で2番目です。スタック内のVFSインターフェイスでキャッシュアクセスを計測するため、任意のファイルシステムまたはストレージデバイスへの読み取りを確認できます。キャッシュミスは、ディスクI / Oを介して測定されます。これにより、一部のワークロードタイプ(そのページの「レッスン」で説明されているものもあります)が欠落し、比率を「レート」と呼びます。


1

特定のプロセスのIOヒット/ミス率に関心がある場合は、/proc/<pid>/ioファイルを読み取ることは簡単ですが非常に効果的なアプローチです。

ここには4つのキー値があります。

  • rcharアプリケーションの観点からの読み取りバイトの合計数(つまり、キャッシュからではなく、物理ストレージから満たされた読み取りの間に差が生じない場合)
  • wchar:上記と同じですが、書き込まれたバイトについて
  • read_bytes:ストレージサブシステムから実際に読み取られたバイト
  • write_bytes:ストレージサブシステムに実際に書き込まれたバイト

プロセスには次の値があるとします。

rchar: 1000000
read_bytes: 200000

読み取りキャッシュミス率(バイト単位)はで100*200000/1000000 = 20%、ヒット率は100-20 = 80%

ただし、キャッチがありrcharます。値にはtty IOとしてのものが含まれているため、パイプとの間で大量の読み取り/書き込みを行うプロセスでは、上記の計算がゆがみ、有効なヒット率より高いヒット率が報告されます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.