Page fault

[idle0]

Вопрос про UNIX/Solaris. Что такое page fault и можно ли по большому колличеству page faults судить о недостатке памяти в сервере или нет?

Я считаю что каждая disk i/o operation порождает page fault, т.e. запись/чтение файла и т.д. А мне говорят что page fault бывает
только в случае paging-a, когда например процесс обращается к
странице в памяти, которая была paged out из-за нехватки памяти...

[A. Fig Lee]

Вопрос про UNIX/Solaris. Что такое page fault и можно ли по большому колличеству page faults судить о недостатке памяти в сервере или нет?

aga

Я считаю что каждая disk i/o operation порождает page fault, т.e. запись/чтение файла и т.д. А мне говорят что page fault бывает
только в случае paging-a, когда например процесс обращается к
странице в памяти, которая была paged out из-за нехватки памяти...

Правильно говорят

[idle0]

Вопрос был такой: приходят ко мне друзья и говорят - мы сеичас померяем все сервера (iz Patrol-a), и везде где high rate of page faults - будем вас иметь за то что в системе недостаточно памяти.

А я им говорю - отчепитесь, у вас там high disk i/o и поетому то high rate of page faults.

P.S. В Solaris весь disk i/o сделан через paging. Если копировать большой файл - через "sar -p" видно большое колличество vflt/s.

Так что по моему я прав...

[A. Fig Lee]

Вопрос был такой: приходят ко мне друзья и говорят - мы сеичас померяем все сервера (из Патрол-а), и везде где хигх рате оф паге фаултс - будем вас иметь за то что в системе недостаточно памяти.

А я им говорю - отчепитесь, у вас там хигх диск и/о и поетому то хигх рате оф паге фаултс.

П.С. В Соларис весь диск и/о сделан через пагинг. Если копировать большой файл - через "сар -п" видно большое колличество вфлт/с.

Так что по моему я прав...

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

[A. Fig Lee]

Вопрос был такой: приходят ко мне друзья и говорят - мы сеичас померяем все сервера (из Патрол-а), и везде где хигх рате оф паге фаултс - будем вас иметь за то что в системе недостаточно памяти.

А я им говорю - отчепитесь, у вас там хигх диск и/о и поетому то хигх рате оф паге фаултс.

П.С. В Соларис весь диск и/о сделан через пагинг. Если копировать большой файл - через "сар -п" видно большое колличество вфлт/с.

Так что по моему я прав...

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

A Fig Lee, если я правильно помню, Solaris использует memory mapping для file I/O. Грубо говоря, файл объявляется swap-нутым на диск и все обращения к файлу идут через обращения к памяти. Естественно, если запрошенного участка файла нет в памяти, происходит отказ страницы и подкачка с диска.
Поиск по Google выдает в числе первых ссылок
http://www.cs.uleth.ca/~holzmann/C/system/mmap.html

Дальше рыться лень...

По-моему, ето не из той оперы. Во первых, Как ето поможет? Открываешь файл и пишешь туда - при чем тут мемори маппед файл?
2. При меморы маппед файл изменения в мемори синхронизируются с изменениями в реальном файле, так что своп тут не при чем, ИМХО.
3. Если Вы имеете ввиду мемори маппед с МАП_АНОН - тады да, своп - но в етом случае file IO не при чем.
4. Если запрошенного участка нет в памяти - ето говорит, что памяти не хватает.

5. АФАИК , Линух для malloc использует mmap - ну чтото я не вижу никаких фолтов с 1Гиг памяти.

[A. Fig Lee]

Вы наверное, когда копируете большой файл аллокируете много мемори - используйте маленький буффер и увидите.

Небольшое дополнение. Системы, копирующие файл через swap

read src from disk->write swap to disk->read swap from disk->write dest to disk

не имеют права на существование, IMHO..

Все системы делают ето, когда не хватает памяти. Когда память есть - никто не делает.

[A. Fig Lee]

Я, наверное, слишком кратко выразилась. Впрочем, детальные разъяснения не входили в мои планы. Да и сейчас не входят, но начальный импульс дать могу. Открытие файла как memory-mapped сводится к объявлению в системе этого файла уже находящемся в виртуальной памяти и swap-нутым на диск таким образом, что его swap точно совпадает с открываемым файлом на диске. ...

1.То есть система имеет как бы 2 копии - в свапе и обычный файл, так? Зачем?

2.Короче - свапнутым на диск он будет только если памяти физической не хватает.

3. Свап - ето и есть память - виртуальная. Если хватает физической, савп используется 0%.

