Комментарии 85
Статьи такого уровня и определяют класс хабра.
Спасибо.
Спасибо.
+32
мммм, пора вводить плашку «Правильный автор», который пишет правильные статьи по нужной тематике.
ЗЫ надо чтоб автор стал №1 — все-таки ресурс не для фотографий кресел…
ЗЫ надо чтоб автор стал №1 — все-таки ресурс не для фотографий кресел…
+22
Уровень — да, я считаю любой программист обязан это знать. Но вот новичкам читать будет тяжело, тексту ещё бы пару дней в черновиках надо, чтобы стиль и оформление подкрутить.
Перед употреблением этого материала, чтобы чувствовать себя уверенно, рекомендую посмотреть прекраснейшее выступление Марка Руссиновича на PDC10 на эту тему:
Mysteries of Windows Memory Management Revealed, Part 1 of 2
Mysteries of Windows Memory Management Revealed, Part 2 of 2
Перед употреблением этого материала, чтобы чувствовать себя уверенно, рекомендую посмотреть прекраснейшее выступление Марка Руссиновича на PDC10 на эту тему:
Mysteries of Windows Memory Management Revealed, Part 1 of 2
Mysteries of Windows Memory Management Revealed, Part 2 of 2
+5
Действительно отличные доклады. Гораздо лучше чем у меня. В оправдание могу сказать, что Руссинович имеет громадный опыт в публичных выступлениях и подготовке презентаций. Более того, не удивлюсь если данная презентация собрана из материала, который собирался и полировался несколько лет. Я же написал статью за пару дней на коленке и с нуля.
В общем в черновиках ей сидеть надо было бы хотя с полгода — попробую поправить пост-фактум (если есть конкретные предложения по стилистике — с радостью приму помощь в редактуре)
В общем в черновиках ей сидеть надо было бы хотя с полгода — попробую поправить пост-фактум (если есть конкретные предложения по стилистике — с радостью приму помощь в редактуре)
+2
хотелось бы увидеть что нибудь вроде этого
geekswithblogs.net/akraus1/archive/2009/10/04/135294.aspx
думаю, тоже будет сильно интересно:)
geekswithblogs.net/akraus1/archive/2009/10/04/135294.aspx
думаю, тоже будет сильно интересно:)
+1
XP — 1 ядро
0
Осилил с боооольшим трудом :-)
Все-таки, немного напутано.
Все эти мутки с отключением pagefile или переноса на RAM-Disk — это все страшная утопия?
Все-таки, немного напутано.
Все эти мутки с отключением pagefile или переноса на RAM-Disk — это все страшная утопия?
+6
Что путано — это да. «Это не я такой — это жизнь такая».
Зато есть павершеловские скрипты для «оптимизации» памяти. :-)
Отключение пейджфайла может принести положительный результат в редких случаях. Однако перед отключением следует понимать, что делается, зачем и какие есть альтернативы. Перенос файла подкачки на рамдиск — не может помочь в принципе. То есть вообще никогда.
Зато есть павершеловские скрипты для «оптимизации» памяти. :-)
Отключение пейджфайла может принести положительный результат в редких случаях. Однако перед отключением следует понимать, что делается, зачем и какие есть альтернативы. Перенос файла подкачки на рамдиск — не может помочь в принципе. То есть вообще никогда.
+6
Спасибо за статью. Поработайте, пожалуйста, над стилем изложения. Нестрашно, если будет больше букв: зато понятнее.
0
Перенос файла подкачки на рамдиск — не может помочь в принципе. То есть вообще никогда.
А почему, ведь скорость доступа к файлу увеличивается? Объясните, если не трудно :)
-2
Потому, что назначение свопа компенсировать недостаток ОЗУ, а не забивать свободную память.
+3
Очень конструктивно.
Тем не менее размещение свопа в свободной памяти компенсирует медленную скорость доступа находясь на жестком диске.
Есть предположение, что автор имел в виду то, что перемещение свопа в оперативную память равносильно его отключению (лишняя «прослойка»). Я правильно понимаю?
Тем не менее размещение свопа в свободной памяти компенсирует медленную скорость доступа находясь на жестком диске.
Есть предположение, что автор имел в виду то, что перемещение свопа в оперативную память равносильно его отключению (лишняя «прослойка»). Я правильно понимаю?
-1
Ну какой в этом вообще может быть смысл? Вы работаете, у вас на столе бумаги, разные книги, в какой-то момент вы решаете, что вам не хватает места и вы прибиваете над столом полочку, куда складываете редко используемые книги. Через некоторое место замечаете, что до полочки слишком долго тянутся, снимаете её и кладете на стол. У вас стало больше места на столе?
+30
А если это ОЗУ не доступно для системы? XP 32бита не видит ничего выше 3гб. А памяти допустим 4гб. Пускай 786мб пропадают?
+3
> Перенос файла подкачки на рамдиск — не может помочь в принципе. То есть вообще никогда.
Вы ошибаетесь. 32-битная Windows (в моем случае — Vista) на ряде ноутбуков не видит памяти свыше 2.5Г (или выше 3Г плюс-минус — все зависит от конфигурации железа). Включенный режим PAE + файл подкачки на RAM-диске позволяют оставшиеся 1.5Г использовать хоть как-то. Понятное дело, что в таком режиме скорость работы с такой «виртуальной» памятью все равно раз в 100 ниже, чем с «обычной» памятью, однако даже этот результат оказывается на 2-3 порядка быстрее, чем если бы файл подкачки был на физическом диске. Подробности я описал тут: friendfeed.com/dklab/9f46792b/windows-32-4-2-5-ram-1
У меня сейчас в итоге: 32-битная Windows, 3Г памяти обычной, около 1Г — файл подкачки на RAM-диске, и еще есть файл подкачки на SSD (который, впрочем, практически всегда близок к нулевому размеру).
В 64-битной ОС, конечно же, этой проблемы нет, видны все 4Г.
Вы ошибаетесь. 32-битная Windows (в моем случае — Vista) на ряде ноутбуков не видит памяти свыше 2.5Г (или выше 3Г плюс-минус — все зависит от конфигурации железа). Включенный режим PAE + файл подкачки на RAM-диске позволяют оставшиеся 1.5Г использовать хоть как-то. Понятное дело, что в таком режиме скорость работы с такой «виртуальной» памятью все равно раз в 100 ниже, чем с «обычной» памятью, однако даже этот результат оказывается на 2-3 порядка быстрее, чем если бы файл подкачки был на физическом диске. Подробности я описал тут: friendfeed.com/dklab/9f46792b/windows-32-4-2-5-ram-1
У меня сейчас в итоге: 32-битная Windows, 3Г памяти обычной, около 1Г — файл подкачки на RAM-диске, и еще есть файл подкачки на SSD (который, впрочем, практически всегда близок к нулевому размеру).
В 64-битной ОС, конечно же, этой проблемы нет, видны все 4Г.
+10
Рекомендую подробности этой небезынтересной конфигурации памяти переопубликовать также и на Хабрахабре.
+1
Лушче отключить файл подкачки, чем переносить его в RAM
-3
Согласен с Мицголом, надо написать топик. В рамках недели просвещения на Хабре.
+1
А мне кажется, что там нечего особенно писать — ссылки достаточно, это не rocket science.
0
Ну с тестами надо для доказательства. Я вот хотел про пользу от рам диска для компиляции написать — так провёл кое какие тесты с сорцами FireFox и писать передумал — ибо оказалось не о чем.
+1
Отрицательный результат — тоже результат )
0
С доказательствами того, что запись в RAM-диск на несколько порядков быстрее, чем запись на диск (даже SSD)? Мне кажется, это излишне.
0
Я повторюсь, я тоже думал что компиляция на рам диске сильно быстрее чем на hdd. Однако разница была:
ALL IN RAM = 1915 seconds
ALL ON HDD = 1945 seconds
ALL — это всё, исходники объёктники и temp.
ALL IN RAM = 1915 seconds
ALL ON HDD = 1945 seconds
ALL — это всё, исходники объёктники и temp.
0
О таком сценарии не подумал — действительно имеет место быть. Добавил в апдейты
+1
Либо я чего-то не понял, либо Вы тоже заблуждаетесь. Та память, которую «не видно» — это memory mapped I/O и области для доступа к видеокарте например, к ее памяти через адресное пространство оперативной. Так или иначе, эти адреса недоступны физически на уровне PCI-мостов, никакими ухищрениями с пейджингом увидеть их не получится. Это тот случай, когда памяти ровно 4 гига. Если памяти больше, скажем 8 гигов, тогда можно написать свой драйвер RAM-disk-а, который сможет использовать память выше 4 гигов (то что между 3,3 и 4 увидеть все-равно не получится) но смысла в этом никакого, тут надо ставить x64.
У современных чипсетов есть такая фича — memory remap feature, которая позволяет отмапить часть оперативки в пространство выше 4Gb, на первый взгляд кажется, что это то что нужно, пишем свой драйвер, работающий с этой памятью и размещаем своп там, выше 4 гигов. На практике это опять же лишено всякого смысла, потому что для доступа к этой памяти нужен диапазон адресов в первых 4-х гигах, которые придется попросить из системного адресного пространства и вручную поправить таблицы страниц, но мы при этом забираем у системы виртуальные адреса, которые ей возможно нужнее, чем дополнительный своп, можно конечно каждый раз выделять/освобождать при каждом обращении к этому «свопу», но в этом еще меньше смысла.
В общем я бы сказал так, теоретически при наличии должной поддержки со стороны желаза и в каком-то особом случае, когда известно что можно безболезненно забрать у системы часть системного виртуального адресного пространства, это может и принесет какую-то пользу, но всем и каждому я бы это не рекомендовал. Это примерно как кошке пятая нога иногда может быть полезна. Поправьте меня.
У современных чипсетов есть такая фича — memory remap feature, которая позволяет отмапить часть оперативки в пространство выше 4Gb, на первый взгляд кажется, что это то что нужно, пишем свой драйвер, работающий с этой памятью и размещаем своп там, выше 4 гигов. На практике это опять же лишено всякого смысла, потому что для доступа к этой памяти нужен диапазон адресов в первых 4-х гигах, которые придется попросить из системного адресного пространства и вручную поправить таблицы страниц, но мы при этом забираем у системы виртуальные адреса, которые ей возможно нужнее, чем дополнительный своп, можно конечно каждый раз выделять/освобождать при каждом обращении к этому «свопу», но в этом еще меньше смысла.
В общем я бы сказал так, теоретически при наличии должной поддержки со стороны желаза и в каком-то особом случае, когда известно что можно безболезненно забрать у системы часть системного виртуального адресного пространства, это может и принесет какую-то пользу, но всем и каждому я бы это не рекомендовал. Это примерно как кошке пятая нога иногда может быть полезна. Поправьте меня.
+1
Позвольте с вами не согласиться!
Включенный режим PAE позволяет 32-битной операционной системе эффективно использовать доступную физическую память далеко за пределами 4 ГБ (вплоть до 64 ГБ).
Конечно же, виртуальное адресное пространство одного конкретного процесса останется неизменным. Но при этом физическая страница ОЗУ, соответствующая какой-либо странице виртуальной памяти, может лежать за пределами 4 ГБ.
Я не буду вдаваться в подробности, все уже расписано до меня, почитайте, интересно: http://en.wikipedia.org/wiki/Physical_Address_Extension
Зная этот факт, я бы не стал утверждать, что pagefile в RAM-диске — это выгодно. А вы проверяли? Делали какие-нибудь тесты?
Кстати, неправильно говорить, что 32-битное приложение не может использовать больше 4 ГБ ОЗУ;) На windows это делается посредством AWE: http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx
Сомневающимся настоятельно рекомендую написать простенькую программку своими руками. Это очень занимательно:)
Включенный режим PAE позволяет 32-битной операционной системе эффективно использовать доступную физическую память далеко за пределами 4 ГБ (вплоть до 64 ГБ).
Конечно же, виртуальное адресное пространство одного конкретного процесса останется неизменным. Но при этом физическая страница ОЗУ, соответствующая какой-либо странице виртуальной памяти, может лежать за пределами 4 ГБ.
Я не буду вдаваться в подробности, все уже расписано до меня, почитайте, интересно: http://en.wikipedia.org/wiki/Physical_Address_Extension
Зная этот факт, я бы не стал утверждать, что pagefile в RAM-диске — это выгодно. А вы проверяли? Делали какие-нибудь тесты?
Кстати, неправильно говорить, что 32-битное приложение не может использовать больше 4 ГБ ОЗУ;) На windows это делается посредством AWE: http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx
Сомневающимся настоятельно рекомендую написать простенькую программку своими руками. Это очень занимательно:)
0
Здесь и здесь
Вкратце, PAE теоретически использовать можно, оно будет работать не всегда, часть физических адресов недоступна из-за меппинга пространства ввода/вывода и никакими способами ее не вытащить (адрес на шине адресует, к примеру видеокарту, а не память). Даже если ядро включает PAE (к примеру для включения NX) это не значит, что оно будет поддерживать PAE адресацию выше 4Gb (из-за лицензионных ограничений и некоторых глюков с драйверами PAE на клиентских 32-битных виндах не адресует больше 4Gb). Пытаться напрямую работать с директорией страниц чревато очень серьезными глюками. Завязывать драйвер RAM-диска на патченное ядро не имеет смысла.
Это технические проблемы. Если же говорить о практике: я не видел драйверов RAM диска, которые бы работали с фической памятью, да еще через PAE (в частности потому, что как сказано выше, это не имеет смысла на 32-битных виндах) — они все поголовно выделяют либо из Paged либо из Non-paged пула и хранят данные там. Ну и во-вторых, в том примере, на который я дал ссылку использует 3 Gb памяти, которые отлично адресуются системой и могут быть использованы кеш-менеджером.
Что же до тестов: как я уже сказал, теоретически такой драйвер существовать может, практически же он мне не попадался — так что тестов не было за неимением объекта тестирования. Вместо кривого решения надуманных проблем лучше взять x64 версию ОС и не мучаться.
Вкратце, PAE теоретически использовать можно, оно будет работать не всегда, часть физических адресов недоступна из-за меппинга пространства ввода/вывода и никакими способами ее не вытащить (адрес на шине адресует, к примеру видеокарту, а не память). Даже если ядро включает PAE (к примеру для включения NX) это не значит, что оно будет поддерживать PAE адресацию выше 4Gb (из-за лицензионных ограничений и некоторых глюков с драйверами PAE на клиентских 32-битных виндах не адресует больше 4Gb). Пытаться напрямую работать с директорией страниц чревато очень серьезными глюками. Завязывать драйвер RAM-диска на патченное ядро не имеет смысла.
Это технические проблемы. Если же говорить о практике: я не видел драйверов RAM диска, которые бы работали с фической памятью, да еще через PAE (в частности потому, что как сказано выше, это не имеет смысла на 32-битных виндах) — они все поголовно выделяют либо из Paged либо из Non-paged пула и хранят данные там. Ну и во-вторых, в том примере, на который я дал ссылку использует 3 Gb памяти, которые отлично адресуются системой и могут быть использованы кеш-менеджером.
Что же до тестов: как я уже сказал, теоретически такой драйвер существовать может, практически же он мне не попадался — так что тестов не было за неимением объекта тестирования. Вместо кривого решения надуманных проблем лучше взять x64 версию ОС и не мучаться.
-1
Мне кажется, вы меня не правильно поняли: я хотел поспорить с пользователем DmitryKoterov, который утверждает, что использовать своп в рам-диск эффективно, и его спрашивал, на чем основана уверенность, что используемая им конфигурация лучше стандартной со включенным PAE.
От вас ожидал поддержки. Кстати, ее и получил, спасибо:)
Ну и конечно, правильнее взять x64, если есть возможность:)
От вас ожидал поддержки. Кстати, ее и получил, спасибо:)
Ну и конечно, правильнее взять x64, если есть возможность:)
0
Мало что понял… Знаю только что сейчас проги леплят всякими конструкторами и они огромные, тогда как раньше программы занимали места меньше (и на диске и в озу) Конечно нельзя сравнить текстовый интерфейс например 5-го ворда под дос и ворда из новых офисов, но все равно новые программы хотять слишком много…
Если подумать то даже 10 мегабайт, это ж 10 000 000 символов, таким количеством букв/знаков можно описать дофига всего, даже представить не могу… а для новых программ это очень мало… Вот здесь мне кажется что-то не то, не так должно быть
Если подумать то даже 10 мегабайт, это ж 10 000 000 символов, таким количеством букв/знаков можно описать дофига всего, даже представить не могу… а для новых программ это очень мало… Вот здесь мне кажется что-то не то, не так должно быть
+2
Например в книге, букв наверно меньше, но когда ее читаешь сколько всего себе можно пердставить… Тоже самое должно быть с компами, ты ему основные указания, а он все делает на ходу
+1
Здесь не столько про проги, сколько про саму винду. Базовые принципы не менялись со времен NT3.51 (1993-й год — когда компьютеры были большими, а программы маленькими).
Если кратко: смотреть в таск менеджер бесполезно, смотреть на «используемую память» и «используемый своп» бесполезно, перезапускать «Оперу», отожравшую гиг памяти — бесполезно. Ну и т.д… Просто поразительно, насколько много мифов не основаны вообще ни о чем (собственно именно поэтому статья и называется «Here be dragons»)
Если кратко: смотреть в таск менеджер бесполезно, смотреть на «используемую память» и «используемый своп» бесполезно, перезапускать «Оперу», отожравшую гиг памяти — бесполезно. Ну и т.д… Просто поразительно, насколько много мифов не основаны вообще ни о чем (собственно именно поэтому статья и называется «Here be dragons»)
+3
Ну не знаю, возможно… я любитель старых прог так как они меньше кушают озу и главное быстро работают, а более старые даже не знают что такое интернет чтобы туда лазить за обновлениями и проверкой лицензии, как вот например айсидиси 3.0… Винда у меня ХР и своп отключен, озу 4 гига но видно 3.25, меня это не беспокоит, все равно озу как г-на, мне хватает…
+1
4 гига и до сих пор на XP x86. Мсье знает толк в извращениях :-)
+1
так без свопа же, так что ограничения в 4 гига на адресное пространство вполне хватает.
+1
Сразу вопрос про XP:
Всё это в равной степени примеримно к XP? Есть ли её кеш-менеджера есть какие-то свои особенности (кроме отсутствия приоритетов)?
И ещё, на скриншоте с XP System Cache — это Cached? Если да, почему System Cache > Available (ведь весь кеш можно освободить под нужды)?
Так куда же она уходит после того, как отбирается у процесса? А уходит она, в зависимости от того, соответствует ли ее содержимое тому, что было прочитано с диска, в один из двух списков: Standby (начиная с Висты это не один список, а 8, о чем позже) или Modified...
Всё это в равной степени примеримно к XP? Есть ли её кеш-менеджера есть какие-то свои особенности (кроме отсутствия приоритетов)?
И ещё, на скриншоте с XP System Cache — это Cached? Если да, почему System Cache > Available (ведь весь кеш можно освободить под нужды)?
0
На XP Standby список хоть и один, но он все еще есть. Так что к XP применимо все, кроме приоритетов памяти.
Почему Cached > Available. Полагаю потому, что Modified list — тоже является кешем данных с диска, но не является «доступной» памятью в том смысле, что перед тем как ее можно будет использовать нужно сделать как минимум одну дисковую операцию (сбросить измененную страницу на диск)
Почему Cached > Available. Полагаю потому, что Modified list — тоже является кешем данных с диска, но не является «доступной» памятью в том смысле, что перед тем как ее можно будет использовать нужно сделать как минимум одну дисковую операцию (сбросить измененную страницу на диск)
+1
перезапускать «Оперу», отожравшую гиг памяти — бесполезно.
когда файрбаг течет и память поднимается до верху — машина начинает ужасно тормозить.
перезапуск фокса помогает.
может в теории оно всё так, как вы говорите, но на практике оно ведёт себя совершенно иначе
+1
У меня тоже чисто практический опыт. До хрома я пользовался оперой что то около восьми лет. В рамках программы по легализации всего и вся, я стал слушать музыку с пандоры, ласт.фм и имеем при этом никогда не перегружаясь без острой необходимости (апдейты и пр). Не знаю, был ли это лик или флеш так кеширует, но опера достаточно быстро вырастала за гигабайт. Причем система использовалась достаточно активно (виртуалки, большие проекты в VS, всякий дотнетовский lob и пр.) — тормозов не наблюдалось.
Здесь как в теории так и на практике есть некоторый «конфликт интересов»: система пытается не вырезать Working Set-ы и скорее выбросит кеш, так что повершеловский скрипт, который я привел, может ИНОГДА помочь вручную сбросить «утекшую память» сначала в modified список, а потом и в пейджфайл. Но на практике, я этого никогда не делал и никогда не имел проблем с производительностью (в смысле по причине нехватки памяти)
Здесь как в теории так и на практике есть некоторый «конфликт интересов»: система пытается не вырезать Working Set-ы и скорее выбросит кеш, так что повершеловский скрипт, который я привел, может ИНОГДА помочь вручную сбросить «утекшую память» сначала в modified список, а потом и в пейджфайл. Но на практике, я этого никогда не делал и никогда не имел проблем с производительностью (в смысле по причине нехватки памяти)
0
НЛО прилетело и опубликовало эту надпись здесь
вот у меня сейчас modified=50mb и не меняется. правильно ли я понимаю, что в случае экстренного вырубания компа эти данные будут потеряны с непредсказуемыми последствиями?
0
Тысячи данных будут утеряны в случае экстренного вырубания компа. Но в основном это память приложений, которую они заново нагенерируют при следующем старте.
0
память приложений — это in use
0
In use — это вроде как Working Set всех приложений. Stend by и modified — помеченные для освобождения страницы. В принципе, в modified могут быть и измененные проекции файлов, открытых для записи. Но мне почему-то кажется, что проекции редко делают для записи, и в основном это могут быть какие-нибудь торренты, которые все равно хеши от частей файлов считают.
0
у меня сейчас никаких торрентов не запущено. и если приложение что-то изменило в файле, но это фиг знает когда сбросится на диск… наверно именно из-за этого у меня хром после восстановления сессии открывает давно закрытые мной вкладки и забывает про текущие =_="
0
RamMap умеет «чистить» (сбрасывать данные на диск и переводить страницы в Standby) modified список.
Данные можно сбрасывать вызовом FlushFileBuffers (утилита sync умеет делать это)
Данные можно сбрасывать вызовом FlushFileBuffers (утилита sync умеет делать это)
+1
ну я опять же не буду вручную ничего чистить %-) просто неприятно, что ось ленится сбросить каких-то 50 метров на диск…
0
Private данные собираются и долго хранятся еще и для того, чтобы можно было их кластеризовать. Линейное чтение/запись — достаточно быстрая операция, это head seek убивает производительность. Вот страницы, находящиеся по соседству в памяти с большой вероятностью в будущем понадобятся тоже вместе. Винда складывает их одну за другой на диск. Фактически время записи/чтения скажем мегабайта мало отличается чтения/записи четырех килобайт
+1
И да, я не имел в виду, что Вы можете сбросить Ваши данные при помощи FlushFileBuffers. Я имел в виду, что приложение может сбросить данные на диск при помощи этой функции, если считает это достаточно важным. Если же нужны ACID гарантии — есть KTM
0
Да, то что приложения использую прямо сейчас — это In Use. Если приложение получило физическую страницу в свой рабочий набор, но после того как эта страница была «подрезана», в случае приватных данных она попадает в Modified список с «намерением» сбросить ее в pagefile. В этом списке ее можно держать сколь угодно долго — это данные могут быть потеряны только вместе с единственным процессом, который может их использовать
+1
Да, эти данные будут потеряны. С другой стороны, чаще всего неопределенно должно в modified списке сидият только Private (те которые были выделены в куче, стеки потоков и пр) страницы, которые все равно не будут иметь смысла после перезагрузки. То есть как раз те страницы, которые должны пойти в пейджфайл, а не в пользовательские файлы.
Вообще говоря, никаких гарантий сохранности ДАННЫХ большинство файловых систем не дает. Журналируются только метаданные — то есть структуры самой файловой системы. Программа, которая хочет предоставить ACID гарантии, должна использовать Kernel Transaction Manager
Вообще говоря, никаких гарантий сохранности ДАННЫХ большинство файловых систем не дает. Журналируются только метаданные — то есть структуры самой файловой системы. Программа, которая хочет предоставить ACID гарантии, должна использовать Kernel Transaction Manager
+2
Я правильно понял, что Commit Charge — это объем виртуальной памяти, который суммарно запросили все приложения в системе?
0
Но самое потрясающее, что я видел всвязи с управлением памятью — это совет переместить pagefile на RAM-диск:Всё нормально. Windows XP не умеет нормально использовать память выше 3ГБ, поэтому иногда там создают RAM-диск, на который помещают своп.
Из моих трех гигабайт под RAM disk был выделен один (на тот момент, когда на лаптопе еще была установлена XP), на котором я создал своп на 768МБ ...
0
Объясните кто-нибудь случай с этой темой на КЫВТе:
rsdn.ru/forum/flame.comp/3805844.1.aspx
(см картинку)
Что это за выделение памяти хитрое, которое не попадает ни в Commit Charge, ни в Working Set?
rsdn.ru/forum/flame.comp/3805844.1.aspx
(см картинку)
Что это за выделение памяти хитрое, которое не попадает ни в Commit Charge, ни в Working Set?
0
Может она в nonpaged pool-е в ядре? В пользу этого предположения говорит еще и то, что при очевидном бешенном давлении на память, система не освободила себе памяти путем подрезания (вернее рабочие наборы процессов выглядят подрезанными, но память все равно забита). Я бы искал драйвер с утечками
Вообще, мне не известно о способах потребления физической памяти таким образом, чтоб это потребление нельзя было отследить стандартными средствами (хотя я предпочитаю Process Explorer). Единственное, что можно потреблять незаметно — это commit charge.
Вообще, мне не известно о способах потребления физической памяти таким образом, чтоб это потребление нельзя было отследить стандартными средствами (хотя я предпочитаю Process Explorer). Единственное, что можно потреблять незаметно — это commit charge.
0
Нет, это не драйвер. Там в конце темы есть объяснение, что за прога потребляла память таким образом. Но каким образом она это делала — по прежнему загадка.
0
Хм, я тоже совершенно не представляю, как они это делали :-)
По моим нынешним представлениями, как я уже сказал, невозможно взять у системы физическую память так, чтобы она не отобразилась в Working Set. Вполне допускаю, что я чего не знаю, но сильно подозреваю, что здесь что то другое, чего автор просто не учел: к примеру, какой то драйвер (наподобие обсуждаемого там же eboostr) кешировал файлы для оперы и делал это в non paged pool. Это должно было бы быть видно на Task Manager-овском Performance Tab-е.
По моим нынешним представлениями, как я уже сказал, невозможно взять у системы физическую память так, чтобы она не отобразилась в Working Set. Вполне допускаю, что я чего не знаю, но сильно подозреваю, что здесь что то другое, чего автор просто не учел: к примеру, какой то драйвер (наподобие обсуждаемого там же eboostr) кешировал файлы для оперы и делал это в non paged pool. Это должно было бы быть видно на Task Manager-овском Performance Tab-е.
+1
В общем, я тут поэкспериментировал с оперой и получил занятные результаты. В целом, всё аналогично — память пожирается, commit charge и commit limit без изменений. Но вот что интересно, task manager и resource monitor показывают что cached memory в это время уменьшается до 0, а вот process explorer показывает что system cache увеличивается на весь объем зохаванной памяти.
Получается, что понятие кэш в этих программах понимается совсем по разному. И в чем там различие, хотелось бы знать?
Получается, что понятие кэш в этих программах понимается совсем по разному. И в чем там различие, хотелось бы знать?
0
А у Вас случайно не осталось скриншота Process Explorer-овского System Information? Ну и желательно вкладку Performance из свойств процесса оперы и system в procexp?
+1
А ты посмотри сам, это же куда информативнее ;)
Воспроизводится очень просто. Запустить закачку большого торрента (> RAM size) оперой, стопнуть, запустить снова.
Воспроизводится очень просто. Запустить закачку большого торрента (> RAM size) оперой, стопнуть, запустить снова.
0
Мне просто не очень хочется ставить оперу и качать 10-гиговый файл.
+1
Не нужно качать, достаточно просто запустить.
Случайно не сохранилось, так что пришлось делать специально ;)
img695.imageshack.us/i/clipboard01jg.png/
img44.imageshack.us/i/clipboard02zt.png/
img338.imageshack.us/i/clipboard03y.png/
img844.imageshack.us/i/clipboard04y.png/
img405.imageshack.us/i/clipboard05j.png/
Случайно не сохранилось, так что пришлось делать специально ;)
img695.imageshack.us/i/clipboard01jg.png/
img44.imageshack.us/i/clipboard02zt.png/
img338.imageshack.us/i/clipboard03y.png/
img844.imageshack.us/i/clipboard04y.png/
img405.imageshack.us/i/clipboard05j.png/
0
Ухтыха. Ради этого можно даже поставить оперу. Спасибо
+1
Скачал, посмотрел. RamMap показывает, что память уходит в mapped file и даже показывает в какой (там кстати тоже приоритет 5, который выталкивает из памяти всех подряд), но вот почему эта памяти не отображается в Shared WS для меня загадка — надо будет поковырять
+1
Кстати, еще интересно было бы узнать, менялся ли commit limit (когда кто-то выделяет non-paged pool — это не увеличивает commit charge, а уменьшает commit limit). В общем скриншот Process Explorer-овского system info мог бы помочь при выяснении причин
+1
Странно, но эта и другие ваши статьи должна быть на хабре!
0
Прочитал. Что-то понял, но мало. Можно примеров? Есть у меня 1С, работают в ней какие-то пользователи, цифры процессов 1С которых разнообразнейше плавают в диспетчерах задач от 300 до 1800 МБ. Захотелось мне новый сервер завести - как память считать? 300 на RDP, к этому мы привыкли, а 1С как понять, когда working set одно, private другое, что-то там третье. Привыкли считать по столбцу в диспетчере задач, а он, оказывается, разное показывает от системы к системе. Получается, по peak working set считать, если с надёжным запасом?
А через VMMap почему-то он выглядит иначе. Проверил на других - через VMMap больше. Процесс находится в виртуальной машине, память которой в динамическом режиме.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Here be dragons: Управление памятью в Windows как оно есть [1/3]