/proc/PID/status: состояние, идентификаторы и память
Прочитайте status выбранного процесса: отличите PID от PPid, сон от зависания и виртуальный размер от резидентной памяти; проверьте вывод по именам полей.
Снимок процесса перед поиском причины
Сервис отвечает медленно, и хочется сразу объявить его зависшим или слишком большим. Начните с короткой карточки состояния: кто работает, в каком состоянии находится и сколько памяти показывает ядро. Один такой снимок помогает сформулировать следующий вопрос, но сам по себе не устанавливает причину задержки.
Для учебного чтения удобна собственная Bash. Она живёт достаточно долго, чтобы повторить наблюдение, а для доступа обычно не нужны повышенные права. При переходе к сервису сначала установите его актуальный PID.
Поля нужно различать по смыслу
Pid относится к наблюдаемой задаче, PPid указывает родителя, а Threads показывает число потоков процесса. Состояние S означает прерываемое ожидание и нормально для оболочки, которая ждёт ввод. Буква состояния описывает текущий момент, а не итоговую оценку здоровья приложения.
VmSize описывает виртуальную память; VmRSS — резидентную часть. Большой адресный диапазон не равен такому же занятому объёму RAM. Значения резидентной памяти в status приближённые; для более подробного учёта существуют smaps и smaps_rollup.
Выберите только нужные строки
Запустите в интерактивной Bash. Выбор полей по имени сохраняет смысл отчёта при добавлении ядром новых строк.
observed_pid=$$
printf "Карточка оболочки %s\n" "$observed_pid"
grep -E "^(Name|State|Pid|PPid|Threads|VmSize|VmRSS):" "/proc/$observed_pid/status"Составьте проверяемое описание
Запишите факт: «для PID, указанного в отчёте, State равен S, Threads равен одному, VmRSS указан в kB». Не дописывайте к нему «поэтому процесс завис». В момент запуска grep оболочка может ждать завершения дочерней команды — это ожидаемое поведение.
Если сравниваете память до и после действия, сохраните одинаковый набор полей и повторите замер несколько раз. Отделите устойчивый рост от краткого пика. Не складывайте VmSize и VmRSS: это разные представления памяти, а не две независимые части расхода.
Проверьте своё рассуждение
Задача: VmSize вырос вдвое, VmRSS почти прежний, приложение отвечает. Достаточно ли этого для вывода об утечке физической памяти?
Нет. Следующий шаг — сравнить резидентный учёт и характер отображений на одинаковой нагрузке. Рост виртуального пространства является наблюдением, требующим объяснения; он ещё не показывает пропорционального роста занятой RAM.
Что осталось за пределами снимка
Некоторые поля зависят от конфигурации ядра. При чтении чужого процесса доступ может ограничиваться настройками procfs и политикой трассировки. Пока вы читаете файл, процесс продолжает работать: статус не является транзакционным снимком всех его ресурсов.
Технические источники
Использованы для проверки поведения. Объяснения и учебные сценарии созданы для проекта.
- Linux man-pages — proc_pid_status(5)
- Linux man-pages — proc_pid_smaps(5)
Проверка текста: 2026-09-11. Нативное исполнение на всей матрице дистрибутивов ещё не подтверждено.
Нужны собственная Linux-система, смонтированный procfs и Bash. Доступность полей зависит от ядра, его конфигурации, прав и пространств имён. Примеры только читают диагностические интерфейсы; браузерный симулятор их не реализует.
От материала к практике
Выберите следующую тему в каталоге Linux или проверьте знакомые команды в учебном терминале.