[A. Fig Lee]

Вы наверное, когда копируете большой файл аллокируете много мемори - используйте маленький буффер и увидите.

Небольшое дополнение. Системы, копирующие файл через swap

read src from disk->write swap to disk->read swap from disk->write dest to disk

не имеют права на существование, IMHO..

Все системы делают ето, когда не хватает памяти. Когда память есть - никто не делает.

В системах, поддерживающих memory-mapped files (MMF) это может произойти только в случае неграмотности разработчика приложения (см. предыдущий постинг о MMF) - но это отдельный (клинический) случай.

1. Все популярные более менее поддерживают mmap.
2. Чудес на свете не бывает - если запрошено больше памяти чем есть физической - будет участвовать своп, независимо от того - мемори маппед файл или нет.
3. Предыдущий постинг посмотрел. Ничё не понял, кроме намеков что мне надо бы подучить ето дело..

[tengiz]

1.То есть система имеет как бы 2 копии - в свапе и обычный файл, так? Зачем?
2.Короче - свапнутым на диск он будет только если памяти физической не хватает.
3. Свап - ето и есть память - виртуальная. Если хватает физической, савп используется 0%.

1. Система имеет ровно одну копию - сам файл одновременно является файлом подкачки.
2. Любой файл открытый как memory mapped сам себе файл подкачки.
3. Для регионов виртуальной памяти, отведённых для memory mapped files, эти файлы и являются backing storage. Для других регионов виртуальной памяти, куда явно не отображаются файлы, в качестве backing storage используется swap.

Это совершенно обычное решение для систем, поддерживающих memory mapped файлы. Зачем занимать дополнительное место на стандартном swap, тратить IO и CPU на копирование с диска на диск, если любой файл уже сам по себе является местом на диске, куда можно отобразить регион виртуальной памяти? Преимущества - очевидны.

[f_evgeny]

Проведем эксперимент, включаем top и смотрим куда идет память. Затем включаем копирование большого количеста файлов и смотрим, что изменилось.
Память расходуется на:
- процессы
- буфера
- дисковый кэш
В исходном состоянии использование свопа - 0
Запускаем копирование. Растет дисковый кэш и немножко буфера. Появляется использвание свопа.
Т.е. при большом количестве дискового ввода/вывода память перераспределяется в пользу дискового кэша и из-за этого растет своп. Растет своп - растет количество page faults.
Система - Linux, kernrel 2.4.22
Или вы не об этом?

[A. Fig Lee]

1.То есть система имеет как бы 2 копии - в свапе и обычный файл, так? Зачем?
2.Короче - свапнутым на диск он будет только если памяти физической не хватает.
3. Свап - ето и есть память - виртуальная. Если хватает физической, савп используется 0%.

1. Система имеет ровно одну копию - сам файл одновременно является файлом подкачки.
2. Любой файл открытый как memory mapped сам себе файл подкачки.
3. Для регионов виртуальной памяти, отведённых для memory mapped files, эти файлы и являются backing storage. Для других регионов виртуальной памяти, куда явно не отображаются файлы, в качестве backing storage используется swap.

Это совершенно обычное решение для систем, поддерживающих memory mapped файлы. Зачем занимать дополнительное место на стандартном swap, тратить IO и CPU на копирование с диска на диск, если любой файл уже сам по себе является местом на диске, куда можно отобразить регион виртуальной памяти? Преимущества - очевидны.

Tengiz, спасибо большое! Ваше разъяснение существенно понятней моего.

Ясен пень. Тем более что оно противоречит Вашему.

[A. Fig Lee]

Проведем эксперимент, включаем top и смотрим куда идет память. Затем включаем копирование большого количеста файлов и смотрим, что изменилось.
Память расходуется на:
- процессы
- буфера
- дисковый кэш
В исходном состоянии использование свопа - 0
Запускаем копирование. Растет дисковый кэш и немножко буфера. Появляется использвание свопа.
Т.е. при большом количестве дискового ввода/вывода память перераспределяется в пользу дискового кэша и из-за этого растет своп. Растет своп - растет количество page faults.
Система - Linux, kernrel 2.4.22
Или вы не об этом?

1. Примерно об етом. У меня на Линухе - 1 гиг.
Если сислог не растет - массовое копирование файлов (30 симултанеос процессов в течение многих минут с файлами < 1 мб) не приводят к использованию свопа.
Red Hat 7.2

Сколько у Вас было памяти свободной изначально и как большие файлы Вы используете?

