Comments 34
ахаха, фотка в начале из моего сайта )))
статью читаю…
статью читаю…
UFO just landed and posted this here
Основательно…
Во первых система находит процессы, максимально превысившие свой лимит на размер рабочего набора. Для этих процессов запускается процесс «старения» страниц (aging), для определения какие из страниц меньше всего используются.Вот это ново для меня. Я считал, что все страницы равноправны и у них всегда считается время последнего доступа, а оказывается это механизм для самых жадных.
Standby список имеет 8 уровней приоритета (которыми до некоторой степени может управлять как само приложение, так и Superfetch, осуществляющий динамическое управление приоритетами страниц на основе анализа реального использования файлов/страниц), если не остается вообще никакого выбора — винда первым делом выбрасывает кеш самого низкого приоритета.Здесь я еще раз хотел бы подчеркнуть, что данный механизм появился только в висте. До этого винда спокойно выкидывала данные приложения, оставляя в памяти кеш дисковой системы.
РУ5 — вспмннил детство! Первая попавшая в мои руки с паяльником динамическая память! ;) Был в то время такой компьютер — ЮТ-88. Там модуль динамической памяти собирался на РУ5 и мультиплекирование регенерации было сделано на ПЗУ (а-ля ПЛИС в итоге). Ностальгия однако!
Задачка по теме а-ля «check your knowledge» ;)
Есть компьютер с Windows 7 x64, 4G RAM, 128G SSD. Page-файл по умолчанию имеет размер 4G.
Докупается еще 4G RAM в целях увеличения производительности. Теперь 8G RAM и page-файл тоже 8G.
Вопрос, что сделать с page-файлом, и, главное, почему?
— оставить как есть
— отключить
— уменьшить
— другой вариант
Есть компьютер с Windows 7 x64, 4G RAM, 128G SSD. Page-файл по умолчанию имеет размер 4G.
Докупается еще 4G RAM в целях увеличения производительности. Теперь 8G RAM и page-файл тоже 8G.
Вопрос, что сделать с page-файлом, и, главное, почему?
— оставить как есть
— отключить
— уменьшить
— другой вариант
> Миф: Отключение пейджфайла улучшает производительность системы.
Я бы не назвал это в полной мере «мифом», все зависит от того, как именно используется компьютер. Часто бывает, что лучше уж пусть «зажравшееся» приложение немедленно умрет по нехватке памяти, чем уйдет в бесконечный своп, тем самым потянув на дно и всю систему. Поясню. Бывает так, что размер свопа не ограничен сверху (или ограничен большим числом), а то или иное приложение из-за бага начинает кушать и кушать память. В итоге все начинает настолько зверски тормозить (из-за перегруженности диска), что убить приложение удается только через 3-4 минуты. Иногда это неприемлемо.
Это особенно касается различных серверных систем, когда происходит одновременная обработка большого потока входящих запросов или разгребается очередь заданий. Если процессов много, то пусть уж лучше часть из них умрет, чем вся система деградирует. Именно для таких случаев и дают рекомендацию отключать своп (я эту рекомендацию слышал еще году в 2000-м от Максима Мошкова, правда, для FreeBSD).
Т.е. отключение свопа — это не мера увеличения производительности, это мера для улучшения скорости отклика в критических ситуациях.
Еще одна мысль. В штатном режиме работы на серверной системе своп-активности быть не должно (т.к. важна максимальная скорость отклика). Как только возникает своп-активность, вся система деградирует (обидно, если это происходит из-за какой-нибудь второстепенной ерунды, которая лучше бы просто умерла, чем кушала память). Поэтому я люблю делать так: на хост-машине оставлять своп, однако на всех виртуальных машинах — жестко ограничивать максимальный размер памяти, так, чтобы вся имеющаяся память была распределена между виртуальными машинами непротиворечиво. Тогда в случае аварии я на хост-машину всегда смогу зайти, в то время как виртуальные машины будут убивать «зажравшиеся» процессы.
Я бы не назвал это в полной мере «мифом», все зависит от того, как именно используется компьютер. Часто бывает, что лучше уж пусть «зажравшееся» приложение немедленно умрет по нехватке памяти, чем уйдет в бесконечный своп, тем самым потянув на дно и всю систему. Поясню. Бывает так, что размер свопа не ограничен сверху (или ограничен большим числом), а то или иное приложение из-за бага начинает кушать и кушать память. В итоге все начинает настолько зверски тормозить (из-за перегруженности диска), что убить приложение удается только через 3-4 минуты. Иногда это неприемлемо.
Это особенно касается различных серверных систем, когда происходит одновременная обработка большого потока входящих запросов или разгребается очередь заданий. Если процессов много, то пусть уж лучше часть из них умрет, чем вся система деградирует. Именно для таких случаев и дают рекомендацию отключать своп (я эту рекомендацию слышал еще году в 2000-м от Максима Мошкова, правда, для FreeBSD).
Т.е. отключение свопа — это не мера увеличения производительности, это мера для улучшения скорости отклика в критических ситуациях.
Еще одна мысль. В штатном режиме работы на серверной системе своп-активности быть не должно (т.к. важна максимальная скорость отклика). Как только возникает своп-активность, вся система деградирует (обидно, если это происходит из-за какой-нибудь второстепенной ерунды, которая лучше бы просто умерла, чем кушала память). Поэтому я люблю делать так: на хост-машине оставлять своп, однако на всех виртуальных машинах — жестко ограничивать максимальный размер памяти, так, чтобы вся имеющаяся память была распределена между виртуальными машинами непротиворечиво. Тогда в случае аварии я на хост-машину всегда смогу зайти, в то время как виртуальные машины будут убивать «зажравшиеся» процессы.
Согласен. Описываемый дальше случай с мюторрентом показывает, что если не сделать ничего, то все может стать плохо. С другой стороны, если уж заниматься оптимизацией производительности, то лучше насильно понизить приоритет памяти для подобного процесса (или другим способом решить проблему в приложении), чем отключать подкачку. Радует то, что подавляющему большинству приложений никаких дополнительных телодвижений делать не нужно
Спасибо за статью!
Можно поподробнее про приоритеты ввода \ вывода (в статье такая формулировка, как будто их много, а я встречал только два — нормальный и низкий).
А также про регулирование приоритета памяти? Не встречал такого API
Можно поподробнее про приоритеты ввода \ вывода (в статье такая формулировка, как будто их много, а я встречал только два — нормальный и низкий).
А также про регулирование приоритета памяти? Не встречал такого API
Приоритетов ввода/вывода пока 5:
Называется хинтом, потому что это просто число, ассоциированное с запросом на ввод вывод. Файловая система реализует приоретизацию по своему
typedef enum _IO_PRIORITY_HINT {
IoPriorityVeryLow = 0,
IoPriorityLow = 1,
IoPriorityNormal = 2,
IoPriorityHigh = 3,
IoPriorityCritical = 4,
MaxIoPriorityTypes = 5
} IO_PRIORITY_HINT;
Называется хинтом, потому что это просто число, ассоциированное с запросом на ввод вывод. Файловая система реализует приоретизацию по своему
А я правильно понимаю, что SetThreadPriority(h, THREAD_MODE_BACKGROUND_BEGIN) устанавливает приоритет в минимальный, а SetThreadPriority(h, THREAD_MODE_BACKGROUND_END) возвращает IoPriorityNormal?
Также интересно, влияет ли еще на какие-то приоритеты THREAD_MODE_BACKGROUND_BEGIN — в документации упомянуто про «resource scheduling priorities», что намекает на несколько уровней приоритета
Также интересно, влияет ли еще на какие-то приоритеты THREAD_MODE_BACKGROUND_BEGIN — в документации упомянуто про «resource scheduling priorities», что намекает на несколько уровней приоритета
Он снижает все три приоритета: приоритет (который приоритет на использование CPU), приоритет ввода/вывода и приоритет памяти
Нормальный приоритет процессора — 8, ввода/вывода — 2 (Normal), памяти — 5
Приоритет ввода/вывода можно менять не только для потока, но и для отдельных файлов, приоритет процессора — довольно известная штука и уже практически не вызывает вопросов, а вот с приоритетом памяти есть определенные проблемы. THREAD_MODE_BACKGROUND_BEGIN/END — это единственное публичное API, которое мне известно, и позволяет переключать приоритет между уровнями 5 и 1. Суперфетч имеет свое API (через один из information class-ов в NtSetSystemInformation), которое позволяет более тонко контроллировать приоритет памяти (и более того, перемещать уже загруженные страницы между приоритетами), но ни официальной, ни даже неофициальной документации на это я не встречал.
Нормальный приоритет процессора — 8, ввода/вывода — 2 (Normal), памяти — 5
Приоритет ввода/вывода можно менять не только для потока, но и для отдельных файлов, приоритет процессора — довольно известная штука и уже практически не вызывает вопросов, а вот с приоритетом памяти есть определенные проблемы. THREAD_MODE_BACKGROUND_BEGIN/END — это единственное публичное API, которое мне известно, и позволяет переключать приоритет между уровнями 5 и 1. Суперфетч имеет свое API (через один из information class-ов в NtSetSystemInformation), которое позволяет более тонко контроллировать приоритет памяти (и более того, перемещать уже загруженные страницы между приоритетами), но ни официальной, ни даже неофициальной документации на это я не встречал.
>Миф: Винда использует пейджфайл, даже если свободной памяти еще завались.
На самом деле: В пейджфайл страница может попасть только из modified списка. В modified список — при подрезке редко используемых страниц у разросшихся приложений...
Скажите, это справедливо для всей линейки Windows или начиная с определённой версии?
На самом деле: В пейджфайл страница может попасть только из modified списка. В modified список — при подрезке редко используемых страниц у разросшихся приложений...
Скажите, это справедливо для всей линейки Windows или начиная с определённой версии?
Для всех (начиная с NT3.51 общие принципы не менялись). В первую очередь используются страницы без данных: Free и Zeroed. Если эти списки пусты — принимается решение о том, какую страницу из Standby списка взять. Standby — это кеш общего назначения, там хранится как кеш обычных файлов, так и кеш пейджфайла (фактически здесь даже кавычки не нужны, по сути это и есть кеш содержимого пейджфайла), а переиспользоваться может любая из этих страниц. При последующем обращении к данным, которые были там закешированы — эти данные придется заново читать с диска.
С другой стороны, ЗАПИСЬ в пейджфайл иногда (редко) может происходить даже при наличии свободных страниц. Если приложение серьезно превысило свой MaxWorkingSet и его приватные страницы были подрезаны в modified список, система может решить, что хорошо бы эти данные сбросить на диск. При этом следует понимать, что данные оказываются и в пейджфайле и в физической памяти. Если приложение потребует свои данные обратно — обработчик page fault-а просто найдет соответствующую страницу в standby.
С другой стороны, ЗАПИСЬ в пейджфайл иногда (редко) может происходить даже при наличии свободных страниц. Если приложение серьезно превысило свой MaxWorkingSet и его приватные страницы были подрезаны в modified список, система может решить, что хорошо бы эти данные сбросить на диск. При этом следует понимать, что данные оказываются и в пейджфайле и в физической памяти. Если приложение потребует свои данные обратно — обработчик page fault-а просто найдет соответствующую страницу в standby.
Тогда объясните мне, если всё так, как Вы говорите, то почему получается так, что «имеем машину с WinXP с 4-мя гигабайтами памяти, запускаем VS 2003, немного работаем, запускаем какой-нибудь ФФ, минут 20 неспешно браузим (в пределах 5-6 табов, не больше), переключаемся обратно в VS — и мучительно ждём, когда же будет отрисовано окно VS (под весёлый треск жёсткого диска)»?
Никакого сверх тяжёлого проекта загружено не было, сама VS, как я уже сказал, 2003-го года, так что подозревать её в чрезмерных аппетитах я бы не стал, ФФ забить несколько гигов не успел бы чисто физически. В чём может быть дело? Сценарий воспроизводим в 100% случаев.
Никакого сверх тяжёлого проекта загружено не было, сама VS, как я уже сказал, 2003-го года, так что подозревать её в чрезмерных аппетитах я бы не стал, ФФ забить несколько гигов не успел бы чисто физически. В чём может быть дело? Сценарий воспроизводим в 100% случаев.
Каким образом определяете наличие памяти во free или zeroed списках?
Как я уже сказал, если уже ВСЯ память забита кешем — каким нибудь из кешей придется пожертвовать. И в случае с VS это не обязательно приватная память из пейджфайла — вполне могут быть выброшены и страницы образов — грузит то она их достаточно.
Попробуйте запустить xperf/procmon перед разворачиванием VS.
А вообще совет: переходите уже на современную систему. 4 Гб более чем достаточно для комфортной работы
Как я уже сказал, если уже ВСЯ память забита кешем — каким нибудь из кешей придется пожертвовать. И в случае с VS это не обязательно приватная память из пейджфайла — вполне могут быть выброшены и страницы образов — грузит то она их достаточно.
Попробуйте запустить xperf/procmon перед разворачиванием VS.
А вообще совет: переходите уже на современную систему. 4 Гб более чем достаточно для комфортной работы
>Попробуйте запустить xperf/procmon перед разворачиванием VS.
Попробую.
>А вообще совет: переходите уже на современную систему.
На домашнем компе я давно перешёл на современную систему (не из линейки Windows).
На рабочем не получится: современная система не поддерживает определённый специализированный софт, необходимый для работы (даже в режиме совместимости), поэтому политика компании — Windows XP на рабочих машинах.
Попробую.
>А вообще совет: переходите уже на современную систему.
На домашнем компе я давно перешёл на современную систему (не из линейки Windows).
На рабочем не получится: современная система не поддерживает определённый специализированный софт, необходимый для работы (даже в режиме совместимости), поэтому политика компании — Windows XP на рабочих машинах.
> не из линейки Windows
Линукс (и прочие *nix, за исключением разве что MacOSX, хотя как раз FreeBSD часть является там самой устаревшей) не является современной, ага. Зная Вас, я сначала написал эту ремарку в прошлом комментарии, но потом опять таки, зная Вас, убрал чтоб не начинать этих танцев — да я вообще линукс не упоминал.
Линукс (и прочие *nix, за исключением разве что MacOSX, хотя как раз FreeBSD часть является там самой устаревшей) не является современной, ага. Зная Вас, я сначала написал эту ремарку в прошлом комментарии, но потом опять таки, зная Вас, убрал чтоб не начинать этих танцев — да я вообще линукс не упоминал.
Если приложение потребует свои данные обратно — обработчик page fault-а просто найдет соответствующую страницу в standby.
Да, но диск все равно оказывается перегружен постоянной записью в своп. Это создает проблемы с доступом к диску.
Символичная картинка — «советские микросхемы — У.Г.» )))
Sign up to leave a comment.
Here be dragons: Управление памятью в Windows как оно есть [2/3]