Ключевые слова:bsd, netbsd, tune, optimization, network, ethernet, kernel, sysctl, (найти похожие документы)
From: Михаил Сгибнев <mixa(@).dreamcatcher.ru>
Newsgroups: email
Date: Mon, 17 Feb 2004 14:31:37 +0000 (UTC)
Subject: Тюнинг и диагностика проблем в NetBSD
Оригинал: http://www.dreamcatcher.ru/docs/netbsd_tun.html
Настройка NetBSD
Содержание:
* Утилиты визуального мониторинга
* Утилиты мониторинга
* Сетевые утилиты
* Аккаунтинг
* Профили ядра
* Тюнинг системы
* Тюнинг ядра
Утилиты визуального мониторинга
NetBSD предоставляет различные визуальные средства контроля за
состоянием системы. Они стандартны практически для всех UNIX. В этом
разделе приводится пример использования таких средств.
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 указал нам на самую ресурсоемкую программу, но
не сказал почему она так себя ведет.
Изучая man команды top(1), можно узнать, что с помощью этой команды
можно менять приоритет и уничтожать процессы, также можно установить
дополнительные фильтры.
systat:
-------
Man systat (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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Basically a lot of dead time there, so now have a look with some arguments prov
ided, in this case, systat inet.tcp which looks like this:
/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 94
Ну, что, довольно скучно, но много информации имеется в наличии. Раз у
нас так все замечательно, введем в систему ложную нагрузку, чтобы
увидеть, как systat можно использовать в качестве средства
диагностики:
Как и с top, будем использовать bonnie++ для того, чтобы нагрузить
систему ввода/вывода и немного центральный процессор. Снова будем
смотреть буферный кэш, чтобы увидеть отличия:
/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
Во первых, одратите внимание, что средняя нагрузка возросла, но
незначительно, в то время как как использование файловой системы -
99%. В реальной ситуации поиска неисправностей, это помогло бы выявить
поцесс, делающий интенсивные операции ввода/вывода над файлом или
файловой системе.
Утилиты мониторинга
В дополнение к экранно-ориентированным утилитам мониторига в NetBSD
присутствуют текстовые утилиты. Эти утилиты присутствуют во всех
UNIX-системах.
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
...
iostat:
-------
Iostat(8) - утилита, имя которой соответстует выполняемой задаче
сообщает о состоянии подсистем ввода - вывода на системе. Выглядит это
так:
ftp% 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.
ftp% 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.
ps:
---
Используя ps(1) можно получить много информации о состоянии системы.
Чаще всего команда ps используется для того, чтобы выделить какой-либо
процесс по имени, группе, владельцу и т.д. Вызванный без опций или
параметров, просто распечатывает информацию о пользователе, его
запустившем.
ftp% 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 полная информация о процессах
ftp# 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 может нам помочь? Хорошо, смотрите
на эту измененную версию того же самого вывода:
ftp# 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, мы можем
сделать вывод о процессах, которые могут испытывать проблемы.
vmstat:
-------
Используя vmstat(8) можно получить информацию, касающуюся состояния
виртуальной памяти. Мало чем отличаясь от iostat, vmstat может быть
вызван со счетом и интервалом. Следующее - некоторый типовой вывод,
используя 5 5 как iostat пример:
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 syid
0 7 0 17716 33160 2 0 0 0 0 0 1 0 0 0 105 15 4 0 0100
0 7 0 17724 33156 2 0 0 0 0 0 1 0 0 0 109 6 3 0 0100
0 7 0 17724 33156 1 0 0 0 0 0 1 0 0 0 105 6 3 0 0100
0 7 0 17724 33156 1 0 0 0 0 0 0 0 0 0 107 6 3 0 0100
0 7 0 17724 33156 1 0 0 0 0 0 0 0 0 0 105 6 3 0 0100
Снова проводим испытания на нагрузку. Условия - те же самые: 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 syid
1 8 0 18880 31968 2 0 0 0 0 0 1 0 0 0 105 15 4 0 01 00
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
Не очень много различий. Обратите внимание, так как большинство работы
производила система ввода/вывода, фактически память не очень
использовалась. Так как эта система использует mfs для /tmp. Это
соотношение может быть нарушено:
ftp# 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++ в системе, где mfs использует /tmp Для хранения своих данных.
Обратите внимание, на то, что хоть и виртуальная память была очень
нагружена, процессор был свободен.
Сетевые утилиты
Иногда, проблемы возникают не в работе какой-то отдельно взятой
машины, а в сети - с кабельной разводкой или сетеыми устройствами. То,
как взаимодествуют другие машины в сети с нашей NetBSD-машиной, может
оказывать сильное влияние на функционирование сервисов непосредственно
на машине или оказывать влияние на работу пользователей с этой
машиной. Реальный пример - когда в сети становится недступен DNS
сервер. Разрешение имени тогда идет долго и в конце концов терпят
неудачу, и тогда начинаютя обвинения в адрес NetBSD-машины, разоются
вопли что "сломался Интернет" и т.д. Независимо от ого, что произошло,
NetBSD имеет средства для поиска неисправности как на локальной
машине, так и в сети.
ping:
-----
Классическая утилита ping(8) показывает наличие связи с удаленной
машиной. Может работать как с IP адресом, также может вывести имя
машины (если настроен nsswitch.conf). Вот ее вывод:
ftp# 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
адресом.
ftp# 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:
ftp# 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 и с одной из них очень плохая
связь, можно предположить, что на ней что-либо неправильно настроено.
traceroute:
-----------
Утилита traceroute(8) служит для определения пути пакета от одного
хоста к другому. Например - путь пакета между нашим ftp сервером и
ftp. NetBSD.org:
ftp# 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 по принципу действия.
Теперь пример проблем в сети:
ftp# 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.
route & netstat:
----------------
Другая проблема. когорая мжет возникнуть - это проблема маршрутизации.
Эти проблемы - не всегда прблемы настройки. route(8) и netstat(1)
команды могут показать информацю о маршрутах и сетевых подключениях
соответственно.
Команда route может использоваться, чтобы смотреть и изменять таблицы
маршрутизации, в то время как netstat может отобразит информацию о
сетевых подключениях и маршрутах.
Вот вывод команды route:
ftp# 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
Вышеупомянутый вывод является немного более подробным. Так, как это
может помочь? Хороший пример - когда при подключении новой сети не
прописывается маршрут к ней или динамический маршрут загружается с
ошибкой, или появляется маршрут по умолчянию ведущий в никуда.
tcpdump:
--------
Последний, и определенно не в последнюю очередь - tcpdump (8), сетевой
сниффер, который может отыскать много информации. Сейчас мы рассмотрим
вывод утилиты и объясненим некоторые из наиболее полезных параметров
tcpdump.
Следующее - маленький отрывок вывода tcpdump:
mail# tcpdump
tcpdump: listening on ex0
14:07:29.920651 mail.ssh > 208.44.95.231.3551: P 2951836801:2951836845(44) ack2476972923 win 17520 [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 win16500 (DF)
14:07:29.984406 208.44.95.30.42828 > smtp.somecorp.com.smtp: . 1:1376(1375) ack 0 win 7431 (DF)
...
Учитывая, что сервер в примере выполняет почтовые функции из вывода в
принципе, все понятно. Утилита является очень подробной, я предпочитаю
первоначально выполнить tcpdump без вариантов и послать текстовый
вывод в файл для более позднего изучения.
mail# tcpdump > tcpdump.out
tcpdump: listening on ex0
Так, что точно мы ищем? Это могут быть неправильные пакеты, пакеты с
опроделенного адреса или пределенного типа, в общем, что угодно.
Использование tcpdump с параметрами:
Наличие двойных IP адресов:
tcpdump -e host ip-address
Проблемы роутинга:
tcpdump icmp
Есть множество инструментальных средств сторонных производителей,
однако, NetBSD поставляется с хорошим комплектом инструментальных
средств для того, чтобы разыскать проблемы сетевого уровня.
Аккаунтинг
NetBSD обладает большим количеством средств анализа эффективности для
активного контроля, но что делать. если вести анализ необходимо в
течение долгого времени? Конечно. можно послать вывод различных команд
в файл и анализировать их позже с помощью скриптов оболочки или каких
либо других программ. NetBSD по умолчанию предоставляет программисту,
администратору, или просто хоббитянину(у кого хобби такое) достаточно
мощный инструментарий для низкоуровнего мониторинга.
Аккаунтинг:
В то время как учет используется в окружении пользователя уровень,
профилирование ядра с gprof обеспечивает явное использование
системного вызова.
Успользование утилит аккаунтинга может помочь при анализе проблем
производительности как сети, так и сервисов, запущеных на машине.
Использование:
Использование очень простое, необходимо выполнить с правами
пользователя root команду accton(8):
accton filename
И все информация будет добавляться в конец файла filename. Команда
lastcomm позволит просмотреть этот файл. по умолчанию будет просмотрен
файл /var/account/acct. Также может быть указан любой другой файл.
для остановки аккаунтинга достаточно ввести accton без параметров.
Чтение накопленной информации:
Для чтения накопленной информации используются две программы:
* lastcomm(1)
* sa(8)
lastcomm:
---------
Команда lastcomm показывает последние выполненные команды, можно
выбрать пользователя, чьи команды будут показаны.
Вот примерный вывод этой команды:
mail% 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.
sa:
---
sa (расшифровывается как "печатать статистику системного
аккаунтинга")(ни фига себе, сократили...) может использоваться для
обработки информации аккаунтинга. Может использоваться для создания
интерактивных отчетов.
Вот вывод этой команды:
mail% 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:
mail% 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
Как вести учет:
Ведение учета, при его ведении и регулярном анализе, может помочь
предсказать появление проблем производительности, после пары месяцев
работы позволит понять, какие изменения надо сделать, чтобы сохранить
или повысить производительность. Другой хороший пример - использование
сервера сети. Если нагрузка начинает увеличиваться, возможно стоит
предпринять некоторые действия, до того как она станет реальной
проблемой. Так что, вывод однозначный - как здорово, что в NetBSD есть
такие замечательные средства контроля и все проблемы можно предсказать
заранее!
Профили ядра
------------
Как указано в Profiling HOWTO два набора данных о поведении кода
регистрируются независимо: функциональная частота запроса и время,
затраченное на выполнение каждой функции. Профилирование ядра обычно
используется, когда цель состоит в том, чтобы сравнить влияние новых
изменений в ядре к предыдущему на производительность или для отыскания
проблем производительности.
Начало:
Для начала просмотрите раздел [13]Тюнинг ядра и Kernel FAQ at NetBSD.
Единственное различие в процедуре установки ядра с профилированием -
добавить в config опцию -p. Находясь в каталоге исходных текстов ядра
../compile/.PROF, в то время как GENERIC-ядро в
../compile/GENERIC.PROF.
Нижеследующие - краткая инструкция по тому как скомпилировать ядро с
поддержкой профилирования для i386. Считаем, что исходники доступны в
/usr/src и используется ядро GENERIC. что , конечно, не всегда
соответствует действительности.
cd /usr/src/sys/arch/i386/conf config -p GENERIC cd
../compile/GENERIC.PROF make depend && make cp /netbsd /netbsd.old
cp netbsd / reboot ...
Как только новое ядро было установлено, и система перезагрузилась,
пришло время включать контроль и смотреть на результаты.
Использование kgmon:
Запустить kgmon:
quark# kgmon -b
kgmon: kernel profiling is running.
Остановить kgmon:
quark# kgmon -h
kgmon: kernel profiling is off.
Затем, пошлите данные в файл gmon.out:
quark# kgmon -p
Прочитаем вывод:
quark# gprof /netbsd > gprof.out
С тех пор gmon ищет gmon.out и должен его найти в текущем рабочем
каталоге.
Выполняя только kgmon, Вы не можете получить информацию, в которой Вы
нуждаетесь, однако, если Вы можете получить данные для GENERIC - ядра,
для последующего сравнения со своими ядрами.
Обратите внимание, это - вообще хорошая идея, чтобы нагрузить систему,
и зная как работает GENERIC ядро, сравнить данные с новым ядром.
Интерпретация вывода kgmon:
Теперь, когда kgmon может собирать и анализировать информацию, пришло
время посмотреть на это все безобразие. В нашем
образцово-показательном примере GENERIC-ядро выполняется с
профилированием в течение приблизительно часа с только системными
процессами, дополнительной нагрузки нет, ошибок нет.
Flat Profile:
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
Это закономерно и ожидаемо.
Call Graph Profile:
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
[1] 99.8 163.87 0.00 idle [1]
-----------------------------------------------
[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 [58]
[64] 0.0 0.00 0.01 103 bawrite [64]
0.00 0.01 103/105 VOP_BWRITE [60]
...
И так далее.
В конце вывода идет индекс имен функций, который может помочь
разобраться с картой индексов.
Putting it to Use:
В этом примере, была изменена область ядра, однозначно вызывающая
проблему, которая будет очевидна.
Вот - верхняя часть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;
}
..
Не очень красиво, но достаточно для показа работы системы с
профилированием.
Резюме:
Профилирование ядра позволяет искать и находить неисправности в работе
системы, поиск которых другими средствами был бы затруднен. Это не
очень тяжело и если вы можете откомпилировать ядро, то вы можете
использовать систему с профилированием.
Тюнинг системы
Теперь, когда мы рассмотрели средства контроля и средства анализа
производительности, пришло время изучать методы влияния на эту самую
производительность. В этом разделе мы рассмотрим средства, которые
могут затронуть систему без перекомпиляции ядра, в следующем разделе
рассмотрим уже сборку нового ядра.
sysctl:
-------
Данная утилита используется для просмотра и установки системных
параметров. Так как параметров очень много, рассмотреть здесь их все
не представляется возможным. Но приведем несколько примеров:
Просмотр переменной PATH:
mail% sysctl user.cs_path
user.cs_path = /usr/bin:/bin:/usr/sbin:/sbin:/usr/pkg/bin:/usr/pkg/sbin:/usr/lo
cal/bin:/usr/local/sbin
Довольно просто. Теперь кое-что, что фактически связано с работой.
Посмотрим параметр kern.maxfiles - он определяет сколько одновременно
может быть открыто файлов. На сильно нагруженных системах, говорят,
что могут появиться проблемы из-за невозможности открыть файл.
mail% sysctl kern.maxfiles
kern.maxfiles = 1772
Отлично. Теперь изменим этот параметр. Мы должны владеть правами
пользователя root и использовать параметр -w:
mail# sysctl -w kern.maxfiles=1972
kern.maxfiles: 1772 -> 1972
Помните, что после перезагрузки изменения пропадут. Есть два пути
сохранения изменений - это внести изменения в ядро и прекомпилировать
его или внести изменения в файл /etc/sysctl.conf:
kern.maxfiles=1972
UBC и sysctl:
Из опыта можно судить, что наибольшей настройке подвергается UBC
(обьединенный буферный кэш). Разработчики сделали некоторые
превосходные рекомендации чтобы настроить систему UBC, их стоит
посмотреть этот раздел для примера. http://mail-index.netbsd.org/tech-perform/2002/08/03/0000.html
Хотя мы и увеличили maxfiles, есть еще очень много параметров, которые
могут помочь сделать сделать систему производительнее. Так как теперь
может быть открыто больше файлов, надо подумать о том, как повысить
эффективность кэширования. На данной машине есть довольно большое
количество RAM (256 МБ), которые полностью не используются, так как на
этой машине открываются маленькие файлы, изредка что-то компилируется
и все. Это означает, что буферный кэш мог вероятно быть расширен,
таким образом делая работу лучше, так как больше данных будет будет
сохранено в памяти вместо повторного считывания с диска. Так, что
является параметром? Это - kern.maxvnodes и в случае этой машины,
использовались 38 МБ, которые дали довольно приличное увеличение
работы. Вообще, виделось, что kern.maxvnodes работает хорошо, когда
размер установлен в между 1/6 к 1/4 количества оперативной памяти
Вы можете также улучшить работу, настраиваясь vm.anonmax, который
устанавливает количество физической памяти, которая может быть
предоставлена для данных прикладной программы. Саймон Бердж написал
очень хороший пост на эту тему, рекомендуется его почитать.
http://mail-index.netbsd.org/tech-kern/2002/11/27/0005.html
Для самых ленивых, sysctl -w vm.anonmax=95 на системе pc532 с 8MB of RAM
работало очень хорошо, возможно также будет и у вас.(Пр.п. - это что
за система такая?)
memfs & softdeps:
Работа операционной системы может быть улучшена изменением сразу
нескольких прараметров (также она может быть и ухудшена). Два
специфических случая - это использование файловых систем в памяти
и/или soft updates.
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
Удостоверьтесь, что каталоги пусты и никто не использует их! Потом
можно примонтировать этот раздел или перезагрузить систему.
softdeps: soft updates не установлена по умолчанию из-за особенностей
лицензирования и потому, что эта функция все еще считается
экспериментальной. Однако, практика подтверждает, что работает это
дело хорошо. softdeps заставляет систему работать значительно быстрее,
например rm -f в обычном случае требует некоторое время на выполнение,
с softdeps все происходит практически мгновенно. Много подробной
информации о softdep возможностях может быть найдено на странице
автора (http://www.mckusick.com/softdep/index.html).
Есть также раздел NetBSD Documentation about soft updates.
http://www.netbsd.org/Documentation/misc/#softdeps
Чтобы получить выполнение softdeps, только изменяют вход в /etc/fstab
для файловой системы, на которой это будет использоваться, и
перезагружаются. Для использования Soft Updates на /usr, этот файл:
/dev/wd0a / ffs rw 1 1
/dev/wd0b none swap sw 0 0
/dev/wd0e /usr ffs rw 1 2
/kern /kern kernfs rw
заменяют на этот:
/dev/wd0a / ffs rw 1 1
/dev/wd0b none swap sw 0 0
/dev/wd0e /usr ffs rw,softdep 1 2
/kern /kern kernfs rw
Тюнинг ядра
В то время, как многие параметры могут быть выставлены с
использованием sysctl, очень много переменных используемых для
расширенного управления программным обеспечением (например перенос
сервисов из inetd), которые таким образом настроить нельзя. Тогда
используем перекомпиляцию ядра.
Подготовка:
Сперва получите исходники ядра. Внимание - этот документ применим к
-current ветке ядра. Также прочитайте информацию на [18]официальном
сайте, все что набисано там, написано и здесь.
Устанавливаем переменную CVSROOT. Для csh или tcsh это делается так:
setenv :pserver:[email protected]:/cvsroot
Для sh, ksh и иже с ними:
CVSROOT=:pserver:[email protected]:/cvsroot; export CVSROOT
Теперь, когда переменные установлены проверим исходники:
cvs checkout -rnetbsd-1-6 src/sys
Это положит исходники в src/sys относительно каталога, в котором
пользователь находится.
Для версии 1.5 строка будет такая:
cvs checkout -rnetbsd-1-5 src/sys
для -current версии:
cvs checkout src/sys
Конфигурирование:
Конфигурирование ядра в NetBSD может просто достать... Связано это с
много численными зависимостями в пределах файла конфигурации,
единственный плюс - для конфигурирования можно обойтись выводом dmesg
и ascii редактор. Ядро находится в ~src/sys/arch/ARCH/conf, где ARCH -
ваша архитектура. (например, на sparc это было бы под
~src/sys/arch/sparc/conf) Это - то, где dmesg становится вашим другом.
dmesg покажет все устройства, обнаруженным ядром во время загрузки.
Используя вывод dmesg могут быть определены опции имеющихся устройств.
Пример:
В данном примере мы конфигурируем ядро для ftp сервера, убирая все
лишние драйвера и сервисы - все, что может замедлить работу. Копируем
/usr/src/sys/arch/i386/conf the GENERIC в файл FTP и приступаем к его
редактированию.
В начале файла есть набор опций, включая maxuser, которые мы оставим в
покое, однако на много пользовательских системах этот параметр можно и
поправить. Далее идет тип процессора. Руководствуясь выводом dmesg
определяем:
cpu0: Intel Pentium II/Celeron (Deschutes) (686-class), 400.93 MHz
Нам требуется только опция I686_CPU. В следущей секции тоже все
оставляем в покое за исключением DUMMY_NOPS - ее рекомендуется
выставить, если это не старая машина (не ниже 686). Дальше вниз до
самых compat опций изменять ничего не надо. Потому что эта машина -
строго сервер FTP, все compat опции были выключены кроме тех
необходимых для работы, в данном случае, COMPAT_16
Раз это 1.6 машина, конечно COMPAT_16 должна быть включена. Также
должно присутствовать:
# 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.
Следующий раздел - подробные сообщения для различных подсистем, так
как эта машина уже работала и не имела никаких проблем, все они
прокомментированы.
Драйверы устройств:
Элементы конфигурации указанные выше - дело простое и обьяснимое.
Драйверы устройство - совсем наоборот. Вот маленький пример с CD-ROM.
Вывод dmesg:
...
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. Также рядом лежат разделы ISA, PCMCIA и т.д. На этой машине нет
PCMCIA - устройств, поэтому всю секцию комментируем.
В начале IDE раздела - следующее:
...
wd* at wdc? channel ? drive ? flags 0x0000
wd* at pciide? channel ? drive ? flags 0x0000
# ATAPI bus support
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 - это 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
Действия здесь мало чем отличаются от предыдуших - просто комментируем
то, чего у нас нет.
Начало секции:
...
# 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
Может быть как закомментирована, так и сохранена.
Отступление от темы:
Когда я настраиваю ядро, я люблю сделать это дистанционно в сеансе
Windows X, в одном окне вывод dmesg, в другом файл конфигурации. Может
иногда требоваться несколько проходов, чтобы восстановить очень
урезанное ядро, так как легко случайно удалить зависимости.
Сборка ядра:
Теперь пришло время компилировать и устанавливать ядро.
config FTP
Когда на экране появится предупреждение не забыть сделать make depend:
cd ../compile/FTP
make depend && make
Когда это сделано, сохраняем старое ядро и ставим новое:
cp /netbsd /netbsd.orig
cp netbsd /
Теперь перезагрузка. Если система не грузится, то останавливаем
процесс загрузки и указываем boot netbsd.orig для загрузки предыдущего
ядра.
______________
Оригинал статьи: http://www.netbsd.org/Documentation/tune/
Если есть замечания и исправления - жду по адресу
mixa(@).dreamcatcher.ru - буду вносить.
