Cisco ip input грузит процессор

Обновлено: 07.07.2024

В этой статье объясняются общие симптомы и причины высокой загруженности ЦП в маршрутизаторах Cisco и даются указания и решения по устранению неполадок. Данный документ не ограничен отдельными версиями программного и аппаратного обеспечения.

Симптомы высокой загруженности ЦП

Ниже перечислены распространенные симптомы высокой загрузки ЦП. Если присутствует любой из описанных признаков, для устранения неполадки выполните действия, описанные в данном документе.

Команда show processes cpu выдает высокое значение в процентах
Медленная работа

Службы маршрутизатора не отвечают, например:

задержка ответа Telnet или невозможно получить доступ к маршрутизатору по протоколу Telnet
медленный ответ на консоли
медленный ответ на запрос команды ping или вообще нет ответа
маршрутизатор не отправляет обновления маршрутизации другим маршрутизаторам

Первоначальное устранение неполадок

Как только будет замечен какой-нибудь из указанных выше симптомов, выполните следующее:

Проверьте наличие проблем, связанных с безопасностью. Как правило, высокая загрузка ЦП бывает обусловлена именно проблемами такого рода, например функционированием вредоносной программы (червя или вируса) в сети. Если последние изменения в сети производились давно, это наиболее вероятная причина высокой загрузки ЦП. Обычно для ограничения негативных последствий этой проблемы достаточно добавить строки в списки доступа.
Убедитесь, что все команды отладки в маршрутизаторе выключены, выполнив команду undebug all или no debug all.
Удается выполнить команды show на маршрутизаторе? Если да, немедленно начните собирать дополнительные сведения, используя эти команды.
Маршрутизатор недоступен? Удается воспроизвести эту проблему? Если да, выключите и включите маршрутизатор, а перед воспроизведением проблемы настройте команду scheduler interval 500. В результате выполнение процессов с низким приоритетом будет запланировано с интервалом в 500 миллисекунд, благодаря чему появится время для запуска некоторых команд, даже если ЦП используется на все 100%. На оборудовании Cisco серий 7200 и 7500 используйте команду scheduler allocate 3000 1000.
Проявляет маршрутизатор признаки высокой загрузки ЦП в течение кратких и непрогнозируемых периодов? Если да, регулярно собирайте выходные данные команды show processes cpu, которые отображают причину высокой загрузки ЦП, если она вызвана прерываниями или отдельным процессом.
Выяснение причин и решение проблемы

Используйте команду show processes cpu, чтобы определить, чем вызвана высокая загрузка ЦП, прерываниями или процессами.

Высокая загруженность ЦП процессами

Отладка также является очень полезной при устранении проблемы высокой загруженности ЦП процессами. Однако отладку следует выполнять очень осторожно, поскольку это может привести к еще большей загрузке ЦП. Отладка будет безопасной и эффективной при выполнении следующих предварительных условий:

Все журналы регистрации, за исключением журнала регистрации сведений для буферов, должны быть отключены или уровень важности протоколируемых в них сведений должен быть понижен с 7 (отладка) до 6 (информационный) или ниже при помощи соответствующей команды настройки logging destination[уровень важности]. Сведения о включенных журналах регистрации и уровнях важности протоколируемых в них сведений содержатся в строках заголовка выходных данных команды show logging exec.
Размер буфера регистрации необходимо увеличить, чтобы он вмещал всю необходимую информацию. Дополнительные сведения см. в описании команды глобальной настройки logging buffered.
Чтобы облегчить восприятие и понимание отладки, следует включить временные отметки в миллисекундах, а также дату и время. Дополнительную информацию см. в описании команды глобальной настройки service timestamps.

Команды для получения дополнительной информации

Эти команды позволяют получить дополнительные сведения о проблеме:

Команда show processes cpu

Это пример заголовка команды show processes cpu:

CPU utilization for five seconds: X%/Y%; one minute: Z%; five minutes: W% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

В следующей таблице описаны поля этого заголовка:

Примечание: Суммарное использование ЦП не следует интерпретировать как показатель способности маршрутизатора коммутировать большее число пакетов. В маршрутизаторах Cisco 7500 универсальные интерфейсные процессоры (VIP) и процессоры маршрутизации и коммутации (RSP) не сообщают о линейном использовании ЦП. Почти половина мощности коммутации в пакетах в секунду реализуется после 90-95% загрузки ЦП.

