Глава 17. Точная настройка NetBSD

Глава 17. Точная настройка NetBSD

Русский перевод: Михаил Сгибнев

17.1. Введение

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
	

На самом деле, здесь все зависит от размера и интенсивности использования баз данных, для примера, если база данных распределенная, то форма будет не верна.

Следующий подход к расчету размера раздела подкачки хотя и выглядит несколько странным, но не лишен определенного смысла. Суть его в том, чтобы по возможности при расчетах опираться на объем памяти, который необходим для работы системы. Например, как-нибудь так:

  1. Посчитайте общее количество необходимой памяти при одновременном запуске всего, что вам может потребоваться. Это базы данных, web серверы и так далее.

  2. Добавьте несколько мегабайт про запас.

  3. Вычтите значение RAM из результата.

Если получившийся остаток превышает размер RAM в три и более раза, то рассмотрите возможность увеличения RAM. Конечно, есть проблема в определении того, что может потребоваться и сколько памяти это займет, Другой недостаток этого метода - возможные ошибки в программном обеспечении. Например браузер Netscape, который в некоторых своих версиях имел тенденцию к разрастанию. Поэтому - чем больше резерва, тем больше времени на убийство процесса.

Не на последнем месте стоит и старый, испытанный метод PHYSICAL_RAM * 2. На старых машинах он работает лучше всего, хотя на современных, с большим количеством RAM начал терять свою актуальность.

в целом, довольно сложно сказать, когда начнется активный своппинг. Даже на машинах с 16MB RAM (и даже меньше) с установленной NetBSD все работает достаточно хорошо, пока не будет запущено

17.2.2. Системные сервисы

На серверах хорошая работа сервисов имеет принципиальное значение. Увеличение быстродействия возможно не только улучшением аппаратной части, но и своевременным обновлением программного обеспечения, которое может работать быстрее.

Другим хорошим примером может служить старый вопрос: «Использовать или нет inetd?». Рассмотрим pop3. Вызов его через inetd быстро сможет исчерпать ресурсы системы, что приведет к замедлению работы системы в целом. Установка демона pop3, не связанного с inetd может помочь решить ситуацию.

17.2.3. Ядро NetBSD

От ядра системы очень сильно зависит производительность системы и хотя оптимизация ядра описана несколько ниже по тексту, вкратце коснемся этой темы и здесь.

Оптимизация ядра NetBSD возможна в следующих направлениях:

  1. удаление лишних драйверов

  2. опции конфигурации

  3. системные установки

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

$ ps
 PID 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 aux
USER  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 aux
USER  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 5
 procs 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 5
 procs 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 5
 procs 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 marie
PING 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.5
PING 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 localhost
PING 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.org
traceroute 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.com
traceroute: 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 show
Routing 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:

# tcpdump
tcpdump: 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.out
tcpdump: 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 jrf
last  -  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(расшифровывается как "печатать статистику системного аккаунтинга") может использоваться для обработки информации аккаунтинга. Также применяется для создания интерактивных отчетов. Вот пример вывода этой команды:

$ sa
  77  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 -k
  86  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, что не всегда соответствует действительности.

  1. cd /usr/src/sys/arch/i386/conf

  2. config -p GENERIC

  3. cd ../compile/GENERIC.PROF

  4. make depend && make

  5. cp /netbsd /netbsd.old

  6. cp netbsd /

  7. reboot

Как только новое ядро было установлено, и система перезагрузилась, пришло время включать мониторинг и смотреть на результаты.

17.7.1.1. Использование kgmon

Запускаем kgmon:

$ kgmon -b
kgmon: 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_path
user.cs_path = /usr/bin:/bin:/usr/sbin:/sbin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/bin:/usr/local/sbin

Довольно просто. Теперь кое-что, что фактически связано с работой. Посмотрим параметр kern.maxfiles - он определяет сколько одновременно может быть открыто файлов. На сильно нагруженных системах, говорят, что могут появиться проблемы из-за невозможности открыть файл.

$ sysctl kern.maxfiles
kern.maxfiles = 1772

Отлично. Теперь изменим этот параметр. Мы должны владеть правами пользователя root и использовать параметр -w:

# sysctl -w kern.maxfiles=1972
kern.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 для загрузки предыдущего ядра.

Обновлено: 16.03.2015