[f_evgeny]

Проведем эксперимент, включаем top и смотрим куда идет память. Затем включаем копирование большого количеста файлов и смотрим, что изменилось.
Память расходуется на:
- процессы
- буфера
- дисковый кэш
В исходном состоянии использование свопа - 0
Запускаем копирование. Растет дисковый кэш и немножко буфера. Появляется использвание свопа.
Т.е. при большом количестве дискового ввода/вывода память перераспределяется в пользу дискового кэша и из-за этого растет своп. Растет своп - растет количество page faults.
Система - Linux, kernrel 2.4.22
Или вы не об этом?

1. Примерно об етом. У меня на Линухе - 1 гиг.
Если сислог не растет - массовое копирование файлов (30 симултанеос процессов в течение многих минут с файлами < 1 мб) не приводят к использованию свопа.
Red Hat 7.2

Сколько у Вас было памяти свободной изначально и как большие файлы Вы используете?

Я специально взял WS где памяти поменьше, е ее использую как Xterminal. Памяти - 48 Mb, свободно было несколько мег, так как в таких условиях Линукс использует всю память, свободную - максимально под кэш.
Файлы - я недолго думая взял и сделал cp /usr /tmp

[A. Fig Lee]

1. Примерно об етом. У меня на Линухе - 1 гиг.
Если сислог не растет - массовое копирование файлов (30 симултанеос процессов в течение многих минут с файлами < 1 мб) не приводят к использованию свопа.
Red Hat 7.2

Сколько у Вас было памяти свободной изначально и как большие файлы Вы используете?

Я специально взял WS где памяти поменьше, е ее использую как Xterminal. Памяти - 48 Mb, свободно было несколько мег, так как в таких условиях Линукс использует всю память, свободную - максимально под кэш.
Файлы - я недолго думая взял и сделал cp /usr /tmp[/quote]
Батенька, ето не годится!
Исходный пойнт был - при копировании файлов ВСЕГДА используется свап независимо от размеров свободной памяти, и как следствие количество пейдж фолтов не может указывать на недостаток физической памяти.
Мой пойнт - все до лампочки, независимо от операции, когда все можно поместить в физическую память, своп не будет использован. То есть количество пейдж фолтов прймао говорит о недостатке физической памяти.
А про операционки, копирующие через своп - я вооще молчу...

В Линухе, надо мегабайт 100 свободных физических иметь для експеримента - и запустите потом 3-4 процесса по копированию мегабайтного файла.

[f_evgeny]

1. Примерно об етом. У меня на Линухе - 1 гиг.
Если сислог не растет - массовое копирование файлов (30 симултанеос процессов в течение многих минут с файлами < 1 мб) не приводят к использованию свопа.
Red Hat 7.2

Сколько у Вас было памяти свободной изначально и как большие файлы Вы используете?

Я специально взял WS где памяти поменьше, е ее использую как Xterminal. Памяти - 48 Mb, свободно было несколько мег, так как в таких условиях Линукс использует всю память, свободную - максимально под кэш.
Файлы - я недолго думая взял и сделал cp /usr /tmp

Батенька, ето не годится!
Исходный пойнт был - при копировании файлов ВСЕГДА используется свап независимо от размеров свободной памяти, и как следствие количество пейдж фолтов не может указывать на недостаток физической памяти.
Мой пойнт - все до лампочки, независимо от операции, когда все можно поместить в физическую память, своп не будет использован. То есть количество пейдж фолтов прймао говорит о недостатке физической памяти.
А про операционки, копирующие через своп - я вооще молчу...

В Линухе, надо мегабайт 100 свободных физических иметь для експеримента - и запустите потом 3-4 процесса по копированию мегабайтного файла.[/quote]
Пардон, неясно выяснился. Мой опыт показывает, что при копировании файлов может возрасти количество пейдж фолтов, но не непосредственно, а из-за увеличения количества памяти, занятого под буфера.

[idle0]

Исходный пойнт был - при копировании файлов ВСЕГДА используется свап независимо от размеров свободной памяти, и как следствие количество пейдж фолтов не может указывать на недостаток физической памяти.
Мой пойнт - все до лампочки, независимо от операции, когда все можно поместить в физическую память, своп не будет использован. То есть количество пейдж фолтов прймао говорит о недостатке физической памяти.
А про операционки, копирующие через своп - я вооще молчу...