Команда show interfaces switching

Эта команда используется для определения активных путей коммутации на интерфейсах

Ниже приведен пример выходных данных команды show interfaces switching для одного интерфейса:

Throttle count	0
Drops	RP	0	SP	0
SPD Flushes	Fast	0	SSE	0
SPD Aggress	Fast	0	0
SPD Priority	Inputs	0	Drops	0
Protocol	Path	Pkts In	Chars In	Pkts Out	Chars Out
Other	Process	0	0	595	35700
Cache misses	0
Fast	0	0	0	0
Auton/SSE	0	0	0	0
IP Process	4	456	4	456
Cache misses	0
Fast	0
Auton/SSE	0	0	0	0
IPX	Process	0	0	2	120
Cache misses	0
Fast	0	0	0	0
Auton/SSE	0	0	0	0
Trans. Bridge	Process	0	0	0	0
Cache misses	0
Fast	11	660	0	0
Auton/SSE	0	0	0	0
DEC MOP	Process	0	0	10	770
Cache misses	0
Fast	0	0	0	0
Auton/SSE	0	0	0	0
ARP	Process	1	60	2	120
Cache misses	0
Fast	0	0	0	0
Auton/SSE	0	0	0	0
CDP	Process	200	63700	100	31183
Cache misses	0
Fast	0	0	0	0
Auton/SSE	0	0	0	0

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

Команда show interfaces stat

Эта команда является объединенной версией команды show interfaces switching. Ниже приведен пример выходных данных для одного интерфейса:

Ethernet0	Switching path	Pkts In	Chars In	Pkts Out	Chars Out
Processor	52077	12245489	24646	3170041
Route cache	0	0	0	0
Distributed cache	0	0	0	0
Total	52077	12245489	24646	3170041

Выходные данные команды show interfaces stat на разных платформах отличаются: они зависят от доступных и настроенных коммутируемых путей.

Команда show ip nat translations

Команда show ip nat translations служит для отображения активных на маршрутизаторе трансляций преобразования сетевых адресов (NAT). Каждая активная трансляция генерирует прерывания ЦП и влияет на суммарное использование ЦП маршрутизатора. Большое число трансляций может повлиять на производительность маршрутизатора.

Ниже приведен пример выходных данных команды show ip nat translations:

Inside global	Inside local	Outside local	Outside global
---	172.16.131.1	10.10.10.1	---

Команда show align

Эта команда доступна только на платформах на базе RISC-процессоров с сокращенным набором команд. На этих платформах ЦП может корректировать нарушения выравнивания для чтения и записи в памяти. Ниже приведен пример выходных данных:

Alignment data for:
4500 Software (C4500-DS40-M), Version mis-aligned RELEASE SOFTWARE (fc1)
Compiled Tue 31-Mar-98 15:05 by jdoe

Total Corrections 33911, Recorded 2, Reads 33911, Writes 0

Initial Initial
Address Count Access Type Traceback
40025F4D 15561 16bit read 0x606F4A7C 0x601C78F8 0x6012FE94 0x600102C0
40025F72 18350 32bit read 0x606FB260 0x6013113C 0x600102C0 0x60010988

Команда show version

В целях отслеживания проблем высокой загрузки ЦП, важной частью выходных данных этой команды является версия программного обеспечения Cisco IOS, платформа, тип ЦП и время работы маршрутизатора. Щелкните эту ссылку, чтобы ознакомиться с подробным описанием команды show version.

Команда show log

Есть вопросы?
Обращайтесь в "Аквилон-А", чтобы узнать подробности и получить именно то, что вам требуется.

При высокой загрузке ЦП выполните сначала команду show processes cpu. Выходные данные показывают загрузку ЦП коммутатора, а также потребление ресурсов ЦП каждым процессом.

В этих выходных данных общая загрузка ЦП составляет 57 процентов, а загрузка ЦП прерываниями — 48 процентов. Эти показатели отображаются полужирным шрифтом. Коммутация трафика прерываний процессором приводит к загрузке ЦП прерываниями. В выходных данных команды перечисляются процессы, которые приводят к разнице между этими двумя загрузками. В данном случае причиной является процесс SNMP.

