Есть ли способ получить соотношение Cache Hit / Miss для блочных устройств в Linux?

Можно ли увидеть в Linux, сколько запросов на чтение и запись из пользовательского пространства в конечном итоге приводит к попаданиям в кеш и пропускам блоковых устройств?

Вы можете разработать свой собственный скрипт SystemTap . Вам необходимо учесть следующие две подсистемы:

• VFS: это представляет все запросы ввода-вывода перед буферным кешем (т.е. абсолютно каждый запрос ввода-вывода); просмотрите зонды "vfs.read", "vfs.write" и "kernel.function (" vfs_ * ")"; вам нужно отфильтровать блочные устройства, которые вы хотите отслеживать, по их соответствующим старшим + младшим номерам.
• Блок: это представляет все запросы ввода / вывода, отправленные на блочные устройства до планировщика ввода / вывода (который также выполняет слияние + переупорядочение запросов ввода / вывода); здесь мы знаем, какие запросы были пропущены кешем буфера; просмотрите зонд «ioblock.request».

Разработка SystemTap занимает некоторое время, чтобы учиться. Если вы умеренный разработчик и хорошо разбираетесь в Linux, вам нужно сделать это за 3-4 дня. Да, для изучения требуется время, но вы будете очень довольны результатами - SystemTap дает вам возможность (безопасно) поместить зонды практически в любое место ядра Linux.

Обратите внимание, что ваше ядро ​​должно иметь поддержку для загрузки и выгрузки модулей ядра. В настоящее время большинство стандартных ядер поддерживают это. Вам также необходимо установить символы отладки для вашего ядра. Для моей системы Ubuntu это было так же просто, как загрузить файл .deb размером в несколько сотен МБ, который мне разработала команда разработчиков ядра Ubuntu. Это объясняется, например, на вики-странице SystemtapOnUbuntu .

PS Используйте подход SystemTap только в том случае, если у вас нет другого решения, потому что это совершенно новая структура, которую вы должны изучить, и которая стоит времени / денег, а иногда и разочарований.

Я пошел вперед и написал сценарий для этого. В системной тапе есть один, но он не является правильным. В базовом тестировании это выглядит довольно точно, но 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
}

/ proc / slabinfo - хорошее начало, но оно не дает вам достаточно информации, которую вы ищете (не обманывайте себя процентами попаданий / промахов в системах с несколькими ядрами и включенной статистикой; это нечто иное). Насколько я знаю, нет способа извлечь эту конкретную информацию из ядра, хотя не должно быть очень сложно написать немного кода для выполнения.

Изменить: http://www.kernel.org/doc/man-pages/online/pages/man5/slabinfo.5.html

Теперь есть утилита cachestat из пакета perf-tools .

Автор также перечисляет некоторые (возможно, более грубые) альтернативы, которые используют люди:

A) Изучите частоту пропадания кэша страниц с помощью iostat (1) для мониторинга операций чтения с диска и предположите, что это ошибки кэша, а не, например, O_DIRECT. В любом случае, процент пропусков, как правило, является более важным показателем, чем коэффициент, поскольку пропуски пропорциональны боли при применении. Также используйте free (1), чтобы увидеть размеры кэша.

Б) Удалить кэш страницы (echo 1> / proc / sys / vm / drop_caches) и измерить, насколько ухудшается производительность! Мне нравится использование отрицательного эксперимента, но это, конечно, болезненный способ пролить свет на использование кеша.

C) Используйте sar (1) и изучите мелкие и серьезные неисправности. Я не думаю, что это работает (например, обычный ввод / вывод).

D) Используйте скрипт SystemTap cache-hit-rate.stp, который является вторым в интернет-поиске коэффициента попадания в кеш страниц Linux. Он обеспечивает доступ к кэш-памяти, находящейся высоко в стеке, в интерфейсе VFS, так что можно увидеть чтение в любой файловой системе или устройстве хранения. Промахи кэша измеряются через их дисковый ввод / вывод. При этом также пропускаются некоторые типы рабочей нагрузки (некоторые упоминаются в «Уроках» на этой странице) и соотношения вызовов «тарифы».

Если вы заинтересованы в соотношении попаданий / пропусков ввода-вывода определенного процесса, простой, но очень эффективный подход заключается в чтении /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, поэтому для процессов, которые много читают / записывают из / в канал, приведенные выше вычисления будут искажены, сообщая о более высоком коэффициенте попадания, чем эффективный.