Причина возникновения проблем производительности может находиться не в системе, во многих километрах от нее. Для того чтобы определить, лежит ли причина недостаточной производительности в сети, можно сравнить выполнение зависящих от сети операций с операциями, проходящими без участия сети. Если программа, выполняющая много операций удаленного чтения и записи, работает медленно, а все остальные программы выполняются нормально, возможно, причина находится в сети. Наиболее часто возникающие узкие места в сети:
Существует множество параметров сети, которые могут быть измерены специальными средствами, но только часть из этих параметров важны для настройки производительности.
Настройка параметров сети и NFS для увеличения производительности выполняется командами no и nfso. Кроме того, часть параметров настраивается командами chdev и ifconfig.
Команда ping применяется для:
Опции команды ping, связанные с настройкой производительности:
Опция -f часто применяется для перегрузки сети и подключенных к ней систем. Например, если вы подозреваете, что проблемы производительности вызваны высокой нагрузкой, вы можете искусственно перегрузить сеть для подтверждения этой гипотезы. Откройте несколько окон aixterm и запустите в каждом из них команду ping -f. Нагрузка на адаптер Ethernet быстро достигнет 100 процентов. Пример приведен ниже:
# date ; ping -c 1000 -f wave ; date пятница 23 июля 1999 г. 11.52.39 PING wave.austin.ibm.com: (9.53.153.120): 56 байт данных . ----wave.austin.ibm.com PING Статистика---- 1000 пакетов передано, 1000 пакетов получено, 0% пакетов потеряно время обхода мин/сред/макс = 1/1/23 мс пятница 23 июля 1999 г. 11.52.42
Примечание: Эту команду следует использовать с осторожностью - она может серьезно нарушить работу сети. Она может быть вызвана только пользователем root.
В этом примере 1000 пакетов были отправлены за 3 секунды. Учтите, что данная команда применяет протокол (ICMP) и, таким образом, не задействует транспортный протокол (UDP/TCP) и интерфейс приложений. Измеренные данные, такие как время обхода, не отражают полной производительности.
При попытке перегрузить соединение с удаленной системой учтите следующее:
С помощью ftp вы можете передать очень большой объем данных, указав /dev/zero в качестве ввода и /dev/null в качестве вывода. Это позволяет избежать использования дисков (ограничивающих пропускную способность) и кэширования всего передаваемого файла в памяти.
Введите следующие команды ftp (при необходимости увеличьте или уменьшите число блоков, считываемых командой dd):
> bin > put "|dd if=/dev/zero bs=32k count=10000" /dev/null
Учтите, что после изменения параметров TCP, перед повторным запуском команды ftp для проверки необходимо обновить настройку демона inetd командой refresh -s inetd.
Убедитесь в том, что параметры tcp_senspace и tcp_recvspace не меньше 65535 для "гигантских кадров" и Gigabit Ethernet и ATM с MTU 9180 или больше.
Пример задания параметров приведен ниже:
# no -o tcp_sendspace=65535 # no -o tcp_recvspace=65535 # refresh -s inetd 0513-095 Запрос на обновление подсистемы успешно выполнен.
Соответствующие команды ftp:
ftp> bin 200 Type set to I. ftp> put "|dd if=/dev/zero bs=32k count=10000" /dev/null 200 PORT command successful. 150 Opening data connection for /dev/null. 10000+0 records in 10000+0 records out 226 Transfer complete. 327680000 bytes sent in 8.932 seconds (3.583e+04 Kbytes/s) local: |dd if=/dev/zero bs=32k count=10000 remote: /dev/null ftp> quit 221 Goodbye.
Обычно для проверки состояния сети используется команда netstat. Эта команда более полезна для устранения неполадок, чем для измерения производительности. Однако, команда netstat может применяться для подтверждения сетевого характера проблем производительности.
Команда netstat показывает следующую информацию о передаче данных через сетевые интерфейсы:
Команда netstat показывает содержимое различных структур, связанных с активными сетевыми соединениями. В этом разделе обсуждаются только опции, связанные с производительностью сети. Информация о других опциях и столбцах приведена в AIX 5L Version 5.1 Commands Reference.
Показывает состояние всех настроенных интерфейсов.
В следующем примере показана статистика для рабочей станции с интегрированным адаптером Ethernet и Token-Ring:
# netstat -i Имя Mtu Сеть Адрес Ipkts Ierrs Opkts Oerrs Coll lo0 16896 <Link> 144834 0 144946 0 0 lo0 16896 127 localhost 144834 0 144946 0 0 tr0 1492 <Link>10.0.5a.4f.3f.61 658339 0 247355 0 0 tr0 1492 9.3.1 ah6000d 658339 0 247355 0 0 en0 1500 <Link>8.0.5a.d.a2.d5 0 0 112 0 0 en0 1500 1.2.3 1.2.3.4 0 0 112 0 0
Статистика собирается с момента запуска системы.
Примечание: Команда netstat -i не поддерживает обнаружение конфликтов для интерфейсов Ethernet (см. Команда entstat).
Ниже приведены рекомендации по настройке:
Ierrs > 0.01 x Ipkts
То запустите команду netstat -m, чтобы проверить, достаточно ли памяти.
Oerrs > 0.01 x Opkts
То следует увеличить длину очереди передачи (xmt_que_size) интерфейса. Размер xmt_que_size можно проверить следующей командой:
# lsattr -El адаптер
Coll / Opkts > 0.1
то сеть перегружена, и необходима ее реорганизация или разделение. Для определения частоты конфликтов введите команду netstat -v или entstat.
Данная функция команды netstat очищает все счетчики команды netstat -i.
Показывает статистику работы указанного интерфейса. Будет показана та же информация, что и для команды netstat -i, но для указанного интерфейса за указанный интервал времени. Пример:
# netstat -I en0 1
ввод (en0) вывод ввод (Все) вывод
пакетов ошибок пакетов ошибок конфл. пакетов ошибок пакетов ошибок конфл.
0 0 27 0 0 799655 0 390669 0 0
0 0 0 0 0 2 0 0 0 0
0 0 0 0 0 1 0 0 0 0
0 0 0 0 0 78 0 254 0 0
0 0 0 0 0 200 0 62 0 0
0 0 1 0 0 0 0 2 0 0
В предыдущем примере показан вывод команды netstat -I для интерфейса ent0. Параллельно выводятся два отчета: для указанного интерфейса и для всех доступных интерфейсов (Все). Все поля соответствуют выводу команды netstat -i; например, ввод, пакетов = Ipkts, ввод, ошибок = Ierrs и т.п.
Показывает статистику функций управления буферами. Наиболее полезная часть вывода команды netstat -m - это счетчики, показывающие число отклоненных запросов буферов, и ненулевые значения в столбце числа отказов. Число отклоненных запросов буферов может быть не показано в многопроцессорной системе начиная с версии 4.3.2 - для увеличения производительности в таких системах сбор глобальной статистики по умолчанию отключен. Для включения сбора глобальной статистики присвойте параметру extended_netstats команды no значение 1. Для этого измените файл /etc/rc.net и перезапустите систему.
Вывод команды netstat -m с параметром extended_netstats, равным 1, показан ниже:
# netstat -m 29 буферов занято: 16 страниц кластеров буферов занято 71 Кб выделено для буферов 0 отклоненных запросов буферов 0 вызовов процедур преобразования протоколов Статистика выделения памяти ядром: ******* CPU 0 ******* Размер занято вызовов отказов отложено свободно hiwat освобождено 32 419 544702 0 0 221 800 0 64 173 22424 0 0 19 400 0 128 121 37130 0 0 135 200 4 256 1201 118326233 0 0 239 480 138 512 330 671524 0 0 14 50 54 1024 74 929806 0 0 82 125 2 2048 384 1820884 0 0 8 125 5605 4096 516 1158445 0 0 46 150 21 8192 9 5634 0 0 1 12 27 16384 1 2953 0 0 24 30 41 32768 1 1 0 0 0 1023 0 Тип занято вызовов отказов отложено memuse memmax mapb Отказы статистики блоков: 0 отказов блоков с высоким приоритетом 0 отказов блоков со средним приоритетом 0 отказов блоков с низким приоритетом
Если сбор глобальной статистики выключен, для определения полного числа отклоненных запросов буферов сложите числа в строке числа отказов для каждого процессора. Если команда netstat -m показывает наличие не выполненных или отклоненных запросов буферов или кластеров, увеличьте число thewall командой no -o thewall=новое значение. Более подробная информация о параметрах thewall и maxmbuf приведена в разделе Обзор средства управления буферами.
Начиная с AIX версии 4.3.3 добавлен столбец отложено. При запросе буферов с флагом M_WAIT, если буферы недоступны, нить приостанавливается до освобождения необходимых буферов. В этом случае увеличивается не счетчик отказов, а счетчик отложенных запросов. До версии AIX 4.3.3 счетчик отказов также не увеличивался, но число отложенных запросов не выводилось.
Рекомендуется увеличить значение thewall, если выделено больше 85 процентов от значения thewall. После увеличения значения thewall проверьте командой vmstat, не привело ли уменьшение объема свободной памяти к уменьшение производительности.
Если буферы будут недоступны при получении запроса, запрос скорее всего будет потерян (информация о пакетах, отброшенных адаптером, приведена в разделе Статистика работы адаптера). Учтите, что запрос, переведенный в состояние ожидания, не считается отклоненным.
Если число не выполненных запросов продолжает увеличиваться, возможна утечка буферов. Для локализации неполадки укажите в параметре net_malloc_police команды no значение 1, либо воспользуйтесь точкой трассировкой 254 и командой trace.
После выделения и закрепления буферов и кластеров они могут быть освобождены приложением. Вместо открепления буфера и возврата его в систему он помещается в список свободных, зависящий от размера буфера. При следующем запросе буфера он берется из списка, благодаря чему экономится время закрепления страниц. Если число буферов в списке свободных достигает максимальной отметки, буферы размером 4096 объединяются в блоки, состоящие из целого числа страниц для возврата системе. При возврате буферов системе увеличивается счетчик освобожденных буферов. Если число освобожденных буферов непрерывно увеличивается, максимальная отметка слишком низка. В AIX начиная с версии 4.3.2 максимальная отметка изменяется в соответствии с объемом оперативной памяти в системе.
Команда netstat -v показывает статистику работы всех драйверов устройств CDLI системы. Информацию для отдельных интерфейсов можно получить командами tokstat, entstat, fddistat и atmstat.
Существует отдельная статистика для каждого интерфейса, а также общая статистика работы всей системы. В следующем примере показаны части вывода команды netstat -v, относящиеся к адаптерам Token-Ring и Ethernet; остальная часть вывода общая. Значения, выводимые для разных адаптеров, незначительно отличаются. Наиболее важные поля выделены.
# netstat -v
-------------------------------------------------------------
Статистика Ethernet (ent0) :
Тип устройства: Адаптер Ethernet PCI 10/100 Мб/с фирмы IBM (23100020)
Аппаратный адрес: 00:60:94:e9:29:18
Прошедшее время: 9 дней 19 часов 5 минут 51 секунд
Статистика по передаче: Статистика по приему:
-------------------- -------------------
Пакетов: 0 Пакетов: 0
Байт: 0 Байт: 0
Прерываний: 0 Прерываний: 0
Ошибки передачи: 0 Ошибки приема: 0
Отброшено пакетов: 0 Отброшено пакетов: 0
Пакеты с ошибками: 0
Максимальное число пакетов в программной очереди передачи: 0
Переполнений программной очереди передачи: 0
Текущая длина программной и аппаратной очереди передачи: 0
Пакетов оповещения: 0 Пакетов оповещения: 0
Многоцелевые пакеты: 0 Многоцелевые пакеты: 0
Несущая частота не обнаружена: 0 Ошибка CRC: 0
Выход за нижнюю границу DMA: 0 Выход за верхнюю границу DMA: 0
Ошибки потери CTS: 0 Ошибки выравнивания: 0
Максимум конфликтов: 0 Ошибок недостатка ресурсов: 0
Поздних конфликтов: 0 Конфликтов при получении: 0
Отложено: 0 Слишком коротких пакетов: 0
Проверка SQE: 0 Слишком длинных пакетов: 0
Тайм-аутов: 0 Пакетов отклонено адаптером: 0
Одиночных конфликтов: 0 Попыток получения: 0
Множественных конфликтов: 0
Текущая длина аппаратной очереди передачи: 0
Общая статистика:
-------------------
Ошибок недостатка буферов: 0
Число перезапусков адаптера: 0
Флаги драйвера: Up Broadcast Running
Simplex 64BitSupport PrivateSegment
Статистика адаптера IBM 10/100 Мбит/с Ethernet:
------------------------------------------------
Версия микросхемы: 25
Состояние порта RJ45: выключен
Выбранная скорость носителя: 10 Мбит/с полудуплекс
Текущая скорость носителя: Неизвестна
Размер буфера приема: 384
Свободных буферов приема: 128
Ошибок отсутствия буферов приема: 0
Промежуток между пакетами: 96
Число перезапуском адаптера командами IOCTL: 0
Конфликтов при передаче пакетов:
1 конфликт: 0 6 конфликтов: 0 11 конфликтов: 0
2 конфликта: 0 7 конфликтов: 0 12 конфликтов: 0
3 конфликта: 0 8 конфликтов: 0 13 конфликтов: 0
4 конфликта: 0 9 конфликтов: 0 14 конфликтов: 0
5 конфликтов: 0 10 конфликтов: 0 15 конфликтов: 0
Длительных ожиданий: 0x0
-------------------------------------------------------------
Статистика Token-Ring (tok0) :
Тип устройства: Адаптер IBM PCI Token-Ring (14103e00)
Аппаратный адрес: 00:20:35:7a:12:8a
Прошедшее время: 29 дней 18 часов 3 минут 47 секунд
Статистика по передаче: Статистика по приему:
-------------------- -------------------
Пакетов: 1355364 Пакетов: 55782254
Байт: 791555422 Байт: 6679991641
Прерываний: 902315 Прерываний: 55782192
Ошибок передачи: 0 Ошибок приема: 1
Отброшено пакетов: 0 Отброшено пакетов: 0
Пакеты с ошибками: 0
Макимальное число пакетов в программной очереди передачи: 182
Переполнений программной очереди передачи: 42
Текущая длина программной и аппаратной очереди передачи: 0
Пакетов оповещения: 18878 Пакетов оповещения: 54615793
Многоцелевых пакетов: 0 Многоцелевых пакетов: 569
Тайм-аутов: 0 Ошибок накопления при приеме: 0
Текущая длина программной очереди передачи: 0
Текущая длина аппаратной очереди передачи: 0
Общая статистика:
-------------------
Ошибок недостатка буферов: 0 Ошибок сдвоенного кабеля: 0
Ошибок прерывания: 12 Ошибок AC: 0
Серийных ошибок: 1 Ошибок копирования кадра: 0
Ошибок частоты: 0 Аппаратных ошибок: 0
Внутренних ошибок: 0 Ошибок линии: 0
Потерянных кадров: 0 Нет других станций: 1
Ошибок маркеров: 0 Удалений полученной информации: 0
Обнаружено циклов: 17 Потерь сигнала: 0
Программных ошибок: 35 Ошибок сигнала: 0
Флаги драйвера: Up Broadcast Running
AlternateAddress 64BitSupport ReceiveFunctionalAddr
16 Мбит/с
Статистика адаптера IBM PCI Token-Ring (14103e00):
---------------------------------------------------------
Текущая скорость носителя: 16 Мбит/с Полудуплекс
Выбранная скорость носителя: 16 Мбит/с Дуплекс
Переполнений при получении: 0
Опустошений буфера при передаче: 0
Ошибок ARI/FCI: 0
Уровень микрокода адаптера:001PX11B2
Число пакетов в программной приоритетной очереди передачи: 0
Число пакетов в аппаратной приоритетной очереди передачи: 0
Уровень открытого встроенного программного обеспечения: 001PXRS02
Значения выделенных полей:
Число ошибок ввода-вывода для устройства. В этом поле показано число передач, прерванных из-за ошибок аппаратного обеспечения и сети.
Такие неудачные попытки передачи замедляют работу системы.
Максимальное число пакетов в программной очереди передачи за все время измерения.
Если это значение равно текущему размеру очереди (xmt_que_size), последний следует увеличить. Такое значение показывает, что очередь переполнялась.
Для проверки текущего размера очереди введите команду lsattr -El адаптер, (где адаптер - это, например, tok0 или ent0). Поскольку очередь связана с драйвером устройства и адаптером интерфейса, необходимо указывать имя адаптера, а не имя интерфейса. Изменить размер очереди можно с помощью SMIT или командой chdev.
Число исходящих пакетов, переполнивших программную очередь передачи. Ненулевое значение требует тех же действий по исправлению, что и достижение параметром Максимальное число пакетов в программной очереди передачи значения xmt_que_size. Необходимо увеличить очередь передачи.
Число пакетов оповещения, полученных без ошибок.
Сравните число пакетов оповещения с полным числом полученных пакетов. Это значение должно быть меньше 20 процентов от полного числа полученных пакетов. Большие значения ведут к перегрузке сети; в этом случае рекомендуется перейти к многоцелевой рассылке. Многоцелевая рассылка позволяет передавать сообщение сразу группе хостов, а не всем членам группы по отдельности.
Счетчик переполнений DMA увеличивается при каждой неполной передаче пакета системы с помощью DMA. Существовали свободные буферы для помещения пакета, но операция DMA не была выполнена. Это происходит, если шина MCA перегружена, и адаптеру не удается передать пакет с помощью DMA. В перегруженной системе возникновение таких ситуаций зависит от положения адаптера на шине. Обычно адаптер в самом нижнем разъеме шины, обладая большим приоритетом, занимает настолько большую часть полосы пропускания, что адаптеры в более высоких разъемах не могут получить доступ к шине. Обычно это случается, если в нижнем разъеме установлен адаптер ATM или SSA.
Число неудачных передач, связанных со слишком большим числом конфликтов. Число обнаруженных конфликтов превысило число повторов, заданное для адаптера.
Число неудачных передач, связанных с конфликтом после начала передачи.
Число неудачных передач, связанных с получением тайм-аута от адаптера.
Число исходящих пакетов, при передаче которых был обнаружен только один конфликт.
Число исходящих пакетов, при передаче которых было обнаружено несколько (от 2 до 15) конфликтов.
Число входящих пакетов, при приеме которых произошел конфликт.
Число неудачных запросов на получение буферов от драйвера устройства. Обычно такие запросы отправляются при получении входящих пакетов. Если пул буферов запрошенного размера пуст, пакет будет потерян. Проверьте указанную причину командой netstat -m, затем увеличьте параметр thewall.
Число Ошибок недостатка буферов зависит от интерфейса и не совпадает с числом отклоненных запросов буферов, показываемым командой netstat -m. Сравните вывод команд netstat -m и netstat -v (для адаптеров Ethernet и Token-Ring).
Для локализации проблем производительности сети проверьте число Ошибок в выводе команды netstat -v.
Дополнительные рекомендации:
(Максимум конфликтов + Тайм-аутов) / Переданных пакетов
Если результат превышает 5 процентов, реорганизуйте сеть для более равномерного распределения нагрузки.
Если полное число конфликтов в выводе команды netstat -v (для Ethernet) превышает 10 процентов от полного числа переданных пакетов, то есть:
Число конфликтов / Число переданных пакетов > 0.1
Показывает статистику значений переменных протокола (udp, tcp, ip, icmp); можно указать либо имя протокола, либо его псевдоним. Некоторые имена и псевдонимы протоколов указаны в файле /etc/protocols. Пустой ответ означает отсутствие указанных чисел. Если функция статистики для протокола отсутствует, значение переменной протокола считается неизвестным.
В следующем примере показан вывод для протокола ip:
# netstat -p ip
ip:
:
491351 пакетов получено всего
0 неправильных контрольных сумм заголовка
0 с размером меньше минимального
0 с размером данных < длины данных
0 с длиной заголовка < размера данных
0 с длиной данных < длины заголовка
0 с неправильными параметрами
0 с неправильным номером версии
25930 фрагментов получено
0 фрагментов отброшено (повторы или выход за границы)
0 фрагментов отброшено после тайм-аута
12965 пакетов успешно собрано
475054 пакетов для данного хоста
0 пакетов для неизвестного/неподдерживаемого протокола
0 пакетов переслано
3332 пакетов не удалось переслать
0 перенаправлений отправлено
405650 пакетов отправлено этим хостом
0 пакетов отправлено с подделанным заголовком ip
0 исходящих пакетов отброшено из-за отсутствия буферов и пр.
0 исходящих пакетов отброшено из-за невозможности маршрутизации
5498 исходящих дейтаграмм фрагментировано
10996 фрагментов создано
0 дейтаграмм не может быть фрагментировано
0 отброшено многоцелевых пакетов IP из-за отсутствия получателя
0 переполнений ipintrq
Значения выделенных полей:
Полное число полученных дейтаграмм IP.
Если вывод содержит ненулевые значения в поле неправильная контрольная сумма заголовка или фрагментов отброшено из-за повтора или выхода за границы, это означает, что либо сеть повреждает пакеты, либо очередь получения драйвера устройства недостаточна.
Полное число полученных фрагментов.
Ненулевое число фрагментов, отброшенных после тайм-аута, означает, что счетчик времени жизни фрагментов ip из-за перегрузки сети достигает нулевого значения до получения всех фрагментов дейтаграммы. Для исправления увеличьте значение параметра ipfragttl командой no. Другая возможная причина - недостаток буферов; в этом случае следует увеличить значение thewall.
Число IP-дейтаграмм, созданных и отправленных из локальной системы. Этот счетчик не включает пересланные (транзитные) дейтаграммы.
Число фрагментов, созданных в локальной системе при отправке дейтаграмм.
При просмотре статистики протокола IP обратите внимание на отношение числа полученных пакетов к числу полученных фрагментов. Для сетей с небольшим MTU не должно фрагментироваться больше 10 процентов пакетов. Большое число фрагментов означает, что протоколы более высокого уровня в удаленных хостах передают данные блоками, превышающими MTU интерфейса. Кроме того, фрагментация может происходить на маршрутизаторах и шлюзах. Те же рекомендации относятся к отношению чисел отправленных пакетов и созданных фрагментов.
Фрагментация увеличивает нагрузку на процессор, поэтому важно определить ее причину. Учтите, что фрагментация неизбежна при работе некоторых приложений. Например, фрагментация происходит, если приложение отправляет данные небольшими порциями. Однако, если фрагментация происходит несмотря на то, что приложение отправляет данные большими блоками, найдите причину такого поведения. Возможно, указанный размер MTU интерфейса не совпадает с размером MTU удаленных систем.
В следующем примере показан пример вывода для протокола udp:
# netstat -p udp
udp:
11521194 дейтаграмм получено
0 неполных заголовков
0 полей неправильной длины
0 неправильных контрольных сумм
16532 пакетов отброшено из-за отсутствия сокета
232850 дейтаграмм оповещения и многоцелевых отброшено из-за отсутствия сокета
77 переполнений буфера сокета
11271735 доставлено
796547 дейтаграмм отправлено
Значения выделенных полей:
Причиной появления неправильных контрольных сумм могут быть сбои карты адаптера или кабеля.
Число полученных дейтаграмм UDP, целевой порт для которых не был открыт. В результате обратно отправляется сообщение Цель ICMP недоступна - Порт недоступен. При получении дейтаграммы оповещения UDP ошибки ICMP не создаются. Большое число таких дейтаграмм указывает на ошибки работы с сокетами в приложении.
Переполнения буфера сокета связаны с недостаточным количеством сокетов приема и передачи UDP, демонов nfsd, или недостаточной величиной параметров nfs_socketsize , udp_recvspace и sb_max.
Если команда netstat -p udp показывает наличие переполнений буферов сокетов, рекомендуется увеличить число демонов nfsd. Сначала проверьте, не перегружен ли процессор или ввод-вывод системы, затем проверьте настройки других уровней связи командой no -a. Если система перегружена, необходимо либо уменьшить нагрузку, либо модернизировать систему.
В следующем примере показан пример вывода для протокола tcp:
# netstat -p tcp
tcp:
63726 пакетов отправлено
34309 пакетов данных (6482122 байт)
198 пакетов данных (161034 байт) отправлено повторно
17437 пакетов уведомления (7882 отложено)
0 срочных пакетов
0 пакетов проверки окна
3562 пакетов обновления окна
8220 управляющих пакетов
71033 пакетов получено
35989 уведомлений (для 6444054 байт)
2769 повторных уведомлений
0 лишних уведомлений
47319 пакетов (19650209 байт) получено в правильном порядке
182 полностью повторных пакетов (29772 байт)
4 пакетов с повторными данными (1404 байт повторены)
2475 пакетов в неправильном порядке (49826 байт)
0 пакетов (0 байт) данных после окна
0 проверок окна
800 пакетов обновления окна
77 пакетов получено после закрытия
0 пакетов с неправильной аппаратной контрольной суммой
0 отброшено из-за неправильной контрольной суммы
0 отброшено из-за неправильных полей заголовка
0 запросов установления соединения
3125 запросов установления соединения
1626 разрешений установления соединения
4731 соединений установлено (включая разрешения)
5543 соединений закрыто (включая 31 отброшенных)
62 неполных соединений отброшено
38552 сегментов обновлено (38862 попыток)
0 повторных передач, связанных с вычислением MTU маршрута
3 прерываний вычисления MTU маршрута, связанных с повторной передачей
553 тайм-аутов повторной передачи
28 соединений отброшено из-за тайм-аута повторной передачи
0 постоянных тайм-аутов
464 тайм-аутов времени жизни
26 проверок времени жизни отправлено
1 соединений отброшено по времени жизни
0 соединений использовано повторно
0 отложенных уведомлений для SYN
0 отложенных уведомлений для FIN
0 отправок с отсоединением
Значения выделенных полей:
Сравните число отправленных пакетов с числом повторно отправленных пакетов. Если число повторно отправленных пакетов превышает 10-15 процентов от полного числа пакетов, происходят тайм-ауты TCP; возможно, они вызваны слишком высокой нагрузкой на сеть для передачи уведомлений до наступления тайм-аута. Повторные передачи TCP могут также быть вызваны перегрузкой принимающего узла, либо общими проблемами производительности сети; повторные передачи сами по себе увеличивают поток данных и нагрузку на сеть.
Кроме того, сравните число полученных пакетов с числом полностью повторных пакетов. Если после отправки пакета происходит тайм-аут ожидания подтверждения, пакет передается повторно. При этом другая сторона может получить все переданные копии пакета. Если число повторных пакетов превышает 10-15 процентов, возможно, сеть или принимающий узел перегружен. Повторные передачи пакетов также увеличивают поток данных в сети.
Тайм-аут повторной передачи регистрируется, если узел отправил пакет, но не получил подтверждение за заданное время. При этом выполняется повторная передача пакета. Это значение увеличивается для каждой повторной передачи. Повторные передачи увеличивают нагрузку на CPU; если подтверждение так и не будет получено, пакет будет отброшен.
Команда netstat -s показывает статистику для каждого протокола (в то время как команда netstat -p показывает статистику только для указанного протокола).
Недокументированная опция -s -s показывает только ненулевые строки вывода команды netstat -s, упрощая анализ ошибок.
Это недокументированная функция команды netstat. Она очищает все счетчики команды netstat -s.
Другая опция, связанная с производительностью - это вычисленный MTU маршрута (PMTU).
Для двух хостов, передающих данные через несколько сетей, передаваемый пакет будет фрагментирован, если его размер превышает минимальное значение MTU для всех сетей маршрута. Поскольку фрагментация пакета уменьшает производительность сети, рекомендуется уменьшить ее вероятность, передавая пакеты меньшего размера, чем минимальный MTU маршрута. Максимальный размер пакета, который не будет фрагментирован, называется MTU маршрута.
Значение MTU маршрута можно вывести командой netstat -r. В следующем примере команда netstat -r -f inet применяется для просмотра только таблиц маршрутизации:
# netstat -r -f inet Таблицы маршрутизации Цель Шлюз Флаги Ссылки ЧастотаPMTU Инт Срок Группы Дерево маршрутов для семейства протоколов 2: default itsorusi UGc 1 348 - tr0 - 9.3.1 sv2019e Uc 25 12504 - tr0 - itsonv sv2019e UHW 0 235 - tr0 - itsorusi sv2019e UHW 1 883 1492 tr0 - ah6000d sv2019e UHW 1 184 1492 tr0 - ah6000e sv2019e UHW 0 209 - tr0 - sv2019e sv2019e UHW 4 11718 1492 tr0 - coyote.ncs.mainz itsorusi UGHW 1 45 1492 tr0 - kresna.id.ibm.co itsorusi UGHW 0 14 1492 tr0 - 9.184.104.111 kresna.id.ibm.com UGc 0 5 - tr0 - 127 localhost U 3 96 - lo0 -
Опция -D позволяет узнать число пакетов, получаемых каждым из уровней сетевой подсистемы, а также число отброшенных пакетов на каждом уровне.
# netstat -D
Источник Ipkts Opkts Idrops Odrops
-------------------------------------------------------------------------------
tok_dev0 19333058 402225 3 0
ent_dev0 0 0 0 0
---------------------------------------------------------------
Всего для устройств 19333058 402225 3 0
-------------------------------------------------------------------------------
tok_dd0 19333055 402225 0 0
ent_dd0 0 0 0 0
---------------------------------------------------------------
Всего для драйверов 19333055 402225 0 0
-------------------------------------------------------------------------------
tok_dmx0 796966 N/A 18536091 N/A
ent_dmx0 0 N/A 0 N/A
---------------------------------------------------------------
Всего для демультиплексоров 796966 N/A 18536091 N/A
-------------------------------------------------------------------------------
IP 694138 677411 7651 6523
TCP 143713 144247 0 0
UDP 469962 266726 0 812
---------------------------------------------------------------
Всего для протоколов 1307813 1088384 7651 7335
-------------------------------------------------------------------------------
lo_if0 22088 22887 799 0
tr_if0 796966 402227 0 289
---------------------------------------------------------------
Всего для интерфейсов 819054 425114 799 289
-------------------------------------------------------------------------------
---------------------------------------------------------------
Всего для NFS/RPC N/A 1461 0 0
-------------------------------------------------------------------------------
(Примечание: N/A -> Не применимо)
Уровень устройств показывает число пакетов, получаемых и передаваемых адаптером, а также отброшенных при приеме и передаче. Существуют различные причины ошибок адаптера, для получения более подробной информации проанализируйте вывод команды netstat -v.
Уровень драйверов показывает число пакетов, полученных драйвером устройства для каждого адаптера. Для определения причин ошибок запустите команду netstat -v.
Значения для демультиплексоров показывают число пакетов на уровне демультиплексоров, а ненулевое значение в столбце Idrops обычно указывает на отклонение определенных пакетов при фильтрации (например, пакеты Netware и DecNet не поддерживались и отклонялись системой в примере).
Более подробную информацию об уровне протоколов можно получить командой netstat -s.
Примечание: В выводимой статистике N/A означает, что соответствующий параметр не применим к уровню. Для статистики NFS/RPC все входящие пакеты RPC проходят через NFS, поэтому данные числа не складываются, поэтому в поле Всего для NFS/RPC стоит N/A. NFS не поддерживает счетчики исходящих пакетов и отброшенных исходящих пакетов отдельно для NFS и RPC. Поэтому в полях для отдельных счетчиков стоит N/A, а полное значение показано в поле Всего для NFS/RPC.
Команда netpmon выводит подробную информацию о работе сети в течение заданного интервала времени, собранную функцией трассировки. Поскольку команда netpmon вызывает функцию трассировки, ее разрешено запускать только пользователю root и членам группы system.
Кроме того, команду netpmon нельзя запускать с другими командами сбора данных, использующими функцию трассировки, например, tprof и filemon. Как правило, команда netpmon выполняется в фоновом режиме, отслеживая работу параллельно выполняющихся приложений и системных команд.
Команда netpmon собирает следующую информацию о работе системы:
Вычисляются следующие значения:
Для того чтобы узнать, установлена ли в системе команда netpmon, вызовите следующую команду:
# lslpp -lI perfagent.tools
Команда netpmon включает функцию трассировки, которую можно временно выключить с помощью подкоманды trcoff, снова включить с помощью подкоманды trcon или выключить с помощью подкоманды trcstop. После выключения трассировки команда netpmon записывает свой отчет в стандартный вывод.
Если не указана опция -d, команда netpmon сразу же включает функцию трассировки. Для того чтобы выключить трассировку, вызовите команду trcstop. После выключения трассировки команда netpmon создаст все перечисленные отчеты и завершит свою работу. В среде клиент-сервер команда netpmon позволяет узнать, каким образом передача данных по сети влияет на общую производительность системы. Ее можно запустить как на клиенте, так и на сервере.
Вместо выполнения трассировки команда netpmon может считывать данные трассировки ввода-вывода из указанного файла. В этом случае отчет команды netpmon будет содержать информацию об операциях обмена данными по сети, зафиксированными в файле. Автономная обработка файла трассировки может выполняться в другой системе. Кроме того, она позволяет разделить сбор данных и их обработку.
Вначале файл трассировки должен быть обработан командой trcrpt -r. Вывод команды должен быть перенаправлен в другой файл:
# gennames > gennames.out # trcrpt -r trace.out > trace.rpt
Преобразованный файл трассировки можно передать команде netpmon для создания отчета об операциях ввода-вывода, зарегистрированных в ходе трассировки:
# netpmon -i trace.rpt -n gennames.out | pg
В данном примере команда netpmon считывает информацию, собранную функцией трассировки, из файла ввода trace.rpt. Поскольку данные трассировки уже находятся в файле, команда netpmon не переходит в фоновый режим. После того как будут считаны все данные из файла, команда создает отчеты о работе сети и записывает их в стандартный вывод (в данном примере - передает их на вход команде pg).
Если команда trace была запущена с флагом -C all, команду trcrpt также следует запустить с флагом -C all (см. Форматирование вывода команды trace -C).
Ниже приведен пример команды netpmon, запущенной на сервере NFS, которая вызывает команду sleep и создает отчет через 400 секунд. В течение работы команды в системе выполняется копирование смонтированной файловой системы NFS /nfs_mnt.
# netpmon -o netpmon.out -O all; sleep 400; trcstop
С опцией -O можно задать тип отчета, который должен быть создан. Существуют следующие типы отчетов:
# cat netpmon.out
Четверг 21 января 2000 г. 15.02.45
Система: AIX itsosmp Узел: 4 Компьютер: 00045067A000
Интервал измерения: 401,053 секунды
========================================================================
Статистика использования CPU процессами:
-----------------------------
Сеть
Процессы (20 первых) PID Время CPU CPU % CPU %
----------------------------------------------------------
nfsd 12370 42.2210 2.632 2.632
nfsd 12628 42.0056 2.618 2.618
nfsd 13144 41.9540 2.615 2.615
nfsd 12886 41.8680 2.610 2.610
nfsd 12112 41.4114 2.581 2.581
nfsd 11078 40.9443 2.552 2.552
nfsd 11854 40.6198 2.532 2.532
nfsd 13402 40.3445 2.515 2.515
lrud 1548 16.6294 1.037 0.000
netpmon 15218 5.2780 0.329 0.000
gil 2064 2.0766 0.129 0.129
trace 18284 1.8820 0.117 0.000
syncd 3602 0.3757 0.023 0.000
swapper 0 0.2718 0.017 0.000
init 1 0.2201 0.014 0.000
afsd 8758 0.0244 0.002 0.000
bootpd 7128 0.0220 0.001 0.000
ksh 4322 0.0213 0.001 0.000
pcimapsvr.ip 16844 0.0204 0.001 0.000
netm 1806 0.0186 0.001 0.001
----------------------------------------------------------
Всего (все процессы) 358.3152 22.336 20.787
Время простоя 1221.0235 76.114
========================================================================
Статистика использования CPU обработчиком прерываний первого уровня:
---------------------------------------------------
Сеть
FLIH Время CPU CPU % CPU %
----------------------------------------------------------
уменьшение PPC 9.9419 0.620 0.000
внешнее устройство 4.5849 0.286 0.099
неизвестно 0.1716 0.011 0.000
страничные ошибки (данные) 0.1080 0.007 0.000
плавающая точка 0.0012 0.000 0.000
страничные ошибки (команды) 0.0007 0.000 0.000
----------------------------------------------------------
Всего (все FLIH) 14.8083 0.923 0.099
========================================================================
Статистика использования CPU обработчиком прерываний второго уровня:
----------------------------------------------------
Сеть
SLIH Время CPU CPU % CPU %
----------------------------------------------------------
tokdd 12.4312 0.775 0.775
ascsiddpin 0.5178 0.032 0.000
----------------------------------------------------------
Всего (все SLIH) 12.9490 0.807 0.775
========================================================================
Статистика драйвера сетевых устройств (по устройствам):
---------------------------------------------
--------- Передано --------- ------ Получено -------
Устройство пакетов/с байт/с Исп. Дл.очер. пакетов/с байт/с интерф.
------------------------------------------------------------------------------
token ring 0 31.61 4800 1.7% 0.046 200.93 273994 0.0080
========================================================================
Статистика передачи для драйвера сетевых устройств (по целевым хостам):
----------------------------------------------------------------
Хост пакетов/с байт/с
----------------------------------------
ah6000c 31.57 4796
9.3.1.255 0.03 4
itsorusi 0.00 0
========================================================================
Статистика обращений процессов к сокетам TCP:
----------------------------------------
----- Чтение ---- ---- Запись -----
Процессы (20 первых) PID вызовов/с байт/с вызовов/с байт/с
------------------------------------------------------------------------
telnetd 18144 0.03 123 0.06 0
------------------------------------------------------------------------
Всего (все процессы) 0.03 123 0.06 0
========================================================================
Статистика обращений клиентов к серверу NFS:
----------------------------------
----- Чтение ---- ---- Запись ----- Прочее
Клиент вызовов/с байт/с вызовов/с байт/с вызовов/с
------------------------------------------------------------------------
ah6000c 0.00 0 31.54 258208 0.01
------------------------------------------------------------------------
Всего (все клиенты) 0.00 0 31.54 258208 0.01
========================================================================
Подробная статистика использования CPU обработчиком прерываний второго уровня:
-------------------------------------------------------------
SLIH: tokdd
число: 93039
время CPU (мс): сред 0.134 мин 0.026 макс 0.541 откл 0.051
SLIH: ascsiddpin
число: 8136
время CPU (мс): сред 0.064 мин 0.012 макс 0.147 откл 0.018
Общее (Все SLIH)
число: 101175
время CPU (мс): сред 0.128 мин 0.012 макс 0.541 откл 0.053
========================================================================
Подробная статистика для драйвера сетевых устройств:
------------------------------------------
Устройство: token ring 0
получено пакетов: 80584
получено (байт): сред 1363.6 мин 50 макс 1520 откл 356.3
время получения (мс): сред 0.081 мин 0.010 макс 0.166 откл 0.020
время на ур. инт.(мс): сред 0.040 мин 0.008 макс 0.375 откл 0.040
передано пакетов: 12678
передано (байт): сред 151.8 мин 52 макс 184 откл 3.3
время передачи (мс): сред 1.447 мин 0.509 макс 4.514 откл 0.374
========================================================================
Подробная статистика передачи для драйвера сетевых устройств (по целевым хостам):
-------------------------------------------------------------
Хост: ah6000c
передано пакетов: 12662
передано (байт): сред 151.9 мин 52 макс 184 откл 2.9
время передачи (мс): сред 1.448 мин 0.509 макс 4.514 откл 0.373
Хост: 9.3.1.255
передано пакетов: 14
передано (байт): сред 117.0 мин 117 макс 117 откл 0.0
время передачи (мс): сред 1.133 мин 0.884 макс 1.730 откл 0.253
Хост: itsorusi
передано пакетов: 1
передано (байт): сред 84.0 мин 84 макс 84 откл 0.0
время передачи (мс): сред 0.522 мин 0.522 макс 0.522 откл 0.000
========================================================================
Подробная статистика обращений процессов к сокетам TCP:
-------------------------------------------------
Процесс: telnetd PID: 18144
операций чтения: 12
прочитано (байт): сред 4096.0 мин 4096 макс 4096 откл 0.0
время чтения (мс): сред 0.085 мин 0.053 макс 0.164 откл 0.027
операций записи: 23
записано (байт): сред 3.5 мин 1 макс 26 откл 7.0
время записи (мс): сред 0.143 мин 0.067 макс 0.269 откл 0.064
Протокол: TCP (все процессы)
операций чтения: 12
прочитано (байт): сред 4096.0 мин 4096 макс 4096 откл 0.0
время чтения (мс): сред 0.085 мин 0.053 макс 0.164 откл 0.027
операций записи: 23
записано (байт): сред 3.5 мин 1 макс 26 откл 7.0
время записи (мс): сред 0.143 мин 0.067 макс 0.269 откл 0.064
========================================================================
Подробная статистика обращений клиентов к серверу NFS:
-------------------------------------------
Клиент: ah6000c
операций записи: 12648
записано (байт): сред 8187.5 мин 4096 макс 8192 откл 136.2
время записи (мс): сред 138.646 мин 0.147 макс 1802.067 откл 58.853
прочие вызовы: 5
время выполнения (мс): сред 1.928 мин 0.371 макс 8.065 откл 3.068
Общее (все клиенты)
операций записи: 12648
записано (байт): сред 8187.5 мин 4096 макс 8192 откл 136.2
время записи (мс): сред 138.646 мин 0.147 макс 1802.067 откл 58.853
прочие вызовы: 5
время выполнения (мс): сред 1.928 мин 0.371 макс 8.065 откл 3.068
Вывод команды netpmon состоит из отчетов двух типов: общих и подробных. Общие отчеты содержат следующую статистическую информацию:
Общие отчеты расположены в начале вывода команды netpmon. Они содержат информацию, собранную за указанный интервал времени. Подробные отчеты содержат дополнительную информацию об объектах, статистика для которых приведена в общих отчетах. По умолчанию в отчетах выводится 20 максимальных значений измеряемых показателей. Строки отчета упорядочены в порядке уменьшения значений показателей.
Отчеты команды netpmon содержат заголовок, в котором указывается дата, ИД компьютера и интервал сбора данных в секундах. После заголовка следует список общих и подробных отчетов различных типов.
Каждая строка отчета содержит информацию об использовании процессора указанным процессом. Если опция подробного вывода (-v) не задана, то список содержит 20 процессов, на выполнение которых затрачивается больше всего процессорного времени. В нижней области отчета указано общее время процессора, затраченное всеми процессами, а также время простоя процессора. Доля времени, в течение которого процессор простаивает, вычисляется путем деления времени простоя процессора на интервал сбора данных. Сумма времени простоя и общего времени, затраченного на выполнение процессов, не совпадает с интервалом сбора данных, так как какая-та часть времени была затрачена на работу обработчиков прерываний.
Значение Сеть (CPU %) указывает, какая доля процессорного времени (в процентах) бала затрачена на выполнение сетевых функций.
Если указан флаг -t, то отчет содержит информацию об использовании CPU для различных нитей. В этом случае после строки с информацией о процессе следует несколько строк с информацией о том, какое время было затрачено на выполнение отдельных нитей процесса. Для нитей указываются те же значения, что и для процессов, за исключением имени. Нитям имена не присваиваются.
В приведенном примере общего отчета об использовании процессора доля времени простоя (76,114) получена путем деления общего времени простоя (1221,0235) на длину интервала измерения, умноженную на 4 (401,053*4), поскольку на сервере работает четыре процессора. Для получения информации о работе отдельных процессоров вызовите команду sar, ps или другую команду, предназначенную для многопроцессорной системы. Аналогичным образом вычисляется общее значение CPU %. Время простоя отлично от нуля, так как выполнялись операции передачи данных по сети. Сумма итоговых значений для времени CPU (1221.0235 + 358.315) не совпадает с интервалом измерения, так как в системе есть несколько процессоров, и часть времени была затрачена на обработку прерываний. В примере отчета основная часть процессорного времени была затрачена на выполнение сетевых операций: (20,787 / 22,336) = 93,07 процента. Около 77,664 процентов времени процессор простаивал или ожидал выполнения операции.
Примечание: Если в отчете Статистика использования CPU процессами доля времени, затраченная на выполнение сетевых операций (Сеть - CPU%), поделенная на долю времени, затраченную на выполнение всех операций (Всего CPU %), больше 0,5, то основная часть процессорного времени затрачивается на выполнение сетевых функций.
Кроме того, этот отчет позволяет узнать долю времени, затраченную на выполнение отдельных процессов, не передавая вывод на обработку специальной программе.
В отчете указана информация об использовании процессора обработчиками прерываний первого уровня (FLIH). В нижней области отчета указано общее процессорное время, затраченное на выполнение всех FLIH.
В отчете указана информация об использовании процессора обработчиками прерываний второго уровня (SLIH). В нижней области отчета указано общее процессорное время, затраченное на выполнение всех SLIH.
Каждая строка отчета содержит информацию о работе сетевого устройства.
В данном примере параметр Дл. очер. равен 0,046. Это значение намного меньше размера очереди по умолчанию (30). Значение Получено байт/с равно 273994, что намного меньше скорости передачи данных в сети Token-Ring (16 Мб/с). Следовательно, этот отчет показывает, что сеть слабо загружена.
В каждой строке отчета указано, какой объем данных был передан указанному целевому хосту на уровне драйвера устройства.
Данная статистическая информация выводится для всех протоколов Internet. В каждой строке отчета указано, сколько раз процесс обращался к сокету того или иного протокола через функции read() и write(). В нижней области отчета указано общее число обращений к сокету указанного протокола.
В каждой строке отчета задано число операций, выполненных сервером NFS по запросу указанного клиента. В нижней области отчета указано общее число обращений к серверу.
Если команда выполняется на клиенте, то статистика обращений к серверу NFS заменяется на статистику работы клиента с различными серверами (Статистика обращений клиента к серверам NFS (по файлам), Статистика применения RPC на клиенте NFS (по серверам), Статистика работы клиента NFS (по процессам)).
Команда создает подробные отчеты тех типов, которые заданы с опцией -O. Для указанных типов отчетов создаются как общие, так и подробные отчеты. Подробные отчеты содержат те же записи, что и общие отчеты, но содержат статистику выполнения различных транзакций.
Статистика выполнения транзакций включает число транзакций заданного типа, время ответа и, при необходимости, объем обработанных данных. Для объема обработанных данных указывается среднее, минимальное и максимальное значения, а также стандартное отклонение. Примерно две трети указанных значений находятся в пределах стандартного отклонения от среднего значения. Объем данных указывается в байтах. Время ответа указывается в миллисекундах.
Ниже описаны поля отчета:
Ниже описаны поля отчета:
Существуют и другие типы подробных отчетов, в том числе Подробная статистика передачи для драйвера сетевого устройства (по хостам) и Подробная статистика обращений к сокетам TCP (по процессам). Для клиента NFS создаются отчеты Подробная статистика обращений клиента NFS к серверам (по файлам), Подробная статистика вызова RPC клиентом NFS (по серверам) и Подробная статистика работы клиента NFS (по процессам). Для сервера NFS дополнительно создается отчет Подробная статистика обращений клиентов к серверу NFS. Поля этих отчетов аналогичны описанным ниже.
В приведенном примере значения из отчета Подробная статистика для драйвера сетевого устройства связаны следующим образом:
Из этого отчета, как и из общего отчета для драйвера устройства, видно, что сеть загружена слабо. Средний объем полученных данных составляет 1363.6 байт, что немного меньше MTU по умолчанию. В случае Token-Ring размер максимального блока передачи по умолчанию составляет 1492 байт. Если указанное значение больше MTU (размер MTU можно узнать с помощью команды lsattr -E -l интерфейс, где интерфейс нужно заменить на имя интерфейса, например, en0 или tr0), то измените MTU или размер очереди передачи адаптера для повышения производительности с помощью следующей команды:
# ifconfig tr0 mtu 8500
или
# chdev -l 'tok0' -a xmt_que_size='150'
Если сеть уже перегружена, то изменение размера MTU или очереди передачи не приведет к повышению производительности.
Примечание:
- Если в отчете о работе драйвера устройства указано, что размер отправляемых и принимаемых пакетов невелик, то для повышения производительности рекомендуется увеличить текущий размер MTU.
- Если в отчете о работе клиента NFS указано, что время ожидания выполнения сетевых функций велико, то низкая производительность связана с передачей данных по сети.
Для получения статистической информации команда netpmon применяет функцию трассировки. Следовательно, ее применение создает дополнительную нагрузку на систему.
Для того чтобы избежать снижения производительности, рекомендуется выполнять автономную обработку данных трассировки, а в многопроцессорных системах - указывать в команде trace флаг -C all.
Команда ping позволяет убедиться, что удаленная сеть IP достижима. Однако с ее помощью нельзя обнаружить и устранить неполадки. Рассмотрим следующий пример:
Команда traceroute позволяет узнать, где в данный момент находится пакет, и почему его нельзя доставить по заданному маршруту. Если пакет будет передаваться через маршрутизаторы и каналы связи, принадлежащие другим организациям, то вам вряд ли удастся проверить состояние этих маршрутизаторов с помощью команды telnet. В этом случае можно воспользоваться командами traceroute и ping.
Примечание: Команда traceroute может применяться для тестирования, администрирования и оценки значений параметров сети. В основном она предназначена для локализации неполадок. Поскольку команда traceroute создает дополнительную нагрузку на сеть, не применяйте ее во время обычной работы и не включайте в сценарии.
Команда traceroute применяет протокол UDP и функцию создания отчета об ошибках, предусмотренную в ICMP. Эта команда трижды отправляет пакет UDP каждому шлюзу или маршрутизатору, входящему в маршрут. Первый пакет отправляется ближайшему шлюзу. Второй пакет отправляется следующему за ним транзитному узлу и т.д. Последний пакет отправляется целевой системе. В выводе команды указывается имя шлюза, IP-адрес шлюза и время оборота трех пакетов, отправленных шлюзу. Ниже приведен пример вывода команды:
# traceroute wave trying to get source for wave source should be 9.53.155.187 traceroute to wave.austin.ibm.com (9.53.153.120) from 9.53.155.187 (9.53.155.187), 30 hops max outgoing MTU = 1500 1 9.111.154.1 (9.111.154.1) 5 ms 3 ms 2 ms 2 wave (9.53.153.120) 5 ms 5 ms 5 ms
Ниже приведен другой пример:
# traceroute wave trying to get source for wave source should be 9.53.155.187 traceroute to wave.austin.ibm.com (9.53.153.120) from 9.53.155.187 (9.53.155.187), 30 hops max outgoing MTU = 1500 1 9.111.154.1 (9.111.154.1) 10 ms 2 ms 3 ms 2 wave (9.53.153.120) 8 ms 7 ms 5 ms
Команда была повторно вызвана после того, как истек срок действия записи ARP. Обратите внимание, что время оборота первого пакета, отправляемого шлюзу или целевому хосту, больше, чем у остальных пакетов. Это связано с тем, что дополнительное время затрачивается на получение информации от протокола ARP. Если маршрут проходит через сеть с коммутацией каналов (WAN), то при передаче первого пакета дополнительное время будет затрачено на установление соединения. В результате может произойти тайм-аут. Тайм-аут по умолчанию составляет 3 секунды. Его можно изменить с помощью опции -w.
Первые 10 мс затрачены системой (9.53.155.187) на получение адреса шлюза 9.111.154.1 с помощью протокола ARP. Следующие 8 мс затрачены шлюзом на получение адреса целевого хоста (wave). В данном случае применяется DNS, поэтому перед отправкой каждого пакета команда traceroute обращается к серверу DNS.
Если маршрут к целевому хосту включает большое число транзитных узлов или проходит через сети со сложной конфигурацией, то при вызове команды traceroute часто возникают различного рода ошибки. Поскольку многие аспекты работы команды зависят от ее реализации, во многих случаях невозможно найти причину ошибки. Однако если все маршрутизаторы и системы, через которые передается пакет, относятся к вашей организации, то вы можете проанализировать причину ошибки.
В приведенном ниже примере пакеты отправляются из системы 9.53.155.187. Маршрут к мосту включает две системы, играющие роль маршрутизаторов. Во второй из этих систем функция маршрутизации была временно выключена (опции ipforwarding было присвоено значение 0 с помощью команды no). Рассмотрим приведенный ниже пример:
# traceroute lamar trying to get source for lamar source should be 9.53.155.187 traceroute to lamar.austin.ibm.com (9.3.200.141) from 9.53.155.187 (9.53.155.187), 30 hops max outgoing MTU = 1500 1 9.111.154.1 (9.111.154.1) 12 ms 3 ms 2 ms 2 9.111.154.1 (9.111.154.1) 3 ms !H * 6 ms !H
Все сообщения об ошибках ICMP, за исключением Истекло время и Порт недостижим, выдаются в следующем формате:
Если в течение 3 секунд от целевой системы не будет получен ответ, то для всех запросов возникает тайм-аут, и в выводе команды указывается звездочка (*).
# traceroute chuys trying to get source for chuys source should be 9.53.155.187 traceroute to chuys.austin.ibm.com (9.53.155.188) from 9.53.155.187 (9.53.155.187), 30 hops max outgoing MTU = 1500 1 * * * 2 * * * 3 * * * ^C#
Если предположительно ошибка связана с каналом связи, то увеличьте значение тайм-аута с помощью флага -w. Кроме того, возможно, хотя и маловероятно, что все порты были заняты. Попробуйте изменить номера портов и повторите запрос.
Ниже приведен другой пример вывода команды:
# traceroute mysystem.university.edu (129.2.130.22) traceroute to mysystem.university.edu (129.2.130.22), 30 hops max 1 helios.ee.lbl.gov (129.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.university.edu (129.2.216.1) 39 ms 19 ms 39 ms 3 lilac-dmc.university.edu (129.2.215.1) 19 ms 39 ms 19 ms 4 ccngw-ner-cc.university.edu (129.2.135.23) 39 ms 40 ms 19 ms 5 ccn-nerif35.university.edu (129.2.167.35) 39 ms 39 ms 39 ms 6 csgw/university.edu (129.2.132.254) 39 ms 59 ms 39 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 rip.university.EDU (129.2.130.22) 59 ms! 39 ms! 39 ms!
В данном примере половина из 12 промежуточных шлюзов (13 узел - это целевая система) не указаны в выводе. Фактически эти узлы не являлись шлюзами. Целевой хост скопировал значение TTL из полученной дейтаграммы в свой ответ ICMP, поэтому этот ответ был удален на обратном пути. Поскольку узлы ICMP не отправляют друг другу сообщения, никакого извещения не было получено. Наличие ! (восклицательный знак) после каждого поля, указывающего время оборота пакета, говорит о несовместимости программного обеспечения. (Такая ошибка была обнаружена путем отправки пробного пакета с помощью команды traceroute по маршруту вдвое большей длины. Маршрут к целевому хосту на самом деле содержал только семь промежуточных узлов.)
Существуют различные средства для получения информации о работе сети. Некоторые из них входят в состав операционной системы. Для работы других требуется специальное аппаратное обеспечение. Для получения подробной информации о передаче отдельных пакетов по сети можно воспользоваться демоном iptrace и командой ipreport. Для применения демона iptrace в операционной системе версии 4 необходимо установить набор файлов bos.net.tcp.server. Этот набор файлов содержит демон iptrace и некоторые другие полезные команды, в частности, trpt и tcdump. Демон iptrace разрешено запускать только пользователю root.
По умолчанию демон iptrace включает трассировку для всех пакетов. С помощью опции -a можно исключить пакеты ARP. Другие опции позволяют трассировать только пакеты, полученные от определенного хоста (-s), отправленные определенному хосту ( -d) или соответствующие определенному протоколу (-p). Поскольку на работу демона iptrace затрачивается значительное процессорное время, рекомендуется максимально сократить число пакетов, для которых включается трассировка.
Поскольку программа iptrace является демоном, ее нужно запускать с помощью команды startsrc, а не напрямую из командной строки. В этом случае будет проще управлять работой командой и ее завершением. Ниже приведен пример вызова этой команды:
# startsrc -s iptrace -a "-i tr0 /home/user/iptrace/log1"
Данная команда запускает демон iptrace для трассировки всех пакетов, передаваемых через интерфейс Token-Ring, tr0. Информация трассировки будет записана в файл /home/user/iptrace/log1. Для того чтобы завершить работу демона, вызовите следующую команду:
# stopsrc -s iptrace
Если демон iptrace был запущен без помощи команды startsrc, то для завершения его работы определите ИД процесса демона с помощью команды ps и убейте процесс с помощью команды kill.
Команда ipreport служит для форматирования файла протокола. Отформатированный протокол записывается в стандартный вывод. Различные опции позволяют распознавать и форматировать пакеты RPC (-r), присвоить каждому пакету номер (-n) и добавить к каждой строке префикс из трех символов, обозначающий протокол (-s). Ниже приведен пример вызова команды ipreport для форматирования только что созданного файла log1, принадлежащего пользователю root:
# ipreport -ns log1 >log1_formatted
Результатом выполнения этой команды будет последовательность отчетов о пакетах, как в приведенных ниже примерах. Первым указывается пробный пакет команды ping. Рекомендуется обратить внимание на следующие поля:
Номер пакета 131 TOK: =====( пакет отправлен через интерфейс tr0 )=====пятница 14 января 2000 г. 08.42.07 TOK: пакет 802.5 TOK: заголовок MAC 802.5: TOK: поле управления доступом =0, поле управления кадрами = 40 TOK: [ src = 90:00:5a:a8:88:81, dst = 10:00:5a:4f:35:82] TOK: поле управления маршрутизацией = 0830, маршрут из 3 сегментов TOK: сегменты маршрута [ ef31 ce61 ba30 ] TOK: Заголовок 802.2 LLC: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 129.35.145.140 > (alborz.austin.ibm.com) IP: < DST = 129.35.145.135 > (xactive.austin.ibm.com) IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=38892, ip_off=0 IP: ip_ttl=255, ip_sum=fe61, ip_p = 1 (ICMP) ICMP: icmp_type=8 (ECHO_REQUEST) icmp_id=5923 icmp_seq=0 ICMP: 00000000 2d088abf 00054599 08090a0b 0c0d0e0f |-.....E.........| ICMP: 00000010 10111213 14151617 18191a1b 1c1d1e1f |................| ICMP: 00000020 20212223 24252627 28292a2b 2c2d2e2f | !"#$%&'()*+,-./| ICMP: 00000030 30313233 34353637 |01234567 |
Ниже приведен фрагмент операции ftp. Размер IP-пакета совпадает с размером MTU этой сети (1492 байт).
Номер пакета 501
TOK: =====( пакет получен через интерфейс tr0 )=====пятница 10 декабря 1999 года 08.42.51
TOK: пакет 802.5
TOK: Заголовок MAC 802.5:
TOK: поле управления доступом =18, поле управления кадрами = 40
TOK: [ src = 90:00:5a:4f:35:82, dst = 10:00:5a:a8:88:81]
TOK: поле управления маршрутизацией = 08b0, маршрут из 3 сегментов
TOK: сегменты маршрута [ ef31 ce61 ba30 ]
TOK: Заголовок 802.2 LLC:
TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP: < SRC = 129.35.145.135 > (xactive.austin.ibm.com)
IP: < DST = 129.35.145.140 > (alborz.austin.ibm.com)
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=1492, ip_id=34233, ip_off=0
IP: ip_ttl=60, ip_sum=5ac, ip_p = 6 (TCP)
TCP: <исходный порт=20(данные ftp), целевой порт=1032 >
TCP: th_seq=445e4e02, th_ack=ed8aae02
TCP: th_off=5, flags<ACK |>
TCP: th_win=15972, th_sum=0, th_urp=0
TCP: 00000000 01df0007 2cd6c07c 00004635 000002c2 |....,..|..F5....|
TCP: 00000010 00481002 010b0001 000021b4 00000d60 |.H........!....`|
--------- Lots of uninteresting data omitted -----------
TCP: 00000590 63e40000 3860000f 4800177d 80410014 |c...8`..H..}.A..|
TCP: 000005a0 82220008 30610038 30910020 |."..0a.80.. |
Команда ipfilter выдает таблицу заголовков операций, полученных из файла вывода ipreport. Кроме того, выдается некоторая информация о запросах NFS и ответах на эти запросы.
Для того чтобы узнать, установлена ли команда ipfilter в системе, вызовите следующую команду:
# lslpp -lI perfagent.tools
Ниже приведен пример вызова этой команды:
# ipfilter log1_formatted
Распознаны следующие заголовки операций: udp, nfs, tcp, ipx, icmp. Команда ipfilter создает отчеты трех типов:
Описанные в этом разделе команды позволяют получить примерно такую же информацию, что и команда netstat -v. С их помощью можно сбросить статистику адаптера (-r) и получить более подробный отчет, чем предоставляется командой netstat -v (опция -d).
Команда entstat позволяет просмотреть статистическую информацию, собранную указанным драйвером адаптера Ethernet. Помимо общей информации можно просмотреть дополнительную информацию об указанном устройстве. Для этого служит опция -d. С ее помощью можно просмотреть полную статистическую информацию. Если флаги не заданы, то выдается только общая статистическая информация.
Команда entstat вызывается командой netstat с флагом -v. Команда netstat вызывает команду entstat без флагов.
# entstat ent0
-------------------------------------------------------------
Статистика по адаптеру Ethernet (ent0) :
Тип устройства: Адаптер Ethernet PCI 10/100 Мб/с фирмы IBM (23100020)
Аппаратный адрес: 00:60:94:e9:29:18
Истекшее время: 0 дней, 0 часов, 0 минут, 0 секунд
Статистика по передаче: Статистика по приему:
-------------------- -------------------
Пакетов: 0 Пакетов: 0
Байт: 0 Байт: 0
Прерываний: 0 Прерываний: 0
Ошибок передачи: 0 Ошибок приема: 0
Отброшено пакетов: 0 Отброшено пакетов: 0
Пакеты с ошибками: 0
Макс. число пакетов в прогр. очереди передачи: 0
Переполнений прогр. очереди передачи: 0
Общая длина прогр. и аппар. очередей передачи: 0
Пакет оповещения: 0 Пакет оповещения: 0
Многоцелевые пакеты: 0 Многоцелевые пакеты: 0
Несущая частота не обнаружена: 0 Ошибка CRC: 0
Выход за нижнюю границу DMA: 0 Выход за верхнюю границу DMA: 0
Ошибки потери CTS: 0 Ошибки выравнивания: 0
Макс.число конфликтов: 0 Ошибки из-за отсутствия ресурсов: 0
Конфликты опоздания: 0 Конфликты при получении: 0
Задержки: 0 Слишком короткие пакеты: 0
Проверка SQE: 0 Слишком длинные пакеты: 0
Ошибки ожидания: 0 Пакеты, отброшенные адаптером: 0
Число одиночных конфликтов: 0 Начальный счетчик получателя: 0
Число множественных конфликтов: 0
Текущая длина аппар. очереди передачи: 0
Общая статистика:
-------------------
Ошибки отсутствия mbuf: 0
Число перезапусков адаптера: 0
Флаги драйвера: Up Broadcast Running
Simplex 64BitSupport
в приведенном выше отчете стоит обратить внимание на следующее:
Обратите внимание, что в приведенном примере адаптер справляется с нагрузкой, так как нет ошибок приема. Эти ошибки иногда возникают в перегруженной сети, если по ней передаются только неполные пакеты. Неполные пакеты обычно передаются повторно, однако засчитываются как ошибка приема.
Если значение Переполнений прогр. очереди передачи отлично от нуля, то значение Макс. число пакетов в прогр. очереди передачи отражает максимальный размер очереди передачи данного адаптера ( xmt_que_size).
Примечание: Указанные значения будут соответствовать аппаратной очереди, если адаптер не поддерживает программную очередь передачи. Если зафиксированы случаи переполнения очереди передачи, увеличьте ограничения на размер аппаратной или программной очереди драйвера.
Если в системе недостаточно ресурсов для приема пакетов, то значение Отброшено пакетов: будет отлично от нуля, а в качестве причины будет указано Недостаточно буферов приема, Ошибки из-за нехватки ресурсов или аналогичное значение.
Истекшее время указывает время, прошедшее с момента предыдущего сброса статистики. Для сброса статистики служит команда entstat -rимя-адаптера.
Для получения аналогичной информации об интерфейсах Token-Ring, FDDI и ATM служат команды tokstat, fddistat и atmstat.
Команда tokstat выводит статистическую информацию, собранную указанным драйвером устройства Token-Ring. Помимо статистики, собранной драйвером устройства, пользователь может просмотреть дополнительную информацию об указанном устройстве. Если флаги не заданы, то выводится только статистика, собранная драйвером устройства.
Эта команда вызывается командой netstat с флагом -v. Команда netstat вызывает команду tokstat без флагов.
Вывод команды tokstat tok0 аналогичен выводу команды entstat.
Команда fddistat выводит статистическую информацию, собранную указанным драйвером устройства FDDI. Помимо статистики, собранной драйвером устройства, пользователь может просмотреть дополнительную информацию об указанном устройстве. Если флаги не заданы, то выводится только статистика, собранная драйвером устройства.
Эта команда вызывается командой netstat с флагом -v. Команда netstat вызывает команду fddistat без флагов.
Вывод команды fddistat fddi0 аналогичен выводу команды entstat.
Команда atmstat выводит статистическую информацию, собранную указанным драйвером устройства ATM. Помимо статистики, собранной драйвером устройства, пользователь может просмотреть дополнительную информацию об указанном устройстве. Если флаги не заданы, то выводится только статистика, собранная драйвером устройства.
Вывод команды atmstat atm0 аналогичен выводу команды entstat.
Команда no позволяет просмотреть и изменить текущие значения параметров сети.
Список атрибутов команды no приведен в разделе Параметры сети.
Некоторые атрибуты сети можно изменить в любой момент. Другие атрибуты изменяются во время загрузки. Из нужно изменить до загрузки расширения ядра netinet.
Примечание: Изменения, внесенные с помощью команды no, действуют до следующей загрузки системы. После загрузки всем параметрам присваиваются значения по умолчанию. Для внесения изменений на постоянной основе добавьте команду no в файл /etc/rc.net.
Если в системе применяется конфигурация сети типа Беркли, то поместите атрибуты в начало файла /etc/rc.bsdnet. При работе с системой SP измените файл tuning.cust, как описано в руководстве RS/6000 SP: Installation and Relocation.
Примечание: Команда no не проверяет, что указанное значение параметра допустимо. Вызов команды no с недопустимым значением параметра может нарушить работу системы.
В приведенных ниже разделах описаны атрибуты команды no и способы их настройки.