Чтобы не вникать в механизмы, наймите специалистов по обслуживанию сетей. В механизме управления, который работает под управлением CatOS, выходные данные выглядят так:

В этих выходных данных первый процесс — Kernel and Idle — показывает простой в использовании ЦП. Этот процесс обычно наверху, если какие-либо другие процессы не потребляют циклы ЦП. В этом примере процесс SptBpduRx приводит к повышению загрузки ЦП.

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

Служебные программы и средства для определения трафика, поступающего на ЦП

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

Системное программное обеспечение Cisco IOS

В ПО Cisco IOS процессор коммутатора в механизме управления называется SP, а MSFC называется RP.

Команда show interface дает основную информацию о состоянии интерфейса и скорости трафика на интерфейсе. В этой команде также предусмотрены счетчики ошибок.

В этих выходных данных можно увидеть, что входящий трафик коммутируется на 3 уровне вместо коммутации 2 уровня. Это показывает, что трафик поступает на ЦП.

Команда show processes cpu показывает, являются ли эти пакеты пакетами обычного трафика или пакетами управления.

Если пакеты коммутируются процессом, то будет видно, что процесс IP Input повышается. Чтобы увидеть эти пакеты, выполните такую команду:

show buffers input-interface

Если трафик коммутируется прерываниями, то эти пакеты нельзя увидеть с помощью команды show buffers input-interface. ИТ аутсорсинг это возможность не вникать в скучную информацию. Чтобы увидеть пакеты, поступающие на ЦП для коммутации на уровне прерываний, можно выполнить захват SPAN порта RP.

В этом году мы опубликовали две статьи, связанные со сравнением функциональности маршрутизаторов и межсетевых экранов компании Cisco, а также с обзором разделения control и data plane в сетевом оборудовании. В комментариях к этим статьям был затронут вопрос производительности сетевого оборудования. А именно как зависит производительность маршрутизаторов Cisco разных поколений от включения на них тех или иных сервисов. Так же обсуждалась тема производительности межсетевых экранов Cisco ASA. В связи с этим возникло желание посмотреть на эти вопросы с практической стороны, подкрепив известные моменты цифрами. О том, что получилось и, что получилось не очень, расскажу под катом.

Под производительностью будем подразумевать пропускную способность устройства, измеряемую в Мбит/с. Стенд для тестирования представлял из себя два ноутбука, с установленной программой iPerf3. Методика испытания – достаточно проста. iPerf3 запускался в режиме передачи пакетов по протоколу TCP. Использовалось 5 потоков. Я не ставил перед собой цели определить реальную производительность устройств. Для этой задачи необходима более сложная экипировка, так как требуется воссоздавать паттерны трафика реальной сети. Да и мерить нужно было бы количество обрабатываемых пакетов. У нас же основной задачей была оценка влияния использования различных сервисов на работу устройства, а также сравнение результатов, полученных на различных устройствах. Таким образом, выбранный инструментарий на первый взгляд казался достаточно подходящим для поставленных задач.

Cisco Integrated Services Router (ISR) Generation 1 и 2

Для начала из коробки были взяты два младших маршрутизатора Cisco 871 и 881. Это маршрутизаторы разных поколений (871 более старый – G1, а 881 более новый – G2), которые обычно ставятся в небольшие офисы, например, в удалённые филиалы компании.

Исследуемые маршрутизаторы имеют сходные черты в плане программной и аппаратной архитектуры: операционная система – Cisco IOS, «мозг» устройств – SoC MPC 8272 в 871 и SoC MPC 8300 в 881.

Маршрутизация с использованием технологии Cisco Express Forwarding (CEF).
Маршрутизация без использования оптимизирующих технологий (Process Switching).
Маршрутизация (CEF) и применённый список доступа (ACL) на одном из интерфейсов.
Маршрутизация (CEF) и ACL на одном из интерфейсов с опцией log.
Маршрутизация (CEF) и включённая служба трансляции адресов (NAT*).
Маршрутизация (CEF) и включенные сервисы межсетевого экранирования (CBAC для 871 и ZPF для 881).
Маршрутизация (CEF), МСЭ и NAT.

Для более наглядного сравнения данные по разным устройствам нанесены на один график (рисунок 1).

