ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 03.02.2024
Просмотров: 36
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Использование памяти процессами.
Модификация команды show process — show process memory — позволяет получить информацию об использовании памяти отдельными процессами. Данная команда поможет быстро определить доступный объем памяти и объем памяти, занятой процессами.
Результат выполнения команды show process memory приведен в примере 1.8.
Пример 1.8.
Первая строка вывода команды в примере 1.8 отображает суммарный объем памяти в пулах, объем свободной и занятой памяти. Данные из первой строки вывода соответствуют статистике для процессорного пула памяти (processor memory pool) и совпадают с выводом команды show memory. Далее вывод команды содержит детальную информацию об использовании памяти каждым процессом, которая рассмотрена более подробно ниже.
*Init* — строка отображает объем выделенной для ядра системы памяти во время инициализации, прежде чем создаются процессы.
*Sched* — отображает память, выделенную планировщиком процессов.
*Dead* — память, выделенная процессами, перешедшими в “мертвую” фазу. Память “мертвых” процессов впоследствии возвращается ядром в соответствующие пулы.
PID — идентификатор процесса.
TTY — консоль, связанная с данным процессом.
Allocated — общий объем памяти, выделенной процессу, с момента его создания.
Freed — объем памяти, освобожденной процессом с момента его создания
Holding — объем памяти, который выделен процессу на текущий момент. Следует отметить, что, поскольку выделенная процессу память может быть освобождена другим процессом, значения величин allocated, freed и holding не находятся в прямой зависимости, т.е. allocated минус freed не всегда равно holding.
Getbufs — общий объем памяти для буферов пакетов, выделенных данному процессу. Пулы пакетных буферов мы рассмотрим ниже, в разделе “Управление пакетными буферами”.
Retbufs — общий объем памяти для усеченных пакетных буферов данного процесса.
Process — имя процесса.
Проблемы, связанные с выделением памяти.
Во всех примерах, рассмотренных выше, мы предполагали, что запрос процесса на выделение памяти всегда обслуживается и память процессу выделяется. Однако это не всегда так. Ресурсы памяти, как и ресурсы центрального процессора, ограничены, поэтому всегда есть вероятность нехватки требуемого объема памяти. Что же происходит в случае отказа подобного рода? В зависимости от того, для чего необходима выделяемая память, процесс может либо продолжать выполняться, либо остановиться и прекратить работу. В любом случае при получении запроса, который менеджер пулов не в состоянии обработать, он выводит предупреждающее сообщение на консоль.
Существуют две причины, по которым запрос на выделение памяти не отрабатывается:
-
Нехватка свободной памяти. -
Свободной памяти достаточно, однако из-за ее фрагментации непрерывный блок необходимого размера выделить невозможно.
Обычно отказы из-за нехватки памяти возникают тогда, когда физически не установлена память для поддержания всех возможностей системы. Существует два варианта решения указанной проблемы: увеличение объема памяти маршрутизатора либо уменьшение затрат ресурсов памяти (уменьшение количества интерфейсов и различных программных возможностей системы). В редких случаях ошибка нехватки памяти может быть связана с утечкой памяти (memory leak) в одном из процессов. Это означает, что процесс постоянно пытается выделить память, однако никогда ее не освобождает, что обычно приводит к расходу всей доступной памяти. Обычно утечки памяти связаны с ошибками в программном обеспечении. Сбои выделения памяти могут также происходить при наличии требуемого объема свободной памяти. Например, рассмотрим вывод команды show memory.
Пример 1.9.
В рассматриваемом примере в системе доступно 20960428 байт свободной памяти. Однако, если попытаться выделить 9000 байт памяти, возникнет ошибка. Чтобы понять, почему так происходит, достаточно взглянуть на значение в колонке Largest. Поскольку на момент выполнения команды show memory максимальный непрерывный блок памяти составляет 8426 байт, выделить 9000 байт нам никак не удастся. Ход событий подобного рода ярко демонстрирует неблагоприятные последствия фрагментации памяти. Память фрагментируется при выделении большого количества блоков маленького размера, которые затем освобождаются таким образом, что менеджеру пулов не удается объединить их в блоки большего размера. Таким образом, когда все большие блоки памяти окажутся разделенными на маленькие фрагменты, начинают проявляться ошибки выделения памяти, связанные с ее фрагментацией. Менеджер пулов спроектирован таким образом, чтобы избегать нежелательной фрагментации памяти, и в большинстве случаев он с этим успешно справляется. Однако в некоторых случаях механизм устранения фрагментации не срабатывает (как в рассмотренном ранее примере).
Менеджер пакетного буфера.
Маршрутизируя пакеты, система должна иметь некоторое пространство памяти для временного хранения пакетов. Обычно для этого создаются буферы памяти, в которых хранятся поступающие пакеты, пока система решает, куда их переправить. Поскольку вся идея операционной системы IOS заключается в маршрутизации пакетов, для работы с буфером пакетов существует специальный менеджер пакетного буфера (packet buffer manager). Он используется системой для создания и последующего управления набором пулов буфера пакетов. Буферы в таких пулах памяти имеют общее название — системные буферы. Менеджер буферного пула предоставляет удобный способ манипуляции набором (или пулом) буферов определенного размера. Несмотря на то что менеджер буферного пула может использоваться для управления любым видом буферных пулов, преимущественно он применяется для манипуляции с буфером пакетов.
Пулы памяти для буферизации пакетов создаются путем выделения памяти из пула (например, процессорного или пула ввода-вывода). Для того чтобы создать пул, менеджер пакетного буфера требует у менеджера пулов выделить блок памяти и затем разделяет его на буферы. Менеджер пакетного буфера создает список всех свободных буферов для их последующего заполнения и освобождения.
Пулы пакетного буфера могут быть либо статическими, либо динамическими. Статический пул создается с фиксированным количеством буферов, т.е. далее по ходу работы дополнительные буферы не выделяются. Динамические пулы создаются с минимальным количеством буферов (так называемые постоянные буферы) с возможностью дальнейшего создания и удаления дополнительных буферов. При необходимости расширения динамического пула буферов менеджер пулов старается немедленно удовлетворить запрос на расширение. Если же немедленно расширить пул не удается, запрос на расширение обрабатывается позднее фоновым процессом менеджера пулов.
Пулы пакетного буфера могут быть общими либо локальными.
-
Общие пулы, как следует из их названия, могут использоваться любым системным процессом. -
Локальные пулы используются лишь процессом, для которого пул был создан.
Системные буферы.
В любой IOS-системе существует определенный набор общих буферных пулов — системных буферов. Эти буферные пулы используются для коммутации приходящих пакетов либо для хранения пакетов
, генерируемых системой (например, тестрвые пакеты сетевых интерфейсов или пакеты обновления таблиц маршрутизации). Информация, касающаяся системных и прочих буферов, может быть получена с помощью команды show buffer (пример 1.10).
Пример 1.10
Указанные в примере общие буферы являются стандартными для любой системы IOS. У каждого буфера есть имя (как, например, small buffer, или малый буфер, middle buffer, или средний буфер, и т.д.), которое указывает на определенный пул. За названием пула следует размер буферов, содержащихся в данном пуле. В пределах одного пула размер всех буферов одинаковый и варьируется от 104 до 18024 байт, чтобы приспосабливаться к передаваемым настройке параметра размера передаваемого блока (maximum transmission unit — MTU), сопоставленных различным сетевым интерфейсам. Содержимое прочих полей вывода содержит информацию, которая описана ниже.
total — суммарное количество буферов в пуле (свободных и занятых).
permanent — начальное (базовое) число буферов в пуле. Для динамических пулов число буферов может меняться. Однако оно не может достигать меньшего значения, чем указано в данной графе.
min free list — число свободных буферов.
min — минимальное число свободных буферов в пуле. Если количество свободных буферов становится меньше указанного значения, менеджер буферного пула пытается расширить пул с целью добавления дополнительных буферов.
max allowed — максимальное число свободных буферов в пуле. Соответственно, когда число свободных буферов превышает указанное значение, менеджер уменьшает количество свободных буферов и освобождает память. Независимо от значения max allowed, количество буферов не может быть меньше значения permanent.
hits — число буферов, которые были использованы в данном пуле.
misses — число запросов на предмет выделения свободного буфера, в то время, как число свободных буферов было меньше значения min.
trims — число буферов, удаленных из пула в результате сокращения его размера.
created — число буферов, созданных в процессе расширения пула.
failures — количество отказов буферного пула. Отказы обусловлены следующими причинами, запрос на выделение буфера получен во время отработки прерывания, когда расширение пула невозможно, получен запрос на выделение буфера, в то время как доступных буферов не осталось, а объем свободной памяти не позволяет расширить пул.
no memory — число отказов, связанных с отсутствием свободной памяти в пуле (данный показатель не используется в более поздних версиях системы IOS).
Чтобы понять работу менеджера пакетных буферов, рассмотрим коммутацию пакетов и проследим изменения в выводе команды show buffers для определенного пула. Начнем с рассмотрения списка из 16-та свободных буферов, которые приведены в примере ниже рис 1.7.