Вы не понимаете Доступ к файлам и копирование не идет через system swap. Просто на время открытия файла и операций с ниим он становится таким маленьким swap-ом, который используется только для доступа к этому файлу. От колличества памяти в системе это не зависит - понимаете? Это про Solaris, в Linux скорее всего тоже так, но я не уверен на 100%

[tengiz]

Просто на время открытия файла и операций с ниим он становится таким маленьким swap-ом, который используется только для доступа к этому файлу. От колличества памяти в системе это не зависит - понимаете? Это про Solaris, в Linux скорее всего тоже так, но я не уверен на 100%

Это верно только для приложений, которые пользуются memory mapped files для ввода/вывода (и, возможно, для всех исполняемых файлов - я не знаю этой детали про Solaris). Что, вообще говоря, эффективно и разумно только для определённых случаев. Если бы на Solaris это был единственный способ IO, то индустрия баз данных, скажем, не хотела бы иметь ничего общего с Sun. Потому что схемы кеширования, обеспечиваемые стандартными менеджерами виртуальной памяти, не годятся для СУБД, где от операционной системы нужен асинхронный небуферизованный ввод/вывод. Следовательно, предположение о том, что активная подкачка не обязательно означает нехватку физической памяти верно только тогда, когда точно известно, что большая часть IO действительно делается через mmap. Для чего, соответственно, нужно быть уверенным в том, как конкретно сделаны конкретные приложения в основном работающие в системе.

[idle0]

Просто на время открытия файла и операций с ниим он становится таким маленьким swap-ом, который используется только для доступа к этому файлу. От колличества памяти в системе это не зависит - понимаете? Это про Solaris, в Linux скорее всего тоже так, но я не уверен на 100%

Это верно только для приложений, которые пользуются memory mapped files для ввода/вывода (и, возможно, для всех исполняемых файлов - я не знаю этой детали про Solaris). Что, вообще говоря, эффективно и разумно только для определённых случаев. Если бы на Solaris это был единственный способ IO, то индустрия баз данных, скажем, не хотела бы иметь ничего общего с Sun. Потому что схемы кеширования, обеспечиваемые стандартными менеджерами виртуальной памяти, не годятся для СУБД, где от операционной системы нужен асинхронный небуферизованный ввод/вывод. Следовательно, предположение о том, что активная подкачка не обязательно означает нехватку физической памяти верно только тогда, когда точно известно, что большая часть IO действительно делается через mmap. Для чего, соответственно, нужно быть уверенным в том, как конкретно сделаны конкретные приложения в основном работающие в системе.

А для этого есть forcedirectio:

Code: Select all

forcedirectio | noforcedirectio
                      If  forcedirectio  is  specified  and  sup-
                      ported  by  the  file  system, then for the
                      duration of the mount  forced  direct   I/O
                      will  be used. If the filesystem is mounted
                      using   forcedirectio,   then    data    is
                      transferred  directly  between user address
                      space and the disk. If  the  filesystem  is
                      mounted  using   noforcedirectio, then data
                      is buffered in kernel  address  space  when
                      data  is  transferred  between user address
                      space and the disk. forcedirectio is a per-
                      formance  option  that  benefits  only from
                      large  sequential   data   transfers.   The
                      default behavior is  noforcedirectio.

[A. Fig Lee]

Исходный пойнт был - при копировании файлов ВСЕГДА используется свап независимо от размеров свободной памяти, и как следствие количество пейдж фолтов не может указывать на недостаток физической памяти.
Мой пойнт - все до лампочки, независимо от операции, когда все можно поместить в физическую память, своп не будет использован. То есть количество пейдж фолтов прймао говорит о недостатке физической памяти.
А про операционки, копирующие через своп - я вооще молчу...

Вы не понимаете Доступ к файлам и копирование не идет через system swap. Просто на время открытия файла и операций с ниим он становится таким маленьким swap-ом, который используется только для доступа к этому файлу. От колличества памяти в системе это не зависит - понимаете? Это про Solaris, в Linux скорее всего тоже так, но я не уверен на 100%

Да, не понимаю. Что значит - "становится маленьким свапом"? Свап в системе один - грубо говоря - виртуальная память. Каким образом ето становится "маленьким свапом"? Файл физически перемещается или что?
В случае использования мемори маппед файл (для чего угодно) - Вы можете аллокировать большое количество виртуальной памяти, больше, чем есть свободной физической - в етом случае будет участвовать свап. Если памяти меньше чем физической - свап не используется.
Ну Вы меня заставили таки заглянуть в Solaris internals - ничего подтверждающего Вашу мысль я там не нашел.

[f_evgeny]

..и, возможно, для всех исполняемых файлов - я не знаю этой детали про Solaris...

Исполняемые файлы всегда загружаются постранично. Называется - страничная подкачка по требованию. "Все, что в действительности требуется, - это структура пользователя и таблицы страниц. Если они загружены, то процесс считается находящимся в памяти и может быть запущен планировщиком. Страницы с сегментами текста, данных и стека загружаются в память динамически, по мере обращения к ним. Если пользовательской структуры и таблицы страниц нет в памяти, то процесс не может быть запущен, пока своппер не загрузит их" - Танненбаум, 2- е издание. (Здесь под текстом - по видимому имеется в виду программный код)

[A. Fig Lee]

Code: Select all

forcedirectio | noforcedirectio
                      If  forcedirectio  is  specified  and  sup-
                      ported  by  the  file  system, then for the
                      duration of the mount  forced  direct   I/O
                      will  be used. If the filesystem is mounted
                      using   forcedirectio,   then    data    is
                      transferred  directly  between user address
                      space and the disk. If  the  filesystem  is
                      mounted  using   noforcedirectio, then data
                      is buffered in kernel  address  space  when
                      data  is  transferred  between user address
                      space and the disk. forcedirectio is a per-
                      formance  option  that  benefits  only from
                      large  sequential   data   transfers.   The
                      default behavior is  noforcedirectio.

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

Даже если не в физической, то там своя отдельная имплементация, которая не приводит к пейдж фолтам. ("Solaris Internals" page 22).

[f_evgeny]

Давайте не будем горячится и спокойно во всем разберемся. (C)
Лично я знаю следующие виды активности с обращением к диску, которые можно заподозрить в генерации Page faults:
1. Выгрузк/подгрузка страниц из адресного пространства процессов своппером. Сюда входят также и отображаемые в память файлы. Page Faults генерятся. (При обращении к адресу, который находится на странице, которая не загружена в физическую память)
2. Подгрузка страниц в дисковый кэш. Когда из открытого файла процесс пытается считать данные, которые находятся на странице, которой нет в дисковом кэше. Тут насчет Page Faults ничего сказать не могу, надо ковырятся в интернете. Что скажут знатоки?

[tengiz]

Подгрузка страниц в дисковый кэш. Когда из открытого файла процесс пытается считать данные, которые находятся на странице, которой нет в дисковом кэше. Тут насчет Page Faults ничего сказать не могу, надо ковырятся в интернете.

Как уже было написано выше - это зависит от того, что конкретно хотело приложение, работающее с этим файлом и как точно этот файл был открыт. Memory mapped file - не самое лучшее и не самое универсальное решение. В том числе и для реализации системного файлового кеша - особенно когда файлов слишком много и адресного пространства ядра просто на хватит на то, чтобы вместить туда все открытые файлы целиком. А иначе связываеться с mmap для организации файлового кеша смысла мало. Более того, функциональность менеджера витруальной памяти, страничного и дискового кеша настолько друг с другом тесно связаны, что memory mapped files скорее как раз реализована на основе VMM/file cache. Т.е. всё как раз просиходит наоборот.

В общем, на самом деле вопрос упирается в точное определение page fault на Solaris. Если любой кеш-промах в VMM/file cache является page fault, то тогда idle0 совершенно справедливо полагает, что их большое количество не говорит о недостатке физической памяти. С другой стороны, информативность такого счётчика производительности близка к нулю и непонятно зачем он вообще нужен.

[A. Fig Lee]

Ну вроде бы так:

13.4 File system I/O:
Two distinct methods perform file system I/o:
- read, write and related system calls
- memory mapped files.

.. a process calls mmap() to map file into its address space for memory mapped I/O and the kernel maps the file into kernel's address space for read and write.

1. Ясен пень, что кернел мемори пейдж фолтс не вызывает.

Once the file mapping is created in the process's address space, file pages are read when a fault occurs in the address space.

Короче в етом случае вызывается драйвер seg_vn, который тоже вызывается от MMU через as_fault() - то есть пейдж фолт регестрируется до вызова seg_vn, получается мемори маппед файл не регистрируют пейдж фолтов. (Лень все печaтать.)

[idle0]

Для всех неверующих

Запустите на Solaris "cp /var/tmp/largefile1 /var/tmp/largefile2"
и в это же время "sar -p 1 1000" и "vmstat -p 1"

В "sar" смотрите на vflt/s, а в "vmstat" на fpi/fpo (file system page-ins,
file system page-outs)