Так как интерфейсы на устройствах имеют тип FastEthernet, максимальная пропускная способность точка-точка, полученная через iPerf3, не превышала 95 Мбит/с. При этом загрузка ЦПУ для некоторых режимов тесетирования не достигала своих пиковых значений, а значит цифра 95 Мбит/с для этих маршрутизаторов не предел.
Маршрутизатор 881 выглядит лучше, так как имеет более продвинутую аппаратную начинку (в первую очередь процессор общего назначения, далее ЦПУ).
Как и следовало ожидать, мы видим заметную деградацию производительности при включении сервисов.
При отключении CEF мы имеем существенное уменьшение производительности, так как маршрутизатор начинает обрабатывать каждый пакет не самым оптимальным образом.
Включение опции log в ACL приводит к повышению нагрузки на устройство (загрузка ЦПУ в этом случае составляет 99%), что негативно сказывается на производительности. Обусловлено это тем фактом, что опция log заставляет маршрутизатор обрабатывать каждый пакет, попадающий в отмеченную строчку ACL, в режиме Process Switching, что существенно увеличивает нагрузку на процессор.

Общая загрузку ЦПУ составляет 47%. Из них 42% уходит на обработку прерываний, вызванных передачей пакетов. Прерывания при передаче пакетов бывают двух типов: прерывание получения и прерывание передачи пакета. Прерывание получения пакета инициируется интерфейсным процессором, когда пакет получен через интерфейс маршрутизатора и он готов к обработке. Получив такое прерывание ЦПУ прекращает обработку текущих процессов, и начинает выполнять обработку пакета. Так как включен режим CEF, ЦПУ принимает решение, куда передать пакет на основании таблиц CEF (FIB и Adjacency) во время прерывания. Т.е. ему не требуется отправлять пакет на процессорную обработку, а значит существенно экономятся процессорные мощности. В связи с этим на процессы в маршрутизаторе тратится лишь 5% загрузки ЦПУ. Прерывание отправки пакета передаётся на ЦПУ, когда пакет был отправлен интерфейсным процессором дальше по каналам связи. ЦПУ реагирует на это прерывание обновлением счётчиков и освобождением памяти, выделенной для хранения пакета. В плане вклада в общую загрузку устройства данное прерывание менее интересно.

Маршрутизация в режиме Process Switching:

Теперь общая загрузка ЦПУ составляет 99%. Причём только 27% уходит на прерывания. Остальные 72% тратятся на выполнение процессов. Процесс IP Input забирает практически 70% процессорного времени. Именно этот процесс отвечает за процессорную обработку пакетов, т.е. тех пакетов, которые не могут быть обработаны во время прерывания (например, отключен CEF или в его таблицах нет нужной информации для передачи, пакеты адресованы непосредственно маршрутизатору или являются широковещательным трафиком и пр.). А так как в нашем примере отключены CEF и Fast Switching (об этом методе я не упоминал в силу его неактуальности), после того как к ЦПУ пришло прерывание получения пакета, ЦПУ отправляет пакет на процессорную обработку. Прерывание завершается и ЦПУ обрабатывает пакет непосредственно в рамках одного из своих процессов. Поэтому мы и видим такую утилизацию ЦПУ процессом IP Input.

Ещё интересно будет посмотреть на загрузку ЦПУ в случае ACL с опцией log.

Опция log в ACL заставляет маршрутизатор каждый пакеты отправлять на процессорную обработку, признаком чего, как и в предыдущем примере, является высокая утилизация ЦПУ процессом IP Input.

Cisco ASA 5500

Давайте посмотрим теперь на такое устройство как межсетевой экран Cisco ASA 5505. Можно сказать, что ASA 5505 – это аналогичное маршрутизатору Cisco 881 устройство в плане позиционирования (для небольших офисов и филиалов). Эти устройства примерно из одного ценового сегмента и обладают относительно сходными аппаратными характеристиками. В ASA 5505 используется ЦПУ AMD Geode с тактовой частотой 500 MHz. Самое главное отличие –операционная система. В ASA 5505 используется ASA OS. Про различия между маршрутизаторами и ASA в плане функциональности мы говорили в отдельной статье. Посмотрим теперь на производительность ASA и влияния на неё различных сервисов.

