Глава 17. Точная настройка NetBSD
Русский перевод: Михаил Сгибнев
Содержание
- 17.1. Введение
- 17.2. Общие вопросы настройки
- 17.3. Visual Monitoring Tools
- 17.4. Утилиты мониторинга
- 17.5. Сетевые утилиты
- 17.6. Аккаунтинг
- 17.7. Профили ядра
- 17.8. Оптимизация системы
- 17.9. Оптимизация ядра
17.1.1. Краткий обзор
В этой главе рассматриватриваются вопросы повышения
производительности системы путем более тонкой настройки
различных параметров. В принципе, эта область охватывает
профессиональную сферу и администратора системы и системного
программиста. Искусство тонкой настройки очень старо и
призвано повысить эффективность работы без увеличения
мощности оборудования и может относиться и к NetBSD и к
самому серверу и в принципе, даже к пылесосу.
17.1.1.1. Что такое оптимизация производительности?
После загрузки системы автоматически начинает
выполняться довольно большое количество программ.
Пользователь, начав работать с системой, запускает свои
программы и нашей задачей является повышение производительности
операционной системы под наши конкретные нужды.
Самым распространенным мнением является то, что
«настройка» – это уменьшение размера ядра или увеличение
скорости. На самом деле, это только некоторые из аспектов,
которые нам придется рассмотреть, для того, чтобы
привести NetBSD в оптимальное
состояние.
Хорошим примером будет установка параметров файловой
системы. Для системы, где велико количество маленьких
файлов(допустим, репозиторий исходных текстов), администратор
может увеличить число inodes.
Настройка обычно заключается в обнаружении и устранении
критических параметров. В большинстве случаев критические
ситуации являются побочным явлением, например, Mozilla
очень плохо обрабатывает java-апплеты, что может привести
к повышенной нагрузке на центральный процессор или размер
сервера rsynced начинает расти и расти.
17.1.1.2. Когда делать настройку?
Настраивать систему необходимо довольно небольшой
группе пользователей. GENERIC ядро работает прекрасно
и конфигурация позволяет использовать его для самых
разнообразных задач. Если же точная настройка все-таки
необходима, то необходимо четко себе представлять, что
вы будете делать. Настройка обычно делается после
внезапной потери или постепенного снижения производительности,
когда неприятные последствия уже наступают. Давайте не
будем учиться на своих ошибках и рассмотрим основные
методы настройки.
Примером настройки системы может служить желание
получить систему с малым временем перезагрузки. Необходимо
в таком случае как только можно сильнее урезать ядро,
убедившись, что в состав его не входят лишние драйвера(и
даже драйвера присутствующих, но неиспользуемых устройств(lp),
отказаться от запуска дополнительных сервисов. В результате
время загрузки можно сократить почти на две трети, что
при повседневной работе является прекрасным результатом.
17.1.1.3. Что не рассматривается в этом документе
Прежде, чем приступить непосредственно к материалу
главы, хотелось бы оговорить, что здесь не будет рассмотрено.
Это руководство касается только ядра NetBSD, то есть файлы
конфигурации сторонних программ затронуты не будут, так
как про это можно писать до бесконечности и у них, в
большинстве случаев, имеется собственная документация.
17.1.1.4. Используемые примеры
Так как имеется обширная документация на страницах
руководства man, то будут рассмотрены только используемые
в каждом конкретном примере опции и аргументы. В некоторых
случаях материал для краткости усечен или не полностью
описан вследствие простоты. Например, не будет описываться
каждый драйвер ядра в отдельности, однако методика
определения необходимых драйверов будет рассмотрена. Не
стоит принимать этот раздел как непосредственную инструкцию,
это всего лишь учебное пособие.
17.2. Общие вопросы настройки
Тонкая настройка системы не является таким уж сложным
делом, просто заняться этим стоит до того, как
«началось». Настроить сервер до его ввода в
строй проще, чем во время простоя.
17.2.1. Конфигурация системы
Конечно, первоначальная установка системы имеет огромное
значение, так как на этом этапе можно допустить незначительную
ошибку, которая в последствии приведет к неожиданным
проблемам.
17.2.1.1. Файловая система и диски
Размещение файловых систем на дисках – очень важный
вопрос. На системах с аппаратным RAID это не так критично,
но большое число пользователей NetBSD работают с устаревшим
оборудованием, где просто нет RAID. Хорошей идеей будет
размещение / в начале диска, но если
дисков несколько? Стоит ли выделить в отдельный раздел
/usr? Будет ли интенсивно использоваться
/usr/pkgsrc? Подумайте перед началом
установки над этими вопросами.
17.2.1.2. Конфигурация раздела подкачки
Есть три теории вычисления размера раздела подкачки
и около пятидесяти о разбиении файла подкачки с расстановкой
приоритетов. Каждая теория имеет свои собственные формулы
расчета, например для HP-UX с установленной на нем Oracle
использует формулу:
2.5 GB * Number_of_processor
На самом деле, здесь все зависит от размера и
интенсивности использования баз данных, для примера, если
база данных распределенная, то форма будет не верна.
Следующий подход к расчету размера раздела подкачки
хотя и выглядит несколько странным, но не лишен определенного
смысла. Суть его в том, чтобы по возможности при расчетах
опираться на объем памяти, который необходим для работы
системы. Например, как-нибудь так:
- Посчитайте общее количество необходимой памяти
при одновременном запуске всего, что вам может
потребоваться. Это базы данных, web серверы и так
далее. - Добавьте несколько мегабайт про запас.
- Вычтите значение RAM из результата.
Если получившийся остаток превышает размер RAM в три
и более раза, то рассмотрите возможность увеличения RAM.
Конечно, есть проблема в определении того, что может
потребоваться и сколько памяти это займет, Другой недостаток
этого метода – возможные ошибки в программном обеспечении.
Например браузер Netscape, который в некоторых своих
версиях имел тенденцию к разрастанию. Поэтому – чем больше
резерва, тем больше времени на убийство процесса.
Не на последнем месте стоит и старый, испытанный
метод PHYSICAL_RAM * 2. На старых машинах он работает
лучше всего, хотя на современных, с большим количеством
RAM начал терять свою актуальность.
в целом, довольно сложно сказать, когда начнется
активный своппинг. Даже на машинах с 16MB RAM (и даже
меньше) с установленной NetBSD все работает достаточно
хорошо, пока не будет запущено
17.2.2. Системные сервисы
На серверах хорошая работа сервисов имеет принципиальное
значение. Увеличение быстродействия возможно не только
улучшением аппаратной части, но и своевременным обновлением
программного обеспечения, которое может работать быстрее.
Другим хорошим примером может служить старый вопрос:
«Использовать или нет inetd?». Рассмотрим
pop3. Вызов его через inetd быстро сможет исчерпать ресурсы
системы, что приведет к замедлению работы системы в целом.
Установка демона pop3, не связанного с inetd может помочь
решить ситуацию.
17.2.3. Ядро NetBSD
От ядра системы очень сильно зависит производительность
системы и хотя оптимизация ядра описана несколько ниже по
тексту, вкратце коснемся этой темы и здесь.
Оптимизация ядра NetBSD возможна в следующих направлениях:
- удаление лишних драйверов
- опции конфигурации
- системные установки
17.2.3.1. Удаление лишних драйверов
Удаление лишних драйверов из состава ядра приносит
следущие результаты: быстрее происходит загрузка системы,
занимается меньше памяти, вследствии уменьшения размера
ядра, быстрее происходит отклик ядра.
17.2.3.2. Опции конфигурации
Опции конфигурации позволяют нам задействовать или
отключать некоторые подсистемы, специфичные аппаратные
средства и файловые системы. Отключение неиспользуемых
функций также может дать прирост производительности.
Самый простой пример – сервер FTP, на котором не запущено
ничего более. В этом случае нет необходимости в поддержке
ядром лишних файловых систем, типа NTFS. В случае же
наличия рабочей станции, возможно, такая необходимость
есть, для обеспечения совместного доступа к файлам.
17.2.3.3. Системные установки
System wide settings are controlled by the kernel,
a few examples are filesystem settings, network settings
and core kernel settings such as the maximum number of
processes. Almost all system settings can be at least
looked at or modified via the sysctl facility. Examples
using the sysctl facility are given later on.
17.3. Visual Monitoring Tools
NetBSD ships a variety of performance monitoring tools with
the system. Most of these tools are common on all UNIX systems.
In this section some example usage of the tools is given with
interpretation of the output.
17.3.1. Программа мониторинга процессов top
Эта программа выводит на экран список процессов с
ранжированием их по потребляемым ресурсам. Будучи запущеным
без параметров выглядит так:
load averages: 0.09, 0.12, 0.08 20:23:41
21 processes: 20 sleeping, 1 on processor
CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Memory: 15M Act, 1104K Inact, 208K Wired, 22M Free, 129M Swap free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
13663 root 2 0 1552K 1836K sleep 0:08 0.00% 0.00% httpd
127 root 10 0 129M 4464K sleep 0:01 0.00% 0.00% mount_mfs
22591 root 2 0 388K 1156K sleep 0:01 0.00% 0.00% sshd
108 root 2 0 132K 472K sleep 0:01 0.00% 0.00% syslogd
22597 jrf 28 0 156K 616K onproc 0:00 0.00% 0.00% top
22592 jrf 18 0 828K 1128K sleep 0:00 0.00% 0.00% tcsh
203 root 10 0 220K 424K sleep 0:00 0.00% 0.00% cron
1 root 10 0 312K 192K sleep 0:00 0.00% 0.00% init
205 root 3 0 48K 432K sleep 0:00 0.00% 0.00% getty
206 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
208 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
207 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
13667 nobody 2 0 1660K 1508K sleep 0:00 0.00% 0.00% httpd
9926 root 2 0 336K 588K sleep 0:00 0.00% 0.00% sshd
200 root 2 0 76K 456K sleep 0:00 0.00% 0.00% inetd
182 root 2 0 92K 436K sleep 0:00 0.00% 0.00% portsentry
180 root 2 0 92K 436K sleep 0:00 0.00% 0.00% portsentry
13666 nobody -4 0 1600K 1260K sleep 0:00 0.00% 0.00% httpd
Утилита показывает наиболее «прожорливое» приложение,
зависшие процессы или группы процессов, которые могут
вызывать проблемы. Приведенный выше пример – ненагруженая,
спокойная система. Ниже – совсем другой результат:
load averages: 0.34, 0.16, 0.13 21:13:47
25 processes: 24 sleeping, 1 on processor
CPU states: 0.5% user, 0.0% nice, 9.0% system, 1.0% interrupt, 89.6% idle
Memory: 20M Act, 1712K Inact, 240K Wired, 30M Free, 129M Swap free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
5304 jrf -5 0 56K 336K sleep 0:04 66.07% 19.53% bonnie
5294 root 2 0 412K 1176K sleep 0:02 1.01% 0.93% sshd
108 root 2 0 132K 472K sleep 1:23 0.00% 0.00% syslogd
187 root 2 0 1552K 1824K sleep 0:07 0.00% 0.00% httpd
5288 root 2 0 412K 1176K sleep 0:02 0.00% 0.00% sshd
5302 jrf 28 0 160K 620K onproc 0:00 0.00% 0.00% top
5295 jrf 18 0 828K 1116K sleep 0:00 0.00% 0.00% tcsh
5289 jrf 18 0 828K 1112K sleep 0:00 0.00% 0.00% tcsh
127 root 10 0 129M 8388K sleep 0:00 0.00% 0.00% mount_mfs
204 root 10 0 220K 424K sleep 0:00 0.00% 0.00% cron
1 root 10 0 312K 192K sleep 0:00 0.00% 0.00% init
208 root 3 0 48K 432K sleep 0:00 0.00% 0.00% getty
210 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
209 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
211 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
217 nobody 2 0 1616K 1272K sleep 0:00 0.00% 0.00% httpd
184 root 2 0 336K 580K sleep 0:00 0.00% 0.00% sshd
201 root 2 0 76K 456K sleep 0:00 0.00% 0.00% inetd
Кажется очевидным, какой процесс наиболее грузит систему,
но попробуем выяснить почему. bonnie – это утилита для
определения производительности диска и может записывать
файлы, варьируя пути и размеры. Так что, top указал нам на
самую ресурсопотребляющую программу, но не сказал почему
она так себя ведет.
17.3.1.1. Другие подобные программы
Изучая man команды top(1), можно узнать, что с
помощью этой команды можно менять приоритет и уничтожать
процессы, также можно установить дополнительные
фильтры.
17.3.2. Утилита sysstat
Man sysstat(1) указывает нам, что systat отображает
разнообразную системную статистику и основана на библиотеке
curses. Во время работы экран разделен на две части, верхнее
окно показывает текущее среднее число загрузки, в то время
как нижний экран зависит от директив пользователя.
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |
/0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100
<idle> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
В простейшем случае, эта утилита нам покажет загрузку
некоторого компонента системы, в этом примере, команда
sysstat inet.tcp отобразит:
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |
0 connections initiated 19 total TCP packets sent
0 connections accepted 11 data
0 connections established 0 data (retransmit)
8 ack-only
0 connections dropped 0 window probes
0 in embryonic state 0 window updates
0 on retransmit timeout 0 urgent data only
0 by keepalive 0 control
0 by persist
29 total TCP packets received
11 potential rtt updates 17 in sequence
11 successful rtt updates 0 completely duplicate
9 delayed acks sent 0 with some duplicate data
0 retransmit timeouts 4 out of order
0 persist timeouts 0 duplicate acks
0 keepalive probes 11 acks
0 keepalive timeouts 0 window probes
0 window updates
Теперь более информативно. Счетчики накапливаются,
можно видеть много дополнительной информации. Теперь обратим
внимание на буферный кэш и просмотрим его с помощью systat
bufcache:
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average
There are 1642 buffers using 6568 kBytes of memory.
File System Bufs used % kB in use % Bufsize kB % Util %
/ 877 53 6171 93 6516 99 94
/var/tmp 5 0 17 0 28 0 60
Total: 882 53 6188 94 6544 99
Ну что, снова довольно скучная система, но имеется в
наличии много информации. Раз у нас так все замечательно,
введем в систему ложную нагрузку, чтобы увидеть, как systat
можно использовать в качестве средства диагностики:
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |||
There are 1642 buffers using 6568 kBytes of memory.
File System Bufs used % kB in use % Bufsize kB % Util %
/ 811 49 6422 97 6444 98 99
Total: 811 49 6422 97 6444 98
Во первых, обратите внимание, что средняя нагрузка
возросла, но незначительно, в то время как как использование
файловой системы теперь составляет 99%. В реальной ситуации
поиска неисправностей, это помогло бы выявить поцесс,
делающий интенсивные операции ввода/вывода над файлом или
файловой системе.
17.4. Утилиты мониторинга
В дополнение к экранно-ориентированным утилитам мониторига
в NetBSD присутствуют текстовые утилиты. Эти утилиты присутствуют
во всех UNIX и UNIX-like системах.
17.4.1. fstat
Утилита fstat(1) сообщает о состоянии открытых
файлов в системе и многие администраторы используют ее для
контроля за созданием большого числа файлов или файлов
большого размера пользователями или процессами.
Приведем пример вывода fstat:
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W jrf tcsh 21607 wd / 29772 drwxr-xr-x 512 r jrf tcsh 21607 3* unix stream c057acc0<-> c0553280 jrf tcsh 21607 4* unix stream c0553280 <-> c057acc0 root sshd 21597 wd / 2 drwxr-xr-x 512 r root sshd 21597 0 / 11921 crw-rw-rw- null rw nobody httpd 5032 wd / 2 drwxr-xr-x 512 r nobody httpd 5032 0 / 11921 crw-rw-rw- null r nobody httpd 5032 1 / 11921 crw-rw-rw- null w nobody httpd 5032 2 / 15890 -rw-r--r-- 353533 rw ...
Вывод утилиты достаточно информативен, не требует
больших системных ресурсов и позволяет получить информацию
об используемом файле.
17.4.2. iostat
iostat(8) – утилита, имя которой соответстует
выполняемой задаче. Она сообщает о состоянии подсистем
ввода – вывода в системе. Когда эта утилита выполняется,
пользователь, с некоторой дискретностью, может наблюдать
примерно следующее:
$iostat 5 5tty wd0 cd0 fd0 md0 cpu tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id 0 1 5.13 1 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 0 54 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 0 18 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 0 18 8.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 0 28 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100
Вышеупомянутый вывод – от ненагруженного сервера, поля
представляют различные устройства ввода/вывода – HDD,
CD-ROM, FDD, память и CPU.
Теперь попробуем нагрузить систему. будем использовать
все тот же bonnie++(утилита тестирования дисков) и передавать
tarball netbsd.
$iostat 5 5tty wd0 cd0 fd0 md0 cpu tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id 0 1 5.68 1 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 0 54 61.03 150 8.92 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 1 0 18 4 78 0 26 63.14 157 9.71 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 1 0 20 4 75 0 20 43.58 26 1.12 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 9 2 88 0 28 19.49 82 1.55 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 1 0 7 3 89
Как и следовало ожидать, wd0 очень активен, загрузка
процессора повышается в некоторой зависимости от wd0. Малая
загрузка процессора свидетельствует о том, что сервер ftp
едва используется и это связано с усиленной работой bonnie++.
В данном случае с помощью одного инструмента сложно
локализовать проблему и необходимо проанализировать список
процессов, допустим с помощью утилиты systat bufcache.
17.4.3. ps
Используя ps(1) можно получить много информации
о состоянии системы. Чаще всего команда ps используется
для того, чтобы выделить какой-либо процесс по имени,
группе, владельцу и т.д. Вызванный без опций или параметров,
просто распечатывает информацию о пользователе, его
запустившем.
$psPID TT STAT TIME COMMAND 21560 p0 Is 0:00.04 -tcsh 21564 p0 I+ 0:00.37 ssh jrf.odpn.net 21598 p1 Ss 0:00.12 -tcsh 21673 p1 R+ 0:00.00 ps 21638 p2 Is+ 0:00.06 -tcsh
Не впечатляет… Поля довольно понятны, за исключением
STAT, в котором отображается статус процесса. I – простой,
S бездействует, R – runnable, + означает, что процесс
находится в приоритетном состоянии, и s означает, что
процесс – лидер сеанса. Это все очень просто, например
процесс 21560 – tcsh, простой процесс, следовательно tcsh
является и лидером.
В большинстве случаев эту утилиту используют для поиска
вполне определенных вещей. Для этого существуют дополнительные
опции, например -a видеть все процессы, -ax видеть все
процессы плюс не запущеные с терминала, -aux полная информация
о процессах:
#ps auxUSER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 0 0.0 9.6 0 6260 ?? DLs 16Jul02 0:01.00 (swapper) root 23362 0.0 0.8 144 488 ?? S 12:38PM 0:00.01 ftpd -l root 23328 0.0 0.4 428 280 p1 S 12:34PM 0:00.04 -csh jrf 23312 0.0 1.8 828 1132 p1 Is 12:32PM 0:00.06 -tcsh root 23311 0.0 1.8 388 1156 ?? S 12:32PM 0:01.60 sshd: jrf@ttyp1 jrf 21951 0.0 1.7 244 1124 p0 S+ 4:22PM 0:02.90 ssh jrf.odpn.net jrf 21947 0.0 1.7 828 1128 p0 Is 4:21PM 0:00.04 -tcsh root 21946 0.0 1.8 388 1156 ?? S 4:21PM 0:04.94 sshd: jrf@ttyp0 nobody 5032 0.0 2.0 1616 1300 ?? I 19Jul02 0:00.02 /usr/pkg/sbin/httpd ...
Снова, большинство полей понятно, за исключением VSZ
и RSS. RSS – реальный размер процесса в 1024-байтовых
модулях, а SZ – виртуальный размер. Это все здорово, но
как ps может нам помочь? Хорошо, смотрите на эту измененную
версию того же самого вывода:
#ps auxUSER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 0 0.0 9.6 0 6260 ?? DLs 16Jul02 0:01.00 (swapper) root 23362 0.0 0.8 144 488 ?? S 12:38PM 0:00.01 ftpd -l root 23328 0.0 0.4 428 280 p1 S 12:34PM 0:00.04 -csh jrf 23312 0.0 1.8 828 1132 p1 Is 12:32PM 0:00.06 -tcsh root 23311 0.0 1.8 388 1156 ?? S 12:32PM 0:01.60 sshd: jrf@ttyp1 jrf 21951 0.0 1.7 244 1124 p0 S+ 4:22PM 0:02.90 ssh jrf.odpn.net jrf 21947 0.0 1.7 828 1128 p0 Is 4:21PM 0:00.04 -tcsh root 21946 0.0 1.8 388 1156 ?? S 4:21PM 0:04.94 sshd: jrf@ttyp0 nobody 5032 9.0 2.0 1616 1300 ?? I 19Jul02 0:00.02 /usr/pkg/sbin/httpd ...
Учитывая, что мы считаем этот сервер слабо нагруженным,
PID 5032 сильно нагружает процессор. Анализируя вывод
команды ps, мы можем сделать вывод о процессах, которые
могут испытывать проблемы.
17.4.4. vmstat
Используя vmstat(1) можно получить информацию, касающуюся состояния виртуальной памяти. Мало чем отличаясь
от iostat, vmstat может быть вызван с указанием дискретности.
Следующее – некоторый типовой вывод, используя дискретность
5 и выводя 5 результатов:
#vmstat 5 5procs memory page disks faults cpu r b w avm fre flt re pi po fr sr w0 c0 f0 m0 in sy cs us sy id 0 7 0 17716 33160 2 0 0 0 0 0 1 0 0 0 105 15 4 0 0 100 0 7 0 17724 33156 2 0 0 0 0 0 1 0 0 0 109 6 3 0 0 100 0 7 0 17724 33156 1 0 0 0 0 0 1 0 0 0 105 6 3 0 0 100 0 7 0 17724 33156 1 0 0 0 0 0 0 0 0 0 107 6 3 0 0 100 0 7 0 17724 33156 1 0 0 0 0 0 0 0 0 0 105 6 3 0 0 100
Снова проводим испытания на нагрузку. Условия – те же
самые: bonny++ и файл большого размера.
#vmstat 5 5procs memory page disks faults cpu r b w avm fre flt re pi po fr sr w0 c0 f0 m0 in sy cs us sy id 1 8 0 18880 31968 2 0 0 0 0 0 1 0 0 0 105 15 4 0 0 100 0 8 0 18888 31964 2 0 0 0 0 0 130 0 0 0 1804 5539 1094 31 22 47 1 7 0 18888 31964 1 0 0 0 0 0 130 0 0 0 1802 5500 1060 36 16 49 1 8 0 18888 31964 1 0 0 0 0 0 160 0 0 0 1849 5905 1107 21 22 57 1 7 0 18888 31964 1 0 0 0 0 0 175 0 0 0 1893 6167 1082 1 25 75
Не очень много различий. Обратите внимание, так как
большинство работы производила система ввода/вывода,
фактически виртуальная память не очень расходовалась
вследствии использования для /tmp файловой системы mfs.
Это соотношение может быть нарушено:
#vmstat 5 5procs memory page disks faults cpu r b w avm fre flt re pi po fr sr w0 c0 f0 m0 in sy cs us sy id 0 2 0 99188 500 2 0 0 0 0 0 1 0 0 0 105 16 4 0 0 100 0 2 0111596 436 592 0 587 624 586 1210 624 0 0 0 741 883 1088 0 11 89 0 3 0123976 784 666 0 662 643 683 1326 702 0 0 0 828 993 1237 0 12 88 0 2 0134692 1236 581 0 571 563 595 1158 599 0 0 0 722 863 1066 0 9 90 2 0 0142860 912 433 0 406 403 405 808 429 0 0 0 552 602 768 0 7 93
Довольно страшно выглядит. Такой результат мы получили
используя bonny в системе, где /tmp использует файловую
систему mfs для хранения своих данных. Обратите внимание,
на то, что хоть и виртуальная память была очень нагружена,
процессор был свободен.
17.5. Сетевые утилиты
Иногда, проблемы возникают не в работе какой-то отдельно
взятой машины, а в сети – с кабельной разводкой или сетеыми
устройствами. То, как взаимодествуют другие машины в сети с
нашей NetBSD-машиной, может оказывать сильное влияние на
функционирование сервисов непосредственно на машине или
оказывать влияние на работу пользователей с этой машиной.
Реальный пример – когда в сети становится недступен DNS
сервер. Разрешение имени тогда идет долго и в конце концов
терпят неудачу, и тогда начинаютя обвинения в адрес NetBSD-машины,
раздаются крики пользователей что «сломался Интернет»
и т.д. Независимо от того, что произошло, NetBSD имеет
средства для поиска неисправности как на локальной машине,
так и в сети.
17.5.1. ping
Классическая утилита ping(8) показывает наличие
связи с удаленной машиной. В качестве параметра можно
указать IP адрес целевой машины или ее имя (если настроен
nsswitch.conf). Вот ее вывод:
#ping -c 3 mariePING marie (172.16.14.12): 56 data bytes 64 bytes from 172.16.14.12: icmp_seq=0 ttl=255 time=0.571 ms 64 bytes from 172.16.14.12: icmp_seq=1 ttl=255 time=0.361 ms 64 bytes from 172.16.14.12: icmp_seq=2 ttl=255 time=0.371 ms ----marie PING Statistics---- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.361/0.434/0.571/0.118 ms
Этот вывод покажет нам, что не только есть связь, но
и количество прошедших пакетов, их размер, время прохождения
до удаленной машины. Также указывется соответствие IP
адреса к имени машины. Если не использовать сервер имен,
то можно воспользоваться только IP адресом.
#ping -c 1 172.16.20.5PING ash (172.16.20.5): 56 data bytes 64 bytes from 172.16.20.5: icmp_seq=0 ttl=64 time=0.452 ms ----ash PING Statistics---- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.452/0.452/0.452/0.000 ms
Время доступа к машине весьма субьективный параметр.
Например для получения хорошего времени досупа мы можем
пинговать localhost:
#ping -c 4 localhostPING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.091 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.129 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.120 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.122 ms ----localhost PING Statistics---- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.091/0.115/0.129/0.017 ms
Это время намного меньше, потому что запрос никогда не
покидал машину. Утилита ping может использоваться для
определения состояния сети и измерения времени доступа к
различным хостам сети. Также она может быть использована
для некоторой локализации проблемы в сети – если есть три
машины под управлением NetBSD и с одной из них очень плохая
связь, можно предположить, что на ней что-либо неправильно
настроено.
17.5.2. traceroute
Утилита traceroute(8) служит для определения пути
пакета от одного хоста к другому. Например – путь пакета
между нашим ftp сервером и ftp. NetBSD.org:
#traceroute ftp.NetBSD.orgtraceroute to ftp.NetBSD.org (204.152.184.75), 30 hops max, 40 byte packets 1 208.44.95.1 (208.44.95.1) 1.646 ms 1.492 ms 1.456 ms 2 63.144.65.170 (63.144.65.170) 7.318 ms 3.249 ms 3.854 ms 3 chcg01-edge18.il.inet.qwest.net (65.113.85.229) 35.982 ms 28.667 ms 21.971 ms 4 chcg01-core01.il.inet.qwest.net (205.171.20.1) 22.607 ms 26.242 ms 19.631 ms 5 snva01-core01.ca.inet.qwest.net (205.171.8.50) 78.586 ms 70.585 ms 84.779 ms 6 snva01-core03.ca.inet.qwest.net (205.171.14.122) 69.222 ms 85.739 ms 75.979 ms 7 paix01-brdr02.ca.inet.qwest.net (205.171.205.30) 83.882 ms 67.739 ms 69.937 ms 8 198.32.175.3 (198.32.175.3) 72.782 ms 67.687 ms 73.320 ms 9 so-1-0-0.orpa8.pf.isc.org (192.5.4.231) 78.007 ms 81.860 ms 77.069 ms 10 tun0.orrc5.pf.isc.org (192.5.4.165) 70.808 ms 75.151 ms 81.485 ms 11 ftp.NetBSD.org (204.152.184.75) 69.700 ms 69.528 ms 77.788 ms
В целом, не плохо. Пакет пошел с главного компьютера
на местный маршрутизатор, потом в сеть провайдера, затем
в Интернет и наконец к адресату. Показания traceroute также
являются субьективными, но повышенне время доступа на каком
либо участке сети может указать на проблему сетевого
оборудования. Утилита traceroute мало чем отличается от
утилиты ping по принципу действия. Теперь пример проблем
в сети:
#traceroute www.microsoft.comtraceroute: Warning: www.microsoft.com has multiple addresses; using 207.46.230.220 traceroute to www.microsoft.akadns.net (207.46.230.220), 30 hops max, 40 byte packets 1 208.44.95.1 (208.44.95.1) 2.517 ms 4.922 ms 5.987 ms 2 63.144.65.170 (63.144.65.170) 10.981 ms 3.374 ms 3.249 ms 3 chcg01-edge18.il.inet.qwest.net (65.113.85.229) 37.810 ms 37.505 ms 20.795 ms 4 chcg01-core03.il.inet.qwest.net (205.171.20.21) 36.987 ms 32.320 ms 22.430 ms 5 chcg01-brdr03.il.inet.qwest.net (205.171.20.142) 33.155 ms 32.859 ms 33.462 ms 6 205.171.1.162 (205.171.1.162) 39.265 ms 20.482 ms 26.084 ms 7 sl-bb24-chi-13-0.sprintlink.net (144.232.26.85) 26.681 ms 24.000 ms 28.975 ms 8 sl-bb21-sea-10-0.sprintlink.net (144.232.20.30) 65.329 ms 69.694 ms 76.704 ms 9 sl-bb21-tac-9-1.sprintlink.net (144.232.9.221) 65.659 ms 66.797 ms 74.408 ms 10 144.232.187.194 (144.232.187.194) 104.657 ms 89.958 ms 91.754 ms 11 207.46.154.1 (207.46.154.1) 89.197 ms 84.527 ms 81.629 ms 12 207.46.155.10 (207.46.155.10) 78.090 ms 91.550 ms 89.480 ms 13 * * * .......
В данном случае сервер microsoft не может быть найден
или из-за большого числа переходов, или из-за блокирования
ICMP – пакетов межсетевым экраном, или из-за потерь пакетов
в канале. Если попробовать применить утилиту ping, то она
не будет работать, так что можно селать вывод о том, что
скорее всего заблокированы ICMP – пакеты на сеть
microsoft.
17.5.3. netstat
Другая проблема, которая мжет возникнуть, проблема
маршрутизации. Эти проблемы не всегда появляются вследствие
неправильной настройки. Команды route(8) and
netstat(1) команды могут показать информацю о маршрутах
и сетевых подключениях соответственно.
Команда route может использоваться, чтобы смотреть и
изменять таблицы маршрутизации, в то время как netstat
может отобразит информацию о сетевых подключениях и маршрутах.
Вот вывод команды route:
#route showRouting tables Internet: Destination Gateway Flags default 208.44.95.1 UG loopback 127.0.0.1 UG localhost 127.0.0.1 UH 172.15.13.0 172.16.14.37 UG 172.16.0.0 link#2 U 172.16.14.8 0:80:d3:cc:2c:0 UH 172.16.14.10 link#2 UH marie 0:10:83:f9:6f:2c UH 172.16.14.37 0:5:32:8f:d2:35 UH 172.16.16.15 link#2 UH loghost 8:0:20:a7:f0:75 UH artemus 8:0:20:a8:d:7e UH ash 0:b0:d0:de:49:df UH 208.44.95.0 link#1 U 208.44.95.1 0:4:27:3:94:20 UH 208.44.95.2 0:5:32:8f:d2:34 UH 208.44.95.25 0:c0:4f:10:79:92 UH Internet6: Destination Gateway Flags default localhost UG default localhost UG localhost localhost UH ::127.0.0.0 localhost UG ::224.0.0.0 localhost UG ::255.0.0.0 localhost UG ::ffff:0.0.0.0 localhost UG 2002:: localhost UG 2002:7f00:: localhost UG 2002:e000:: localhost UG 2002:ff00:: localhost UG fe80:: localhost UG fe80::%ex0 link#1 U fe80::%ex1 link#2 U fe80::%lo0 fe80::1%lo0 U fec0:: localhost UG ff01:: localhost U ff02::%ex0 link#1 U ff02::%ex1 link#2 U ff02::%lo0 fe80::1%lo0 U
Значение флагов: U – действует, H – хост, G – шлюз.
О значении других флагов, читайте руководство man.
Теперь вывод netstat с параметрами r(маршруты) и n(не
использовать DNS):
Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 208.44.95.1 UGS 0 330309 1500 ex0 127 127.0.0.1 UGRS 0 0 33228 lo0 127.0.0.1 127.0.0.1 UH 1 1624 33228 lo0 172.15.13/24 172.16.14.37 UGS 0 0 1500 ex1 172.16 link#2 UC 13 0 1500 ex1 ... Internet6: Destination Gateway Flags Refs Use Mtu Interface ::/104 ::1 UGRS 0 0 33228 lo0 => ::/96 ::1 UGRS 0 0
Вышеупомянутый вывод является немного более подробным.
Так, как это может помочь? Хороший пример – когда при
подключении новой сети не прописывается маршрут к ней или
динамический маршрут загружается с ошибкой, в результате
появляется маршрут по умолчанию ведущий в никуда.
17.5.4. tcpdump
Последний по списку, но определенно не по значению,
tcpdump(8), сетевой анализатор, с помощью которого
можно собрать очень много информации. Сейчас мы рассмотрим
вывод утилиты и объясненим некоторые из наиболее полезных
параметров tcpdump.
Следующее – маленький отрывок вывода tcpdump:
#tcpdumptcpdump: listening on ex0 14:07:29.920651 mail.ssh > 208.44.95.231.3551: P 2951836801:2951836845(44) ack 2 476972923 win 17520 <nop,nop,timestamp 1219259 128519450> [tos 0x10] 14:07:29.950594 12.125.61.34 > 208.44.95.16: ESP(spi=2548773187,seq=0x3e8c) (DF) 14:07:29.983117 smtp.somecorp.com.smtp > 208.44.95.30.42828: . ack 420285166 win 16500 (DF) 14:07:29.984406 208.44.95.30.42828 > smtp.somecorp.com.smtp: . 1:1376(1375) ack 0 win 7431 (DF) ...
Учитывая, что сервер в этом примере выполняет почтовые
функции, из вывода, в принципе, все понятно. Утилита является
очень подробной, я предпочитаю первоначально выполнить
tcpdump без аргументов и послать текстовый вывод в файл
для более позднего изучения.
#tcpdump > tcpdump.outtcpdump: listening on ex0
Так, что точно мы ищем? Это могут быть неправильные
пакеты, пакеты с определенного адреса или пределенного
типа, в общем, что угодно. С помощью tcpdump возможна
диагностика большого количества проблем в сети.
17.5.4.1. Использование tcpdump
Вот несколько примеров использования tcpdump:
Наличие двойных IP адресов:
tcpdump -e host ip-addressДля примера:
tcpdump -e host 192.168.0.2Проблемы маршрутизации:
tcpdump icmpЕсть множество инструментальных средств сторонных
производителей, однако, NetBSD поставляется с хорошим
комплектом инструментальных средств для того, чтобы
разыскать проблемы сетевого уровня.
17.6. Аккаунтинг
NetBSD обладает широким набором средств анализа эффективности
для активного контроля, но что делать, если вести анализ
необходимо в течение долгого времени? Конечно, можно послать
вывод различных команд в файл и анализировать их позже с
помощью скриптов командной оболочки или каких либо других
программ. NetBSD по умолчанию предоставляет программисту,
администратору, или просто хоббитянину(у кого хобби такое)
достаточно мощный инструментарий для низкоуровнего
мониторинга.
17.6.1. Accounting
В то время как аккаунтинг используется на уровне
окружения пользователя, профилирование ядра с gprof
обеспечивает явное использование системного вызова.
Успользование утилит аккаунтинга может помочь при
анализе проблем производительности как сети, так и сервисов,
запущеных на машине.
Использование очень простое, необходимо выполнить с
правами пользователя root команду accton(8):
accton filename
И вся информация будет добавляться в конец файла
filename. Команда lastcomm позволит просмотреть этот файл.
По умолчанию будет просмотрен файл
/var/account/acct. Также может быть
указан любой другой файл.
Для остановки аккаунтинга достаточно ввести accton без
параметров.
17.6.2. Чтение информации аккаунтинга
Для чтения накопленной информации используются две
программы:
17.6.2.1. lastcomm
Команда lastcomm показывает последние выполненные
команды, есть возможность выбрать пользователя, чьи
команды будут показаны.
$lastcomm jrflast - jrf ttyp3 0.00 secs Tue Sep 3 14:39 (0:00:00.02) man - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:01:49.03) sh - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:01:49.03) less - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:01:49.03) lastcomm - jrf ttyp3 0.02 secs Tue Sep 3 14:38 (0:00:00.02) stty - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:00:00.02) tset - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:00:01.05) hostname - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:00:00.02) ls - jrf ttyp0 0.00 secs Tue Sep 3 14:36 (0:00:00.00) ...
По умолчанию чтение производится из файла /var/account/acct,
но с помощью опции -f можно переопределить файл.
Очевидно, что использовать lastcomm в системе с
большим количеством пользователей достаточно тяжело. Тут
может помоч утилита sa.
17.6.2.2. sa
Утилита sa(расшифровывается как «печатать статистику
системного аккаунтинга») может использоваться для обработки
информации аккаунтинга. Также применяется для создания
интерактивных отчетов. Вот пример вывода этой команды:
$sa77 18.62re 0.02cp 8avio 0k 3 4.27re 0.01cp 45avio 0k ispell 2 0.68re 0.00cp 33avio 0k mutt 2 1.09re 0.00cp 23avio 0k vi 10 0.61re 0.00cp 7avio 0k ***other 2 0.01re 0.00cp 29avio 0k exim 4 0.00re 0.00cp 8avio 0k lastcomm 2 0.00re 0.00cp 3avio 0k atrun 3 0.03re 0.00cp 1avio 0k cron* 5 0.02re 0.00cp 10avio 0k exim* 10 3.98re 0.00cp 2avio 0k less 11 0.00re 0.00cp 0avio 0k ls 9 3.95re 0.00cp 12avio 0k man 2 0.00re 0.00cp 4avio 0k sa 12 3.97re 0.00cp 1avio 0k sh ...
Слева направо: полное время вызова, реальное время
в минутах, число пользователей, системное время в минутах,
среднее количество операций ввода/вывода, и имя
команды.
Команда sa может также использоваться для создания
файлов отчета или сообщений, основанных на шаблонах.
Например, вот – вывод процессов, отсортированных по
среднему использованию CPU:
$sa -k86 30.81re 0.02cp 8avio 0k 10 0.61re 0.00cp 7avio 0k ***other 2 0.00re 0.00cp 3avio 0k atrun 3 0.03re 0.00cp 1avio 0k cron* 2 0.01re 0.00cp 29avio 0k exim 5 0.02re 0.00cp 10avio 0k exim* 3 4.27re 0.01cp 45avio 0k ispell 4 0.00re 0.00cp 8avio 0k lastcomm 12 8.04re 0.00cp 2avio 0k less 13 0.00re 0.00cp 0avio 0k ls 11 8.01re 0.00cp 12avio 0k man 2 0.68re 0.00cp 33avio 0k mutt 3 0.00re 0.00cp 4avio 0k sa 14 8.03re 0.00cp 1avio 0k sh 2 1.09re 0.00cp 23avio 0k vi
Утилита sa весьма полезна на загруженных системах.
17.6.3. Как исполдьзовать аккаунтинг
Аккаунтинг, при его ведении и регулярном анализе, может
помочь предсказать появление проблем производительности,
после пары месяцев сбора статистики позволит понять, какие
изменения надо сделать, чтобы сохранить или повысить
производительность. Другой хороший пример – использование
сервера сети. Если нагрузка начинает увеличиваться, возможно
стоит предпринять некоторые действия, до того как она станет
реальной проблемой. Так что, вывод однозначный – как
здорово, что в NetBSD есть такие замечательные средства
контроля и все проблемы можно предсказать заранее!
17.7. Профили ядра
Профилирование ядра обычно используется для сравнения
работы системы на различных ядрах или для поиска проблем на
низком уровне. Регистрируются два различных параметра: частота
вызова функции и скорость выполнения каждой функции.
17.7.1. С чего начать
Для начала просмотрите разделы Раздел 17.9, «Оптимизация ядра»
и Глава 28, Компиляция ядра настоящего руководства.
Единственное различие в процедуре установки ядра с
профилированием заключается в необходимости добавить в
config опцию -p. Находясь в каталоге исходных текстов ядра
../compile/<KERNEL_NAME>.PROF,
в то время как GENERIC-ядро в
../compile/GENERIC.PROF.
Ниже следует краткая инструкция по тому, как скомпилировать
ядро с поддержкой профилирования для i386. Считаем, что
исходники доступны в /usr/src и
используется ядро GENERIC, что не всегда соответствует
действительности.
cd
/usr/src/sys/arch/i386/confconfig -p GENERICcd ../compile/GENERIC.PROFmake depend && makecp /netbsd /netbsd.oldcp netbsd /reboot
Как только новое ядро было установлено, и система
перезагрузилась, пришло время включать мониторинг и смотреть
на результаты.
17.7.1.1. Использование kgmon
Запускаем kgmon:
$kgmon -bkgmon: kernel profiling is running.
Затем посылаем данные в файл
gmon.out:
$kgmon -p
Делаем читаемый вывод:
$gprof /netbsd > gprof.out
В текущем каталоге gmon начинает искать файл
gmon.out.
Выполняя только kgmon, вы не можете получить всей
информации, в которой вы нуждаетесь, однако, если Вы
можете получить данные для ядра GENERIC, для последующего
сравнения со своими ядрами.
17.7.2. Расшифровка вывода kgmon
Теперь, когда kgmon может собирать и анализировать
информацию, пришло время посмотреть на работу системы. В
нашем примере ядро GENERIC выполняется с профилированием
в течение приблизительно часа с только системными процессами,
дополнительной нагрузки нет, ошибок нет.
17.7.2.1. Flat Profile
В этом профиле представлен список функций, сколько
раз их вызывали и время их выполнения.
Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ns/call ns/call name 99.77 163.87 163.87 idle 0.03 163.92 0.05 219 228310.50 228354.34 _wdc_ata_bio_start 0.02 163.96 0.04 219 182648.40 391184.96 wdc_ata_bio_intr 0.01 163.98 0.02 3412 5861.66 6463.02 pmap_enter 0.01 164.00 0.02 548 36496.35 36496.35 pmap_zero_page 0.01 164.02 0.02 Xspllower 0.01 164.03 0.01 481968 20.75 20.75 gettick 0.01 164.04 0.01 6695 1493.65 1493.65 VOP_LOCK 0.01 164.05 0.01 3251 3075.98 21013.45 syscall_plain ...
Как и ожидалось, основную часть времени система
простаивала, но некоторые процессы всеже работали,
например, функция vn_lock:
... 0.00 164.14 0.00 6711 0.00 0.00 VOP_UNLOCK 0.00 164.14 0.00 6677 0.00 1493.65 vn_lock 0.00 164.14 0.00 6441 0.00 0.00 genfs_unlock
Это закономерно и ожидаемо.
17.7.2.2. Call Graph Profile
Это расширенная версия конфигурации, представленной
выше, показывающая последующие запросы от перечисленных
функций. Вот пример ее вывода:
Call graph (explanation follows) granularity: each sample hit covers 4 byte(s) for 0.01% of 164.14 seconds index % time self children called name <spontaneous> [1] 99.8 163.87 0.00 idle [1] ----------------------------------------------- <spontaneous> [2] 0.1 0.01 0.08 syscall1 [2] 0.01 0.06 3251/3251 syscall_plain [7] 0.00 0.01 414/1660 trap [9] ----------------------------------------------- 0.00 0.09 219/219 Xintr14 [6] [3] 0.1 0.00 0.09 219 pciide_compat_intr [3] 0.00 0.09 219/219 wdcintr [5] ----------------------------------------------- ...
Все выглядит немного запутанно. Индексный номер
отображается в конце строки, для примера:
... 0.00 0.01 85/85 dofilewrite [68] [72] 0.0 0.00 0.01 85 soo_write [72] 0.00 0.01 85/89 sosend [71] ...
Здесь мы видим, что сначала был вызван dofilewrite,
теперь мы можем смотреть на индексный номер для 64 и
посмотреть то, что случилось там:
... 0.00 0.01 101/103 ffs_full_fsync <cycle 6> [58] [64] 0.0 0.00 0.01 103 bawrite [64] 0.00 0.01 103/105 VOP_BWRITE [60] ...
Таким образом можно установить «визуальный путь»
процесса.
В конце вывода идет индекс имен функций, который
может помочь разобраться с картой индексов.
17.7.3. Использование
В этом примере была изменена область ядра, однозначно
вызывающая проблему, легко нами обнаруживаемую.
Рассмотрим верхнюю часть Flat profile после часа работы
системы не слишком нагруженной пользовательскими задачами:
Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls us/call us/call name 93.97 139.13 139.13 idle 5.87 147.82 8.69 23 377826.09 377842.52 check_exec 0.01 147.84 0.02 243 82.30 82.30 pmap_copy_page 0.01 147.86 0.02 131 152.67 152.67 _wdc_ata_bio_start 0.01 147.88 0.02 131 152.67 271.85 wdc_ata_bio_intr 0.01 147.89 0.01 4428 2.26 2.66 uvn_findpage 0.01 147.90 0.01 4145 2.41 2.41 uvm_pageactivate 0.01 147.91 0.01 2473 4.04 3532.40 syscall_plain 0.01 147.92 0.01 1717 5.82 5.82 i486_copyout 0.01 147.93 0.01 1430 6.99 56.52 uvm_fault 0.01 147.94 0.01 1309 7.64 7.64 pool_get 0.01 147.95 0.01 673 14.86 38.43 genfs_getpages 0.01 147.96 0.01 498 20.08 20.08 pmap_zero_page 0.01 147.97 0.01 219 45.66 46.28 uvm_unmap_remove 0.01 147.98 0.01 111 90.09 90.09 selscan ...
Как видно из результата вывода, имеется большое различие
в работе. Сначительно сократилось время простоя системы.
Основное различие состоит в том, что одна специфическая
функция имеет большое время работы с очень небольшим
количеством запросов. Эта функция – check_exec. Сначала
это может не показаться странным, но после выполнения
большого числа команд расхождение с Flat profile первого
измерения оказаться значительным:
... 0.00 164.14 0.00 37 0.00 62747.49 check_exec ...
Запрос в первом измерении сделан 37 раз и имеет большое
время работы. Очевидно, что работа этой функции неправильна.
Чтобы выявить другие функции, нам необходим график запросов,
вот – первая зависимость check_exec:
... ----------------------------------------------- 0.00 8.69 23/23 syscall_plain [3] [4] 5.9 0.00 8.69 23 sys_execve [4] 8.69 0.00 23/23 check_exec [5] 0.00 0.00 20/20 elf32_copyargs [67] ...
Обратите внимание, как время 8.69, кажется, затрагивает
две предыдущих функции. Возможно, что – то не так с ними,
однако, следующий образец check_exec доказывает иное:
... ----------------------------------------------- 8.69 0.00 23/23 sys_execve [4] [5] 5.9 8.69 0.00 23 check_exec [5] ...
Теперь мы можем видеть, что проблема, наиболее вероятно,
постоянно находится в check_exec.
Конечно, проблемы не всегда настолько просты и очевидны,
вот – простой код, который был вставлен в
check_exec (функция находится в
sys/kern/kern_exec.c):
...
/* A Cheap fault insertion */
for (x = 0; x < 100000000; x++) {
y = x;
}
..
Не очень красиво, но достаточно для показа работы
системы с профилированием.
17.7.4. Резюме:
Профилирование ядра позволяет искать и находить
неисправности в работе системы, поиск которых другими
средствами был бы затруднен. Это не очень тяжело и если вы
можете самостоятельно откомпилировать ядро, то вы можете
использовать систему с профилированием.
17.8. Оптимизация системы
Теперь, когда мы рассмотрели средства контроля и средства
анализа производительности, пришло время изучать методы
влияния на эту самую производительность. В этом разделе мы
рассмотрим средства, которые могут затронуть систему без
перекомпиляции ядра, в следующем разделе рассмотрим уже сборку
нового ядра.
17.8.1. Использование sysctl
Данная утилита используется для просмотра и установки
системных параметров. Так как параметров очень много,
рассмотреть здесь их все не представляется возможным. Но
приведем несколько примеров, например вывод переменной
PATH:
$sysctl user.cs_pathuser.cs_path = /usr/bin:/bin:/usr/sbin:/sbin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/bin:/usr/local/sbin
Довольно просто. Теперь кое-что, что фактически связано
с работой. Посмотрим параметр kern.maxfiles – он определяет
сколько одновременно может быть открыто файлов. На сильно
нагруженных системах, говорят, что могут появиться проблемы
из-за невозможности открыть файл.
$sysctl kern.maxfileskern.maxfiles = 1772
Отлично. Теперь изменим этот параметр. Мы должны владеть
правами пользователя root и использовать параметр -w:
#sysctl -w kern.maxfiles=1972kern.maxfiles: 1772 -> 1972
Помните, что после перезагрузки изменения пропадут.
Есть два пути сохранения изменений – это внести изменения
в ядро и прекомпилировать его или внести изменения в файл
/etc/sysctl.conf:
kern.maxfiles=1972
17.8.2. memfs & softdeps
Работа операционной системы может быть улучшена изменением
сразу нескольких прараметров (также она может быть и
ухудшена). Этими параметрами является использование
файловых систем в памяти и/или soft updates.
17.8.2.1. Использование memfs
Когда использовать memfs, а когда нет – дело сугубо
субьективное. Использование на сервере с большим
количеством пользователей не рекомендуется. Однако на
персональной машине это выглядит довольно симпатично и
каталог obj и некоторые из tmp каталогов можно было бы
перенести в память. Смысл это имеет при соответствующем
размере памяти. С другой стороны, если система только
имеет 16 МБ оперативной памяти и /var/tmp
использует memfs, могут возникнуть большие проблемы с
приложениями, использующих /var/tmp.
В GENERIC – ядре memfs установлен по умолчанию. Чтобы
использовать memfs необходимо сначала определить раздел
файла подкачки. Быстрый взгляд на /etc/fstab
говорит, что им является /dev/wd0b.
mail% cat /etc/fstab /dev/wd0a / ffs rw 1 1 /dev/wd0b none swap sw 0 0 /kern /kern kernfs rw
Эта система – почтовый сервер, так что я хочу
использовать только /tmp с memfs.
Также на этой системе я связал /tmp
с /var/tmp для экономии дискового
пространства.
/dev/wd0b /var/tmp mfs rw 0 0
Удостоверьтесь, что каталоги пусты и никто не использует
их! Потом можно примонтировать этот раздел командой
mount -a или перезагрузить систему.
17.8.2.2. Использование softdeps
Этот механизм позволяет не записывать мета-данные
немедленно на диск, что позволяет оптимизировать операции
ввода/вывода. soft updates не установлена по умолчанию
из-за особенностей лицензирования и потому, что эта
функция все еще считается экспериментальной. Да включения
этой функции обратитесь к главе Раздел 4.9, «Включение FFS soft-dependencies» руководства.
Однако, практика подтверждает, что работает это дело
хорошо. softdeps заставляет систему работать значительно
быстрее, например rm -f в обычном случае требует некоторое
время на выполнение, с softdeps все происходит практически
мгновенно. Много подробной информации о возможностях
softdep может быть найдено на странице
автора.
17.9. Оптимизация ядра
В то время, как многие параметры могут быть выставлены
с использованием sysctl, имеется очень много переменных
используемых для расширенного управления программным обеспечением
(например перенос сервисов из inetd), которые таким образом
настроить нельзя. В этом случае приходится использовать
перекомпиляцию ядра.
17.9.1. Подготовка к компиляции ядра
Сперва получите исходные тексты ядра. Для получения
подробной информации обратитесь к главам Глава 26, Obtaining sources by CVS и Глава 28, Компиляция ядра руководства. Внимание
- этот документ применим к -current ветке ядра. Также
прочитайте статью Трэкинг
-current на официальном сайте.
17.9.2. Конфигурирование ядра
Конфигурирование ядра в NetBSD довольно непростое
занятие. Связано это с много численными зависимостями в
пределах файла конфигурации, единственный плюс – для
конфигурирования можно обойтись выводом dmesg и ascii
редактором. Ядро находится в
src/sys/arch/ARCH/conf, где ARCH -
ваша архитектура. (например, на sparc это было бы под
src/sys/arch/sparc/conf).
Конфигурирование ядра заключается в создании копии
файла конфигурации ядра и удаления(комментирования) всего
лишнего. Сейчас именно тот случай, когда dmesg(8)
становится вашим другом. dmesg(8) покажет все устройства,
обнаруженным ядром во время загрузки. Используя вывод
dmesg(8) могут быть определены опции имеющихся устройств.
Для автоматизации действий может быть использован пакет
«adjustkernel».
17.9.2.1. Пример конфигурации
В данном примере мы конфигурируем ядро для ftp сервера,
убирая все лишние драйвера и сервисы – все, что может
замедлить работу. Копируем файл
/usr/src/sys/arch/i386/conf/GENERIC
в файл FTP и приступаем к его редактированию.
В начале файла есть набор опций, включая maxuser,
которые мы оставим в покое, однако на много пользовательских
системах этот параметр можно и поправить. Далее идет тип
процессора. Руководствуясь выводом dmesg определяем:
cpu0: Intel Pentium II/Celeron (Deschutes) (686-class), 400.93 MHz
Нам требуется только опция I686_CPU. В следущей секции
тоже все оставляем в покое за исключением PIC_DELAY – ее
рекомендуется выставить, если это не старая машина (не
ниже 686).
Дальше вниз до самых compat опций изменять ничего не
надо. Так как эта машина выполняет только функции сервера
FTP, все compat опции были выключены.
Следущая секция содержит в себе строки поддержки
файловых систем.
# File systems file-system FFS # UFS file-system LFS # log-structured file system file-system MFS # memory file system file-system CD9660 # ISO 9660 + Rock Ridge file system file-system FDESC # /dev/fd file-system KERNFS # /kern file-system NULLFS # loopback file system file-system PROCFS # /proc file-system UMAPFS # NULLFS + uid and gid remapping ... options SOFTDEP # FFS soft updates support. ...
Сетевые опции:
options INET # IP + ICMP + TCP + UDP options INET6 # IPV6 options IPFILTER_LOG # ipmon(8) log support
Опцию IPFILTER_LOG мы оставим, та как планируем
использовать ipf.
Следующий раздел – подробные отладочные сообщения
для различных подсистем, так как эта машина уже работала
и не имела никаких проблем, все они прокомментированы.
17.9.2.2. Драйверы устройств
Элементы конфигурации указанные выше – дело простое
и обьяснимое. Драйверы устройство – совсем наоборот.
Вот маленький пример с CD-ROM.
... cd0 at atapibus0 drive 0: <CD-540E, , 1.0A> type 5 cdrom removable cd0: 32-bit data port cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 pciide0: secondary channel interrupting at irq 15 cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 (using DMA data transfer ...
Теперь пришло время разыскивать этот раздел в файле
конфигурации. Обратите внимание, что CD находится на
atapibus и требует поддержки pciide. Раздел, который
представляет интерес в этом случае – раздел «IDE and
related devices». Также рядом лежат разделы ISA, PCMCIA
и т.д. На этой машине нет PCMCIA устройств, поэтому всю
секцию комментируем.
Всекции IDE ищем строку:
... wd* at atabus? drive ? flags 0x0000 ... atapibus* at atapi? ...
Хорошо, довольно очевидно, что те строки должны быть
сохранены. Затем:
... # ATAPI devices # flags have the same meaning as for IDE drives. cd* at atapibus? drive ? flags 0x0000 # ATAPI CD-ROM drives sd* at atapibus? drive ? flags 0x0000 # ATAPI disk drives st* at atapibus? drive ? flags 0x0000 # ATAPI tape drives uk* at atapibus? drive ? flags 0x0000 # ATAPI unknown ...
Единственный тип устройства, который был в выводе
dmesg(8) – это CD, остальное может быть
закомментировано.
Следующий пример чуть сложнее – сетевые интерфейсы.
В этой машине их два.
... ex0 at pci0 dev 17 function 0: 3Com 3c905B-TX 10/100 Ethernet (rev. 0x64) ex0: interrupting at irq 10 ex0: MAC address 00:50:04:83:ff:b7 UI 0x001018 model 0x0012 rev 0 at ex0 phy 24 not configured ex1 at pci0 dev 19 function 0: 3Com 3c905B-TX 10/100 Ethernet (rev. 0x30) ex1: interrupting at irq 11 ex1: MAC address 00:50:da:63:91:2e exphy0 at ex1 phy 24: 3Com internal media interface exphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ...
На первый взгляд может показаться, что у нас три
сетевые карты, но присмотревшись повнимательнее, мы
обнаружим:
exphy0 at ex1 phy 24: 3Com internal media interface
Мы имеем только две сетевые карты, поэтому, как и в
случае с CDROM, просто удаляем все, что мы не увидели в
выводе dmesg. Переходим в начало секции сетевых
интерфейсов:
... # Network Interfaces # PCI network interfaces an* at pci? dev ? function ? # Aironet PC4500/PC4800 (802.11) bge* at pci? dev ? function ? # Broadcom 570x gigabit Ethernet en* at pci? dev ? function ? # ENI/Adaptec ATM ep* at pci? dev ? function ? # 3Com 3c59x epic* at pci? dev ? function ? # SMC EPIC/100 Ethernet esh* at pci? dev ? function ? # Essential HIPPI card ex* at pci? dev ? function ? # 3Com 90x[BC] ...
У нас есть устройство ex. Все остальное в разделе
PCI может быть заккоментировано, кроме строки:
exphy* at mii? phy ? # 3Com internal PHYs
Которая может быть как закомментирована, так и
сохранена.
17.9.2.3. Multi Pass
Когда я настраиваю ядро, я люблю сделать это дистанционно
в сеансе X, в одном окне вывод dmesg, в другом файл
конфигурации. Может иногда потребоваться выполнить
несколько проходов, чтобы восстановить черезчур урезанное
ядро, так как легко случайно удалить зависимости.
17.9.3. Building the New Kernel
Теперь пришло время компилировать и устанавливать ядро.
В каталоге conf нашего ftp сервера выполним следующую
команду:
$config FTP
Когда на экране появится предупреждение не забыть
сделать make depend:
$cd ../compile/FTP$make depend && make
Когда это сделано, сохраняем старое ядро и ставим
новое:
#cp /netbsd /netbsd.orig#cp netbsd /
Теперь перезагрузка. Если ядро не загружается, то
остановите процесс загрузки и введите boot для загрузки предыдущего ядра.
netbsd.orig
