поверх показывает `swout` (свопинг), когда у меня есть гигабайты свободной памяти. Почему?
Читая документацию, я думаю, что использование опции "--failed" покажет только неудачные события для запускаемого вами отчета. Поведение по умолчанию - показывать и неудачи, и успехи. Из man-страницы:
--failed
Only select failed events for processing in the reports. The default is both success and failed events.
Я полагаю, что число - это количество событий для данного конкретного отчета для данного конкретного пользователя. В вашем случае с пользователем "root" связано 87 событий входа (неудачных и успешных), а с пользователем "unset" - 458 событий входа (опять же, неудачных и успешных).
Вот дополнительное хорошее чтение по aureport:
Я размышлял над похожим вопросом --вы видели мою ветку про kswapd и зональные водяные знаки --и ответ в моем случае (и, возможно, в вашем тоже )— это фрагментация памяти.
Когда память достаточно фрагментирована, выделение более высокого порядка не удастся, и это (в зависимости от ряда дополнительных факторов )либо приведет к прямому освобождению, либо разбудит kswapd, который попытается выполнить восстановление/сжатие зоны.. Дополнительные подробности вы можете найти в моей теме.
Еще одна вещь, которая может ускользнуть от внимания при решении подобных проблем, — это зонирование памяти . т.е. у вас может быть достаточно памяти в целом(и она может даже содержать достаточно непрерывных фрагментов ), но она может быть ограничена DMA32 (, если вы используете 64-битную -архитектуру ). Некоторые люди склонны игнорировать DMA32 как «маленький» (, вероятно, потому, что они привыкли к 32-битному -мышлению ), но 4 ГБ на самом деле не «маленький».
У вас есть два способа узнать наверняка, что происходит в вашем случае. Одним из них является анализ статистики --. Вы можете настроить задания для периодического создания моментальных снимков /proc/buddyinfo, /proc/zoneinfo, /proc/vmstat и т. д. и попытаться понять, что вы видите.
Другой способ более прямой и надежный, если вы заставите его работать :вам нужно захватить кодовые пути, которые ведут к событиям подкачки, и вы можете сделать это, используя точки трассировки, которыми оснащено ядро (, в частности, существует множество событий vmscan ).
Но заставить его работать может быть сложно, так как инструментарий низкого -уровня не всегда работает так, как должен, из коробки. В моем случае,нам пришлось потратить некоторое время на настройку инфраструктуры ftrace только для того, чтобы в конце концов обнаружить, что функция _graph probe, которая нам была нужна, по какой-то причине не работает. Следующим инструментом, который мы попробовали, был perf, и он тоже не удался с первой попытки. Но затем, когда вам в конце концов удастся зафиксировать интересующие вас события, они, скорее всего, приведут вас к ответу гораздо быстрее, чем любые глобальные счетчики.
С уважением, Николай