Межсетевой экран.
Межсетевой экран и включённая служба трансляции адресов (NAT).
Межсетевой экран и ACL на одном из интерфейсов с опцией log.

Из диаграммы видно, пропускная способность ASA 5505 во всех режимах работы ограничена лишь техническими аспектами стенда. Причём, если мы посмотрим на загрузку ЦПУ, то для всех вариантов она практически идентична:

При относительно схожих ценовых и аппаратных параметрах ASA 5505 предоставляет большую производительность, чем маршрутизатор 881.
Производительность ASA практически не зависит от сервисов (во всяком случае в рамках данного стенда её выявить не удалось).
Опция логирования (log) в ACL не приводит к деградации производительности. Обусловлено этой спецификой реализаций функции маршрутизации в устройстве.

Cisco ISR 4000

Идём дальше. Предлагаю посмотреть, как обстоят дела с влиянием сервисов на производительность маршрутизаторов Cisco ISR 4000. Это самая новая линейка маршрутизаторов Cisco для небольших и средних инсталляций. Как мы помним, в этих маршрутизаторах используется операционная система Cisco IOS XE, которая умеет работать в многопоточном режиме. С точки зрения аппаратной начинки, в этих маршрутизаторах используются многоядерные процессоры.

И так достаём из коробки самый младший Cisco ISR 4000 – 4321. Активируем на нём performance license, чтобы получить заявленную максимальную производительность 100 Мбит/с, и начинаем тестировать. Важно отметить, что на маршрутизаторах ISR 4000 всегда используется шейпер, ограничивающий максимальную производительность устройства. Используется два порога: базовая (для 4321 – это 50 Мбит/с) и расширенная (для 4321 – это 100 Мбит/с; активируется лицензией performance license) производительности. Такая схема работы направлена на получение прогнозируемых значений производительности устройства, не позволяя «захлёбывать» от большого количества трафика.

Для начала проверяем производительность чистой маршрутизации в режиме CEF без дополнительных сервисов. Запускаем iPerf3 и получаем 95 Мбит/с. Ожидаемо. Смотрим в этот момент на загрузку ЦПУ:

Вот это результат! Загрузка ЦПУ 1%. Круто! Но не всё так идеально. Понимание данного феномена приходит после более детального изучения специфики работы IOS XE.

IOS XE – это операционная система, созданная на базе Linux’а, тщательно допиленного и оптимизированного вендором. Традиционная операционная система Cisco IOS запускается в виде отдельного Linux процесса (IOSd). Самое интересное заключается в том, что в IOS XE мы имеем отдельный основной процесс, выполняющий функции data plane. Т.е. мы имеем чёткое разделение control и data plane на программном уровне. Процесс, отвечающий за control plane, называется linux_iosd-imag. Это собственно и есть привычным нам IOS. Процесс, отвечающий за data plane, называется qfp-ucode-utah. QFP, знакомо? Сразу вспоминаем про сетевой процессор QuantumFlow Processor в маршрутизаторах ASR 1000. Так как изначально IOS XE появился именно на этих маршрутизаторах, процесс, отвечающий за передачу пакетов, получил аббревиатуру qfp в своём названии. В дальнейшем для ISR 4000, видимо, ничего менять не стали, с одной лишь разницей, что в ISR 4000 QFP является виртуальным (выполняется на отдельных ядрах процессора общего назначения). Кроме озвученных процессов в IOS XE присутствуют и другие вспомогательные процессы.

Таким образом, чтобы посмотреть на сколько загружены процессорные мощности, анализируем вывод следующих команд, специфичных для IOS XE:

В нашем маршрутизаторе используется четыре ядра (CPU 0, 1, 2, и 3). Команда позволяет нам получить информацию по загрузке каждого из них.

Примечание

Увидеть аппаратную начинку маршрутизатора можно выводом стандартной для Linux информации из файла dmesg: more flash:/tracelogs/dmesg.

В маршрутизаторе ISR 4321 используется процессор:
CPU0: Intel® Atom(TM) CPU C2558 @ 2.40GHz stepping 08

Следующая команда позволяет нам увидеть утилизацию процессорных мощностей различными процессами:

В данном примере, IOS съедает всего 2%, а QFP – 150% (что эквивалентно утилизации одно ядра полностью и ещё одного на половину).

