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

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

21 голос | спросил Kyle Brandt 5 J000000Monday10 2010, 19:43:38

5 ответов


9

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

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

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

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

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

ответил famzah 6 J000000Tuesday10 2010, 10:44:54
8

Я пошел вперед и написал для этого сценарий stap. Есть один в вики-файле 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
}
ответил Dave Wright 28 PMpThu, 28 Apr 2011 18:39:45 +040039Thursday 2011, 18:39:45
2

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

Изменить: http: //www .kernel.org /док /человеко-страница /интернет /страницы /man5 /slabinfo.5.html

ответил BMDan 5 J000000Monday10 2010, 20:52:21
1

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

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

  

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

     

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

     

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

     

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

ответил lemonsqueeze 24 PMpSun, 24 Apr 2016 15:18:44 +030018Sunday 2016, 15:18:44
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, поэтому для процессов, которые читают /записывают много из /в трубу вычисление выше будет искажено, сообщая о более высоком коэффициенте попадания, чем эффективный.

ответил shodanshok 24 PMpSun, 24 Apr 2016 18:45:40 +030045Sunday 2016, 18:45:40

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132