Практика работы с NetBSD: профилирование ядра::Журнал СА 8.2004
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

  Статьи

Вектор роста  

Особенности сертификаций по этичному хакингу

В современном мире информационных технологий знания о них настолько широки и многообразны,

 Читать далее...

1001 и 1 книга  
04.12.2019г.
Просмотров: 70
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 2579
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 2587
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 2087
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1648
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Практика работы с NetBSD: профилирование ядра

Архив номеров / 2004 / Выпуск №8 (21) / Практика работы с NetBSD: профилирование ядра

Рубрика: Администрирование /  Продукты и решения

АЛЕКСАНДР БАЙРАК

Практика работы с NetBSD: профилирование ядра

Перед началом рассмотрения процесса профилирования я предполагаю, что вы установили исходные тексты системы и умеете перекомпилировать ядро. Как это сделать, было описано в статье «Первые шаги в NetBSD. Часть 1», опубликованной в июньском номере журнала.

Целью и задачей профилирования ядра служит сравнение производительности старого и нового ядра. Например, вы скомпилировали новое ядро, и по вашим расчетам оно должно работать быстрее первого, но желаемого результата получено не было. В чем дело? Где вы ошиблись? Все это можно будет выяснить, используя профилирование ядра. Если вы собираете NetBSD для какой-либо встроенной системы, без профилирования вам точно не обойтись. Ведь во встроенных системах аппаратные характеристики железа, как правило, очень ограниченны. А без использования профилирования вряд ли удастся настроить систему на оптимальную производительность.

Рассмотрим пример профилирования для NetBSD, работающей на обычном x86-компьютере. Для примера мы возьмем ядро GENERIC, поставляющееся с системой по умолчанию, и сравним его по производительности с собранным вами новым ядром.

Соберем профилированное GENERIC-ядро.

Переходим в каталог, где располагаются конфигурационные файлы ядра:

# cd /sys/arch/i386/conf/

Опция –p указывает, что собираемое ядро будет профилироваться:

# config –p GENERIC

Запускаем сборку ядра:

# cd ../compile/GENERIC.PROF/

# make depend && make

Сохраняем старое ядро:

# cp /netbsd /netbsd.old

Копируем в корень новое:

# cp netbsd /netbsd

Перезагружаемся:

# reboot

Сразу после загрузки системы проверим, работает профилирование или нет.

# kgmon – b

В ответ мы должны получить:

kgmon: kernel profiling is running.

Теперь отключим профилирование:

# kgmon –h

В ответ мы получим:

kgmon: kernel profiling is off.

Теперь нам нужно поместить данные kgmon в файл.

# kgmon –p

После этой команды мы получим файл gmon.out размером около 3 Мб.

Далее нам нужно получить вывод gprof:

#gprof /netbsd > gprof.out

Должен заметить, имя файла для вывода можно выбрать самому. Примерно через 2-3 минуты в текущем каталоге появится заказанный нами файл gprof.out. После этого переходим непосредственно к процессу анализа полученных данных. Смотрим наш gprof.out (или как вы его назвали).

Первым разделом идет Flat profile, это список всех вызванных функций, время и количество их вызовов.

Вот пример части вывода:

Flat profile:

Each sample counts as 0.01 seconds.
%            cumulative      self                  self            total
time      seconds      seconds      calls      us/call      us/call      name
98.48      4.55            4.55                                          idle
 0.43      4.57            0.02            331      60.42            60.42            pmap_enter
 0.43      4.59            0.02                                          Xtrap0e
 0.22      4.60            0.01            31      322.58            322.58            pmap_do_remove
 0.00      4.61            0.01            4      0.00            422.11       check_exec

Дальше в том же духе. Давайте рассмотрим содержание этих столбцов более подробно.

  1. Сколько всего времени (в процентах) исполнялась та или иная функция.
  2. Общая сумма времени (в секундах) выполнения всех функций до текущего момента.
  3. Время (в секундах) исполнения какой-либо функции. Это основной показатель данной таблицы.
  4. Общее количество вызовов некой функции.
  5. Среднее время (в миллисекундах), истраченное на вызов функции. Если функция не профилируется, то столбец останется пустым. Например, функцию idle, как вы понимаете, «улучшить» никак нельзя, поэтому текущий столбец для этой функции оказался незаполненным.
  6. Среднее время (в миллисекундах), истраченное этой функцией и ее потомками на вызов. Так же, как и в предыдущем столбце, если функция не профилируется, значение остается пустым.
  7. Имя функции.