Так, что же в итоге показывает тогда команда «show processes cpu»? Она выводит загрузку виртуального ЦПУ, который был выделен процессу IOSd. Под данный процесс на маршрутизаторах ISR 4000 выделяется одно из ядер ЦПУ.

Из всего этого можно сделать вывод, что в IOS XE архитектура обработки пакетов существенно изменилась по сравнению с обычным IOS. IOS больше не занимается обработкой абсолютно всех пакетов. Данным процессом обрабатываются лишь те пакеты, которые требуют процессорной обработки. Но даже в этом случае в IOS XE используется более новый механизм Fastpath, который реализует передачу пакетов для процессорной обработки посредствам отдельного потока внутри IOSd, а не через прерывания. Прерывания в IOSd возникают только, когда не возможна обработка через Fastpath.

Маршрутизация с использованием технологии CEF.
Маршрутизация и применённый список доступа (ACL) на одном из интерфейсов.
Маршрутизация (CEF) и ACL на одном из интерфейсов с опцией log.
Маршрутизация (CEF) и включённая служба трансляции адресов NAT.
Маршрутизация (CEF) и включенные сервисы межсетевого экранирования (ZPF).
Маршрутизация (CEF), МСЭ и NAT.

Результаты тестирования представлены на рисунке 3. Для большей наглядности на один график нанесены значения пропускной способности (а они у нас во всех случаях одинаковы) и загрузку ЦПУ процессом QFP. Процесс IOSd не интересен в силу того, что во всех режимах загрузка виртуального ЦПУ внутри IOSd минимальна – 1%.

При проведении тестирования выявить зависимость производительности маршрутизатора ISR 4321 от включения сервисов не удалось. Есть небольшое повышение загрузки CPU, но совсем незначительное. Также стоит отметить, что включение опции log в ACL больше не приводит к драматическим потерям в производительности, так как пакет не отправляется на процессорную обработку.

На примере нескольких устройств разных поколений и типов мы попытались рассмотреть, как зависит производительность от включения различных сервисов. В целом полученные результаты укладываются в ранее известные факты. Америки мы не открыли. Краткие выводы, полученные в результате тестирования, можно сформулировать так:

Симптомы высокой загруженности ЦП

Команда show processes cpu выдает высокое значение в процентах
Медленная работа
Службы маршрутизатора не отвечают, например:
- задержка ответа Telnet или невозможно получить доступ к маршрутизатору по протоколу Telnet
- медленный ответ на консоли
- медленный ответ на запрос команды ping или вообще нет ответа
- маршрутизатор не отправляет обновления маршрутизации другим маршрутизаторам
Первоначальное устранение неполадок

Как только будет замечен какой-нибудь из указанных выше симптомов, выполните следующее:
- Проверьте наличие проблем, связанных с безопасностью. Как правило, высокая загрузка ЦП бывает обусловлена именно проблемами такого рода, например функционированием вредоносной программы (червя или вируса) в сети. Если последние изменения в сети производились давно, это наиболее вероятная причина высокой загрузки ЦП. Обычно для ограничения негативных последствий этой проблемы достаточно добавить строки в списки доступа.
Используйте команду show processes cpu. чтобы определить, чем вызвана высокая загрузка ЦП, прерываниями или процессами.

Высокая загруженность ЦП процессами

Отладка также является очень полезной при устранении проблемы высокой загруженности ЦП процессами. Однако отладку следует выполнять очень осторожно, поскольку это может привести к еще большей загрузке ЦП. Отладка будет безопасной и эффективной при выполнении следующих предварительных условий:
- Все журналы регистрации, за исключением журнала регистрации сведений для буферов, должны быть отключены или уровень важности протоколируемых в них сведений должен быть понижен с 7 (отладка) до 6 (информационный) или ниже при помощи соответствующей команды настройки logging destination[уровень важности]. Сведения о включенных журналах регистрации и уровнях важности протоколируемых в них сведений содержатся в строках заголовка выходных данных команды show logging exec.
Команды для получения дополнительной информации

Эти команды позволяют получить дополнительные сведения о проблеме:

Команда show processes cpu

CPU utilization for five seconds: X%/Y%; one minute: Z%; five minutes: W% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

Читайте также: