Minor и major page fault: почему page fault не всегда означает проблему с диском
Когда процесс обращается к виртуальной памяти, нужная страница не всегда уже находится в памяти именно в том состоянии, которое ожидает процесс.
Тогда возникает page fault - обращение к ядру для обработки этого случая.
Но сам факт page fault ещё не означает, что система полезла на диск.
▪️Смотрим статистику процесса
ps -o pid,comm,min_flt,maj_flt -p 1234
Или:
pidstat -r -p 1234 1
Там можно увидеть количество minor и major faults.
▪️minor fault
При minor page fault данные уже находятся в RAM, но процессу нужно, например, создать или настроить соответствующее отображение страницы.
Дисковый I/O для загрузки этой страницы не требуется.
Поэтому большое количество minor faults само по себе не означает медленный диск.
▪️major fault
При major fault для продолжения работы процесса требуется получить данные из более медленного источника, например с диска.
Условно:
minor
процесс → kernel → RAM → продолжение
major
процесс → kernel → storage → RAM → продолжение
Именно major faults интересны при поиске проблем с памятью и I/O.
▪️Смотрим процесс в реальном времени
pidstat -r -p 1234 1
Можно увидеть примерно:
PID minflt/s majflt/s
1234 15230.00 0.00
Здесь процесс создаёт много minor faults, но major faults нет.
Это совершенно другая ситуация, чем:
PID minflt/s majflt/s
1234 1200.00 85.00
Во втором случае часть обращений действительно приводит к ожиданию загрузки данных.
▪️Практический сценарий
Приложение внезапно начинает тормозить.
top показывает:
CPU: 20%
RAM: 60%
Но:
pidstat -r -p 1234 1
показывает заметный majflt/s.
Тогда стоит дополнительно посмотреть I/O:
iostat -xz 1
Возможно, процесс регулярно ждёт чтения данных со storage.
▪️Важный нюанс
Не стоит использовать количество page faults как самостоятельную метрику производительности.
Высокий minflt/s может быть совершенно нормальным для приложения с определённым характером работы с памятью.
Гораздо интереснее смотреть на major faults вместе с latency и I/O activity.
То есть:
page fault
↓
minor или major?
↓
если major → есть ли реальный I/O?
↓
где процесс проводит время?
Сам по себе page fault - это не ошибка. Это механизм, который Linux постоянно использует при работе с виртуальной памятью.
BashTex 📱 #bash #systemd
Когда процесс обращается к виртуальной памяти, нужная страница не всегда уже находится в памяти именно в том состоянии, которое ожидает процесс.
Тогда возникает page fault - обращение к ядру для обработки этого случая.
Но сам факт page fault ещё не означает, что система полезла на диск.
▪️Смотрим статистику процесса
ps -o pid,comm,min_flt,maj_flt -p 1234
Или:
pidstat -r -p 1234 1
Там можно увидеть количество minor и major faults.
▪️minor fault
При minor page fault данные уже находятся в RAM, но процессу нужно, например, создать или настроить соответствующее отображение страницы.
Дисковый I/O для загрузки этой страницы не требуется.
Поэтому большое количество minor faults само по себе не означает медленный диск.
▪️major fault
При major fault для продолжения работы процесса требуется получить данные из более медленного источника, например с диска.
Условно:
minor
процесс → kernel → RAM → продолжение
major
процесс → kernel → storage → RAM → продолжение
Именно major faults интересны при поиске проблем с памятью и I/O.
▪️Смотрим процесс в реальном времени
pidstat -r -p 1234 1
Можно увидеть примерно:
PID minflt/s majflt/s
1234 15230.00 0.00
Здесь процесс создаёт много minor faults, но major faults нет.
Это совершенно другая ситуация, чем:
PID minflt/s majflt/s
1234 1200.00 85.00
Во втором случае часть обращений действительно приводит к ожиданию загрузки данных.
▪️Практический сценарий
Приложение внезапно начинает тормозить.
top показывает:
CPU: 20%
RAM: 60%
Но:
pidstat -r -p 1234 1
показывает заметный majflt/s.
Тогда стоит дополнительно посмотреть I/O:
iostat -xz 1
Возможно, процесс регулярно ждёт чтения данных со storage.
▪️Важный нюанс
Не стоит использовать количество page faults как самостоятельную метрику производительности.
Высокий minflt/s может быть совершенно нормальным для приложения с определённым характером работы с памятью.
Гораздо интереснее смотреть на major faults вместе с latency и I/O activity.
То есть:
page fault
↓
minor или major?
↓
если major → есть ли реальный I/O?
↓
где процесс проводит время?
Сам по себе page fault - это не ошибка. Это механизм, который Linux постоянно использует при работе с виртуальной памятью.
BashTex 📱 #bash #systemd