Как видно из этого фрагмента, подавляющее большинство времени система бездействовала.

Теперь следует раздел Call Graph Profile. Его задача – показать дальнейшие запросы («потомки») от перечисленных функций.

Вот часть вывода:

granularity: each sample hit covers 4 byte(s) for 0.01% of 75.78 seconds

index      % time            self            children      called            name
                                                         
[1]          97.7            74.04            0.00                        idle [1]
                                                          < spontaneous>
[2]           0.9             0.00            0.65                        shed_sync [2]
                         0.01            0.63            12/12         VOP_FSYNC (cycle 1) [4]
                         0.00            0.00            75/1731      ltsleep [62]
                         0.00            0.00            152/1731     lockmgr [310]

И так далее. Всего 6 столбцов с данными.

  1. Уникальное число, присвоенное каждой функции.
  2. Cколько времени (в процентах) исполнялась некая функция и все ее «потомки».
  3. Общий процент времени, истраченный на эту функцию.
  4. Общее время, занятое «потомками» этой функции.
  5. Сколько раз функция была вызвана. После «/» идет количество вызовов этой функции ее потомками. Рекурсивные вызовы не учитываются.
  6. Имя функции.

Следующим разделом этого файла является список всех функций, которые указывались выше, отсортированные в алфавитном порядке, и с указанием уникального номера, присвоенного в разделе Call graph profile. После того как мы проанализировали полученные данные, давайте создадим еще одно ядро системы. Отличие от «оригинального» будет в заведомой «заторможенности» одной из функций. Для примера (как и в NetBSD handbook) возьмем функцию check_exec. Настало время немного поправить ядро системы. Берем свой любимый текстовый редактор и открываем файл /usr/src/sys/kern/kern_exec.c. Ищем там функцию check_exec и добавляем в конце вот такой код:

for (x = 0; x < 100000000; x++)

{

y = x;

}

Не забыв в начале функции check_exec, написать:

int x;

int y;

После внесения этих нехитрых изменений, снова перекомпилируем ядро. Естественно, с профилированием. Перезагрузившись, повторяем уже известные нам действия по созданию файлов gmon.out и gprof.out. И переходим к анализу полученных файлов.

В данном случае результат сразу бросается в глаза, вот что у меня получилось в gprof.out, раздел Flat profile:

Each sample counts as 0.01 seconds.
  %         cumulative         self              self         total
 time         seconds         seconds          calls             us/call        us/call              name
 93.97         136.13         136.13                                                                 idle
  5.87         143.81           7.68             25             466826.09       466842.52            check_exec
  0.01         143.83           0.02            243                 82.30           82.30            pmap_copy_page

Сравним получившиеся результаты функции check_exec с теми, которые были получены до модификации последней.

До:

0.00      4.61            0.01            4           0.00      422.11       check_exec

После:

5.87          143.81       7.68                   25           466826.09       466842.52      check_exec

Разница, я думаю, всем понятна. А теперь представим, что изменения, аналогичные тем, что мы специально добавили в систему для уменьшения производительности, попали в код случайно, например, вследствие ошибки программиста. Без профилирования, как мне кажется, будет сложно узнать, что именно «притормаживает» систему. А какие перспективы открывает профилирование для оценки оптимизации кода ядра! Внесли некоторые изменения в процедуру, погоняли машину в тестовом режиме, сравнили результаты с тем, что было в старом варианте и что получилось в новом.

И все видно сразу как на ладони. Для любителей оптимизации и разработчиков встроенных систем это просто находка!

Вообще тема профилирования достаточно обширна, но думаю, что описанного выше простого примера вполне достаточно, чтобы понять принцип профилирования ядра.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru