Всем привет. В общем следующая проблема:
При интенсивной нагрузке page faults растут как на дрожжах...
За 4 часа работы переваливает за 5 000 000.
Это вообще нормально? ( ATL сервис, STL, основная работа происходит с std::map-иной )
Заранее спасибо

Здравствуйте, Аноним, Вы писали:
А>Это вообще нормально?

смотря для какой задачи: при каких-то требованиях с сервису это может быть нормально, при каких-то — нет, при каких-то — неизбежно.
ну а вообще, 350 page faults в секунду — это много. raid, вероятно, на пределе работает =)

--
— приборы?
— 10.
— что "10"?!
— а что "приборы"?

Здравствуйте, vayerx, Вы писали:

V>ну а вообще, 350 page faults в секунду — это много. raid, вероятно, на пределе работает =)

Page fault не обязательно означает загрузку страницы из свопа. Обычно при выделении памяти OS большую часть страниц в VA процесса резервирует, но не выделяет для них физическую память. Реальное выделение физической памяти будет происходить по мере обращения, как раз при обработке page fault. Подобным образом работает и выделение памяти под стек.

Здравствуйте, IID, Вы писали:

IID>Page fault не обязательно означает загрузку страницы из свопа. Обычно при выделении памяти OS большую часть страниц в VA процесса резервирует, но не выделяет для них физическую память. Реальное выделение физической памяти будет происходить по мере обращения, как раз при обработке page fault. Подобным образом работает и выделение памяти под стек.

в общем случа вы правы. если же речь идет именно о большом std::map, то память инициализрованна и, скорее всего, именно выгруженна на диск. впрочем, не зная конкретной задачи и ее реализации, можно только гадать

Здравствуйте, vayerx, Вы писали:

V>Здравствуйте, IID, Вы писали:

IID>>Page fault не обязательно означает загрузку страницы из свопа. Обычно при выделении памяти OS большую часть страниц в VA процесса резервирует, но не выделяет для них физическую память. Реальное выделение физической памяти будет происходить по мере обращения, как раз при обработке page fault. Подобным образом работает и выделение памяти под стек.

V>в общем случа вы правы. если же речь идет именно о большом std::map, то память инициализрованна и, скорее всего, именно выгруженна на диск. впрочем, не зная конкретной задачи и ее реализации, можно только гадать

В-общем то задача банальная — есть сессии (некий класс), и идентификаторы сессий (
строка). Все это хранится в мапине std::hash_map< std::wstring, Session >. Сессий много, они постоянно добавляются, ищутся и удаляются. Вот собсно все.

Здравствуйте, Аноним, Вы писали:

А>В-общем то задача банальная — есть сессии (некий класс), и идентификаторы сессий (
А>строка). Все это хранится в мапине std::hash_map< std::wstring, Session >. Сессий много, они постоянно добавляются, ищутся и удаляются. Вот собсно все.

как соотносится среднее количество хранимых сессий с размером hash_map? большое количество page faults может быть вызванно завышенным размером.

сколько в среднем приходит запросов к hash_map? как это соотносится с оценочными 350 pf в секунду?

какая при этом дисковая активность?

сколько памяти в системе?

сколько программа занимает в оперативной памяти? какая часть свопится?

первая мысль которая приходит в голову при виде таких сообщений — "вы хотите об этом поговорить?"
Программа тормозит? Профайлер показал что из-за свопинга?
page faults используется для многих вещей в системе. Чем занимается тот класс Session про который вы писали? Используете ли работу с пайпами? Используете ли работу с реестром? filemapping явно или не явно (работая с файлами через API которые могут отображать их в память)?

Здравствуйте, vayerx, Вы писали:

V>сколько памяти в системе?

V>сколько программа занимает в оперативной памяти? какая часть свопится?
VMWare, 2003 server, 384 mb ram

Занимает где то метров 8, но постепенно растет до 10 (за 3 часа). Возможно, ML, но больно растет медленно при полной загрузке, но исключать такую возможность не стоит.
Дергается мапина очень часто, через COM интерфейс.

А>Дергается мапина очень часто, через COM интерфейс.
COM работает через RPC. RPC локально работает через LPC. LPC юзают файлмаппинг для shared memory. Вполне возможно отсюда растут ваши page фолты. Вообще глупое это занятие -мерять пэйдж фолты, вы еще померяйте общее время работы программы, и удивитесь почему оно расчет со скоростью 60 секунд в минуту.

Здравствуйте, Аноним, Вы писали:

А>>Дергается мапина очень часто, через COM интерфейс.
А>COM работает через RPC. RPC локально работает через LPC. LPC юзают файлмаппинг для shared memory. Вполне возможно отсюда растут ваши page фолты. Вообще глупое это занятие -мерять пэйдж фолты, вы еще померяйте общее время работы программы, и удивитесь почему оно расчет со скоростью 60 секунд в минуту.

Мой вопрос был не в замерение page faults , а в том нормально это или нет, то бишь не упадет ли это все со временем .

А>Мой вопрос был не в замерение page faults , а в том нормально это или нет, то бишь не упадет ли это все со временем .
Нет не упадет. Это обычный performance показатель, как CPU time например.

Здравствуйте, Аноним, Вы писали:

А>>Мой вопрос был не в замерение page faults , а в том нормально это или нет, то бишь не упадет ли это все со временем .
А>Нет не упадет. Это обычный performance показатель, как CPU time например.
Благодарю

Здравствуйте, Аноним, Вы писали:

А>Всем привет. В общем следующая проблема:
А>При интенсивной нагрузке page faults растут как на дрожжах...
А>За 4 часа работы переваливает за 5 000 000.
А>Это вообще нормально? ( ATL сервис, STL, основная работа происходит с std::map-иной )
А>Заранее спасибо

Why does Explorer generate a page fault every two seconds?