From: Михаил Сгибнев <mixa(@).dreamcatcher.ru>
Newsgroups: email
Date: Mon, 17 Feb 2004 14:31:37 +0000 (UTC)
Subject: Тюнинг и диагностика проблем в NetBSD
Содержание:
* Утилиты визуального мониторинга
* Утилиты мониторинга
* Сетевые утилиты
* Аккаунтинг
* Профили ядра
* Тюнинг системы
* Тюнинг ядра
Утилиты визуального мониторинга
NetBSD предоставляет различные визуальные средства контроля за
состоянием системы. Они стандартны практически для всех UNIX. В этом
разделе приводится пример использования таких средств.
top:
----
Эта программа выводит на экран список процессов с ранжированием их по
потребляемым ресурсам. Будучи запущеным без параметров выглядит так:
Утилита показывает наиболее "прожорливое" приложение, зависшие
процессы или группы процессов, которые могут вызывать проблемы.
Приведенный выше пример - ненагруженая, спокойная система. Ниже -
совсем другой результат:
Кажется очевидным, какой процесс наиболее грузит систему, но попробуем
выяснить почему. 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:
Вышеупомянутый вывод - от ненагруженного сервера, поля представляют
различные устройства ввода/вывода - HDD, CD-ROM, FDD, память и CPU.
Теперь попробуем нагрузить систему. будем использовать все тот же
bonnie++ и передавать tarball netbsd.
Как и следует ожидать 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 пример:
Снова проводим испытания на нагрузку. Условия - те же самые: 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. Это
соотношение может быть нарушено:
Довольно страшно выглядит. Такой результат мы получили используя
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:a87e 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)
Вышеупомянутый вывод является немного более подробным. Так, как это
может помочь? Хороший пример - когда при подключении новой сети не
прописывается маршрут к ней или динамический маршрут загружается с
ошибкой, или появляется маршрут по умолчянию ведущий в никуда.
tcpdump:
--------
Последний, и определенно не в последнюю очередь - tcpdump (8), сетевой
сниффер, который может отыскать много информации. Сейчас мы рассмотрим
вывод утилиты и объясненим некоторые из наиболее полезных параметров
tcpdump.
Следующее - маленький отрывок вывода tcpdump:
Учитывая, что сервер в примере выполняет почтовые функции из вывода в
принципе, все понятно. Утилита является очень подробной, я предпочитаю
первоначально выполнить 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 показывает последние выполненные команды, можно
выбрать пользователя, чьи команды будут показаны.
Вот примерный вывод этой команды:
По умолчанию чтение производится из файла /var/account/acct, но с
помощью опции -f можно переопределить файл. Очевидно. что использовать
lastcomm в системе с большим количеством пользователей достаточно
тяжело. Тут всплывает команда sa.
sa:
---
sa (расшифровывается как "печатать статистику системного
аккаунтинга")(ни фига себе, сократили...) может использоваться для
обработки информации аккаунтинга. Может использоваться для создания
интерактивных отчетов.
Вот вывод этой команды:
Слева направо: полное время вызова, реальное время в минутах, число
пользователей, системное время в минутах, среднее количество операций
ввода/вывода, и имя команды. (Что-то несходится... Прим переводчика)
Команда sa может также использоваться, чтобы создать итоговые файлы
или сообщения, основанные на шаблонах.
Например, вот - вывод отсортированных по среднему использованию CPU:
Ведение учета, при его ведении и регулярном анализе, может помочь
предсказать появление проблем производительности, после пары месяцев
работы позволит понять, какие изменения надо сделать, чтобы сохранить
или повысить производительность. Другой хороший пример - использование
сервера сети. Если нагрузка начинает увеличиваться, возможно стоит
предпринять некоторые действия, до того как она станет реальной
проблемой. Так что, вывод однозначный - как здорово, что в 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 - список функций, сколько раз их вызывали и время
выполнения.
Как и ожидалось, основную часть времени система простаивала, но
некоторые процессы всеже работали, например 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
Все выглядит немного запутанно. Индексный номер отображается в конце
строки.
...
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 после часа работы системы с небольшим
количеством взаимодействия от пользователей:
Как видно, есть большое различие в работе. Сразу время простоя -
заметно меньше. Основное различие здесь - то, что одна специфическая
функция имеет большое время работы с очень небольшим количеством
запросов. Эта функция - 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:
-------
Данная утилита используется для просмотра и установки системных
параметров. Так как параметров очень много, рассмотреть здесь их все
не представляется возможным. Но приведем несколько примеров:
Довольно просто. Теперь кое-что, что фактически связано с работой.
Посмотрим параметр kern.maxfiles - он определяет сколько одновременно
может быть открыто файлов. На сильно нагруженных системах, говорят,
что могут появиться проблемы из-за невозможности открыть файл.
mail% sysctl kern.maxfiles
kern.maxfiles = 1772
Отлично. Теперь изменим этот параметр. Мы должны владеть правами
пользователя root и использовать параметр -w:
Помните, что после перезагрузки изменения пропадут. Есть два пути
сохранения изменений - это внести изменения в ядро и прекомпилировать
его или внести изменения в файл /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.
Вот пример:
Эта система - почтовый сервер, так что я хочу использовать только /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
В то время, как многие параметры могут быть выставлены с
использованием sysctl, очень много переменных используемых для
расширенного управления программным обеспечением (например перенос
сервисов из inetd), которые таким образом настроить нельзя. Тогда
используем перекомпиляцию ядра.
Подготовка:
Сперва получите исходники ядра. Внимание - этот документ применим к
-current ветке ядра. Также прочитайте информацию на [18]официальном
сайте, все что набисано там, написано и здесь.
Устанавливаем переменную CVSROOT. Для csh или tcsh это делается так:
Для sh, ksh и иже с ними:
CVSROOT=:pserver:anoncvs@anoncvs.NetBSD.org:/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
определяем:
Нам требуется только опция 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.
...
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 - буду вносить.
677 Прочтений • [Тюнинг и диагностика проблем в NetBSD (bsd netbsd tune optimization network ethernet kernel sysctl)] [08.05.2012] [Комментариев: 0]
7e UH
Vova
