Назад | Перейти на главную страницу

Есть ли способ получить соотношение попаданий в кэш / промахов для блочных устройств в Linux?

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

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

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

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

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

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

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

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

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

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

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

D) Используйте сценарий cache-hit-rate.stp SystemTap, который занимает второе место в поиске в Интернете по коэффициенту попадания в кэш страниц 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 value включает такую ​​вещь, как tty IO, поэтому для процессов, которые много читают / записывают из / в канал, приведенный выше расчет будет искажен, сообщая о более высоком коэффициенте совпадений, чем эффективный.